FTE Debt is the organizational capacity you've already lost to data friction. The hours your team burns on manual work, duplication, reconciliation, and waiting. The formula is People × Friction% × Average Cost. On most data portfolios, it's the single largest hidden cost.

Why is it so hard to measure data ROI?

Most companies track data costs (tools, infrastructure, salaries) but not the time lost to data friction. That's where most of the value disappears. Without measuring capacity drain, ROI can't be calculated. It can only be assumed.

How can I reduce data team costs?

Find the low-impact initiatives. Cut the time wasted on manual work, duplication, and delays. The goal isn't fewer headcount. It's recovering the capacity that's currently trapped in friction.

What is a good data ROI metric?

Start by measuring recovered capacity. FTE time saved. That gives you a number you can audit, instead of guessing at revenue attribution.

Should I reduce my data team size?

Probably not. In most cases the issue isn't headcount, it's how that capacity is being spent. Recover the wasted time before you cut the investment.

Do I need to clean my data before we talk?

No. Waiting for 'perfect' data is the most expensive mistake a CEO can make. Start with what you have. The first job is to make the cost visible — what the portfolio is actually spending. Everything else follows from having that number.

Decision Architecture vs. Data Architecture

Most data strategy decks I have read in the last decade open with the same diagram: sources, ingestion, storage, transformation, semantic layer, BI, consumers. Boxes and arrows. The argument is that if you build this stack correctly, decisions will follow. They will not. They almost never do. And the reason is that the diagram describes a data architecture, and the company's actual problem is that it lacks a decision architecture.

The two architectures, distinguished

Data architecture answers: where does data come from, where does it live, how does it move, how is it modeled? It is a technical discipline. It is well-taught, well-tooled, and well-funded. Most data teams are excellent at it.

Decision architecture answers a different question: which decisions does this company need to make, who owns each one, what evidence do they need, and on what cadence? It is a strategic discipline. It is rarely taught, almost never tooled, and almost always under-funded. Most data teams have never been asked to do it.

The pathological case, and it is the common case, is a company with a beautiful data architecture and no decision architecture. The result is a portfolio that produces information at industrial scale and decisions at artisanal scale.

How to spot the mismatch

Five symptoms, any of which should trigger a decision-architecture conversation:

Dashboard sprawl with low repeat-use. If 50%+ of your dashboards have not been opened in 90 days, you are producing answers to questions nobody is asking on a recurring basis. The data architecture is fine. The decision architecture is missing, nobody specified which decisions the dashboards were supposed to support.
Every decision triggers a new analysis. Healthy organizations build evidence for recurring decisions and treat one-off analyses as exceptions. If every decision is bespoke, the decision architecture has not been mapped.
The data team is in a queue. Tickets, requests, "can you pull X." The data team becomes a service desk. This is what happens when nobody has decided in advance which decisions need ongoing evidence, so every decision shows up as a ticket.
Metrics are debated, not used. If the same five metrics are re-defined in each meeting, the decision architecture has not specified the evidence basis for each decision.
"We have the data, but…" The most expensive sentence in a data portfolio. It means the data exists; it just was not connected to a decision. The data architecture worked. The decision architecture was never built.

What a decision architecture looks like

It is not a stack diagram. It is a map with three columns:

Decision, the recurring choice the business must make. ("Which markets get incremental marketing budget this quarter?")
Owner, the single person accountable for making it.
Evidence, the specific numbers, with their definitions, that the owner needs to make the decision well.

That is the entire artifact. For a typical growth-stage company you will end up with 30–60 recurring decisions on the map. The exercise of producing the map is the work, the document is a side effect.

Why this changes the data team's job

With a decision architecture in hand, the data team's queue collapses. Instead of a service desk, they become the owner of the evidence layer for each mapped decision. New requests get evaluated against the question: does this serve a mapped decision, or is it a new decision we need to add to the map? If neither, it does not get built.

That single filter is what reduces dashboard sprawl, kills the Invisible Tax, and converts the data team from a cost center into something the CFO can actually defend.

Why companies skip this step

Three reasons:

It feels less impressive than buying tools. A new data warehouse is visible. A decision map is a Notion page. Boards reward the visible.

It requires the business to commit to which decisions matter. Most leadership teams resist this, it forces them to admit that some decisions they currently spend a lot of evidence on are not actually decisions, and others they make on gut feel should have evidence. Both are uncomfortable.

The data team usually does not have a mandate to drive it. Decision architecture is a strategy job. It needs sponsorship from the CEO or COO, not from the head of data. Without that sponsorship, the data team builds tools instead, because that is what they are allowed to do.

The order of operations

If you are starting from scratch, the order is:

Map the recurring decisions (decision architecture).
Define the evidence each one requires (semantic layer of the decisions).
Build the data architecture to serve that evidence, and only that evidence, first.
Treat everything else as exceptions, not as the default workload.

If you are starting from an existing data architecture (which most companies are), the order is:

Map the recurring decisions.
For each existing dashboard / pipeline / metric, ask: which mapped decision does this serve?
The ones that serve no mapped decision are candidates for retirement. Most of them should be retired.
The ones that serve a mapped decision are your real portfolio. Invest in them.

The CEO version

If you are the CEO and you do not have time for the full mapping exercise, ask your data leadership a single question: What are the ten most important recurring decisions this company makes, and what evidence do we currently provide for each?

If they cannot answer in fifteen minutes, you do not have a decision architecture. The conversation about how to build one is the most valuable hour you will spend on data this year.