The cost of running your data function is not growing because you are building more valuable things. It is growing because data products do not retire themselves. Every dashboard, every pipeline, every model your team has ever shipped is still on the balance sheet, still requiring maintenance, monitoring, and support, whether or not it is still delivering value. And nobody is tracking that number.
The accumulation problem
Think about the trajectory of a typical data function over three to five years.
Year one: the team ships its first cohort of products. A few dashboards, some automated reports, a data pipeline or two. The maintenance cost is low because there is not much to maintain.
Year two: the team doubles the portfolio. More products, more stakeholders, more pipelines. The new products get built on top of infrastructure from year one, which now requires ongoing attention alongside the new work.
Year three: the team is being asked to deliver at the same pace as year two, but a meaningful share of the team's capacity is now consumed by keeping years one and two running. Support tickets, pipeline breaks, schema migrations when upstream data changes, users who cannot interpret dashboards that have drifted from the business process they were built for.
By year five, many data teams are spending more than half their time on the portfolio that already exists, not on building anything new. And from the outside, it looks like a team that has stopped delivering, because the output is invisible. Maintenance does not appear in any sprint review.
Why the cost is non-linear
Software products can be shipped and largely left alone. Once a user-facing application is stable, it requires maintenance, but the relationship between portfolio size and maintenance burden is roughly linear, each product adds a predictable amount of ongoing cost.
Data products do not work this way. Data is downstream of everything. When the marketing team changes how it runs campaigns, the attribution logic breaks. When the product team redesigns a feature, the funnel analysis changes. When the company moves CRM platforms, every pipeline that touches customer data needs to be rebuilt. These are not edge cases, they are the normal operating environment of a data team.
This means every data product you have ever shipped is permanently exposed to change from systems and processes it did not control. The maintenance burden does not stay constant; it grows with the complexity of the organization. And it grows faster than the team's capacity to absorb it.
The trade-off nobody makes
Every organization has a version of this problem: products that were built for a business process that has since changed, data pipelines that serve dashboards nobody looks at, reports that the business team has replaced with a spreadsheet but that the data team is still running every night.
These products are not delivering value. They are consuming team capacity. But they rarely get retired, because retiring a data product requires someone to declare that it is no longer needed, and the person who built it is not eager to have that conversation, and the business stakeholder who requested it is not monitoring whether it is still being used.
The result is a portfolio that grows in one direction only. Products get added; products never get removed. The team gets slower every quarter not because the individuals are performing worse, but because the weight they are carrying increases every time something new ships.
The organizations that avoid this pattern are the ones that treat the portfolio as a managed set of assets, where adding something new requires an explicit decision about what gets retired or reduced to make room for it. This is not a natural conversation to have, it feels like declaring that previous work was wasted. But the alternative is a data function where the cost keeps growing and the innovation capacity keeps shrinking, until leadership concludes that the team is not delivering value and begins looking for answers in the wrong place.
What the cost looks like when you measure it
The maintenance burden of a data portfolio can be quantified. For each product in the portfolio, the team can estimate the hours per month it requires: pipeline monitoring, bug fixes, user support, schema updates, stakeholder requests related to that product.
Sum those estimates across the portfolio and compare to the team's total available capacity. In most organizations I have worked with, the maintenance share sits between 40% and 65% of the team's total time, often higher if the portfolio is more than three years old.
That number is the starting point for an honest conversation about what the data team can actually deliver versus what leadership expects them to deliver. In most cases, the gap between those two things is large, and the maintenance burden is why.
The decision that follows
Once the maintenance cost is visible, it forces a set of decisions that are uncomfortable but necessary.
Which products are worth the maintenance cost they consume? The answer is not "all of them," but without measurement, that is what the default behavior implies.
Which products have drifted far enough from their original purpose that they are creating more work than they are saving? These are the products that generate the most support tickets, the most "can you update this?" requests, the most confusion when the numbers do not match what the business team expects.
What would it take to reduce the portfolio to the set of products that genuinely earn their keep, and use the recovered capacity to build the next thing the business actually needs?
This is portfolio management. It is not glamorous, and it is not a conversation most data leaders are trained to have with their CEO. But it is the conversation that explains why the cost keeps rising and what can actually be done about it.
The question worth asking this quarter
Ask your Head of Data to pull a list of every active data product in the portfolio and estimate the monthly maintenance hours for each one. You do not need precision, rough estimates are enough to see the picture.
Then ask: of the total team capacity, what percentage is going to maintenance versus new development? If the maintenance share is above 50%, the portfolio is running the team rather than the team running the portfolio. That is the problem, and it has a solution.
Book a 30-minute conversation to map the portfolio and identify where the weight is concentrated. That is usually where the answer is.