A company I advised in 2024 built a data team of 14 people in 18 months. They hired a Head of Data, four analytics engineers, three data analysts, two ML engineers, a data architect, and support staff. They built a modern data stack – Snowflake, dbt, Looker, the whole thing. They shipped a customer 360 dashboard that the CEO showed to the board. Everyone was proud.
By early 2026, the team was down to six people. The Head of Data had left. The remaining analysts had been reassigned to Finance and Marketing. The ML engineers were gone entirely. Nobody made a dramatic announcement. It just happened gradually, one “restructuring” at a time.
This pattern is so consistent across companies that it might as well be a law of corporate physics.
The Three-Year Life Cycle
Most centralised data teams have a life expectancy of about three years. The arc looks like this:
Year one is the building phase. The team gets created with fanfare – “we’re becoming data-driven!” There’s executive sponsorship, budget approval, and aggressive hiring. The work is tangible and satisfying: stand up the data warehouse, build the pipelines, create the first dashboards, establish data governance basics. Progress is visible. Everyone can see things being built.
Year two is where the trouble starts. The infrastructure is mostly built. The dashboards exist. The data warehouse is running. And somewhere around Q2, the CFO starts asking uncomfortable questions about what exactly this team of 15 people produces that justifies their $3M annual payroll. The team is still busy – there are always more dashboards to build, more data sources to integrate, more pipeline issues to fix. But the work has shifted from building something new to maintaining something that exists, and maintenance doesn’t generate executive excitement.
Year three is the reckoning. A new CFO arrives, or the existing one gets more aggressive about cost optimisation. Someone pulls together a spreadsheet showing the data team’s cost versus their measurable output. The numbers don’t look good, because the team never established a clear framework for measuring their impact. The team gets restructured, absorbed into business units, or quietly downsized.
I’ve watched this play out at a dozen companies. The details vary but the structure doesn’t.
The Infrastructure Trap
The core problem is a setup failure. The data team was created to build infrastructure – and infrastructure projects have an end date. Once the data warehouse is running, the pipelines are stable, and the core dashboards are built, you have a team whose original mission is complete.
Most data leaders don’t make the transition from “build the thing” to “deliver value with the thing” fast enough. They keep hiring engineers to build more infrastructure instead of pivoting to outcomes. Another data source integration. Another dashboard. Another pipeline optimisation. All of it defensible, none of it directly tied to revenue or cost savings.
The CFO doesn’t care that you migrated from Redshift to Snowflake and reduced query times by 60%. The CFO cares about what that 60% improvement enabled in dollar terms. If you can’t answer that question, you have a problem.
The Service Desk Trap
The second failure mode is subtler and arguably worse. The data team becomes a ticket queue.
Business units submit requests. “Can you pull the Q3 revenue numbers by region?” “Can you build a dashboard for the new product launch?” “Can you run an analysis of customer churn in the enterprise segment?” The data team fulfils these requests diligently. The backlog grows. The team asks for more headcount to handle the volume. Leadership approves because the demand is clearly there.
But at some point, someone with a spreadsheet realises that most of these requests are straightforward report pulls and basic analyses. The kind of work that a well-trained business analyst could do, or that a consulting firm could handle at a fraction of the cost. If your data team’s primary output is ad-hoc report requests, you’ve built a cost centre that’s pretending to be a strategic capability. And cost centres get cut.
The painful part: the team is working hard. They’re responsive, they’re producing output, and the business units genuinely rely on them. None of that matters when the cost-cutting conversation starts. A strong data strategy roadmap would have anticipated this vulnerability and built in safeguards. Without one, the team is exposed.
What Actually Keeps Data Teams Alive
The data leaders who survive long-term – and I mean leaders who keep their teams intact through two or three budget cycles – share one trait. They tie every major project to a dollar figure.
Not “we built a customer segmentation model.” Instead: “The segmentation model drove $2.4M in incremental campaign revenue in Q3 by enabling Marketing to target high-propensity customers with personalised offers.”
Not “we improved data quality.” Instead: “By fixing the duplicate customer records issue, we eliminated $180K in annual over-crediting to the sales team and reduced finance close time by two days per month.”
Not “we built a churn prediction model.” Instead: “The churn model flagged 340 at-risk enterprise accounts in Q2. The retention team intervened on 280 of them and saved $6.1M in ARR that would have been lost.”
This requires the data team to work differently. You can’t just ship a model or a dashboard and move on. You have to follow the output through to business impact, which means partnering closely with the teams that act on your work. It’s more effort. It’s also the difference between a team that survives and a team that gets restructured.
CDOs and Heads of Data need to understand this from day one. If you’re stepping into a data leadership role, the best CDO programs will drill this into you: your survival depends on your ability to speak the CFO’s language.
The Embedded vs Centralised Debate
Many companies that go through the disband-and-restructure cycle land on an embedded model. Instead of a centralised data team, analysts and engineers sit within business units – two in Marketing, one in Finance, three in Product – with a thin central team handling governance, standards, and shared infrastructure.
The embedded model solves the “data team doesn’t understand the business” problem. An analyst who sits in Marketing, attends Marketing standups, and reports to the VP of Marketing will produce more relevant work than one who sits in a centralised team and gets context through ticket descriptions.
But the embedded model creates its own problems. Standards diverge. Marketing’s analyst builds things differently from Finance’s analyst. Nobody owns the data model holistically. Duplicated work creeps in. And the embedded analysts often get pulled into non-data work because their business unit manager sees them as a general resource.
The companies that make this work maintain a central data platform team (3-5 engineers who own the warehouse, the pipelines, and the data model) alongside embedded analysts. The central team sets standards and builds shared infrastructure. The embedded analysts deliver value to their business units. A data governance council meets monthly to keep everything aligned.
Neither model is perfect. But the hybrid approach gives you the business proximity of embedded roles with the coherence of centralised standards. Getting the balance right is hard. Getting it wrong in either direction is worse.
The CDO Tenure Problem
Here’s a structural issue that doesn’t get discussed enough: the average CDO tenure is about 2.5 years. According to research from Harvard Business Review, becoming data-driven is genuinely difficult, and the organisational timelines rarely match executive patience.
2.5 years is barely enough time to build the infrastructure, let alone demonstrate sustained value. The CDO arrives, spends six months assessing the landscape and hiring, spends twelve months building, starts to show results around month 18, and then either leaves for a bigger role or gets pushed out because results aren’t coming fast enough. The replacement CDO arrives, disagrees with the previous CDO’s technical choices, and restarts the cycle.
Boards and CEOs need to understand that data capability is a 3-5 year build, not a 12-month project. If you’re hiring a CDO and expecting transformative results in year one, you’re setting everyone up for failure. McKinsey’s work on the data-driven enterprise reinforces this point – the companies that get real value from data invested consistently over multiple years.
Signals Your Data Team Is in Trouble
If you lead a data team, watch for these warning signs:
- The CFO has asked for a “data team ROI analysis” – that’s not curiosity, it’s the opening move in a cost-cutting conversation
- Your team’s work is described internally as “support” rather than “strategic” – language matters, and “support” functions get outsourced
- You can’t name three projects from the last quarter that had measurable business impact – if you can’t, neither can the people who control your budget
- Business unit leaders have started hiring their own analysts without consulting you – they’ve decided your team is too slow or too disconnected
- Your executive sponsor has changed roles or left the company – without air cover, data teams are vulnerable
Any two of these showing up simultaneously means you have 6-12 months to change the narrative or face restructuring.
Building a Team That Lasts
If you’re building a data team right now, build the value narrative from day one. Don’t wait until the infrastructure is finished to start talking about impact. Even during the build phase, find small wins that connect to dollars. “The new pipeline reduced the monthly close process by three days, freeing up $45K in Finance team time annually.” It’s a small number, but it establishes the habit of measuring impact.
Staff for sustainability, not for a sprint. You don’t need 15 people in year one. Start with 5-6 strong generalists who can build and deliver value simultaneously. Grow based on demonstrated impact, not projected need. Every hire you make before you can justify the team’s existence adds to your vulnerability.
And build relationships with Finance from the start. Not because they’re your adversary, but because they’re the people who will defend or dismantle your budget. If the FP&A team sees your data team as a partner that helps them do their job better, you have an ally in every budget conversation. If they see you as a line item they don’t understand, you’re exposed.
Data teams don’t get disbanded because they’re incompetent. They get disbanded because they can’t prove they’re worth what they cost. That’s a solvable problem – but only if you start solving it before anyone asks the question.
Ben is a full-time data leadership professional and a part-time blogger.
When he’s not writing articles for Data Driven Daily, Ben is a Head of Data Strategy at a large financial institution.
He has over 14 years’ experience in Banking and Financial Services, during which he has led large data engineering and business intelligence teams, managed cloud migration programs, and spearheaded regulatory change initiatives.