Walk into any $100M+ company and ask the head of FP&A, the head of revenue operations, and the head of customer success where their numbers come from. None of them will name the warehouse first. They will name a spreadsheet, a Notion table, or an Airtable base maintained by a senior IC who does not report into the data function. That artifact is the operating source of truth for that team, and it has been for longer than anyone is willing to admit on the record.
This is shadow data. The default reaction from a central data team is to treat it as a governance failure to be eradicated. That reaction is wrong, and pursuing it costs the data function the trust it needs to do anything else.
Why team-built spreadsheets win
Team-built artifacts are not winning because the people who build them are reckless. They are winning because they are optimized for one thing the central data function is structurally bad at: the speed at which the operating team’s questions change.
A revenue operations leader needs to know, by Thursday, whether the new segmentation logic moves pipeline coverage in the right direction. The warehouse team can deliver that in six weeks through the proper intake process. The RevOps analyst can deliver it in an afternoon by joining the Salesforce export to a tab she maintains by hand. The afternoon answer is wrong in ways the six-week answer would not be — but it is available on Thursday, and the decision is on Thursday, so the afternoon answer is the one that runs the business.
Shadow data is the operating team telling you, in the most direct way available, where your latency is too high. The artifact is a symptom. The latency is the problem.
The stages of formalization
Not every shadow artifact deserves to be absorbed into the warehouse. Most do not. The discipline is recognizing which stage a given artifact is in and matching the response to the stage.
Stage 1: Exploratory. A single analyst, fewer than ten cells of meaningful logic, lifespan measured in weeks. The team is still figuring out whether the question is the right question. Absorbing this into the warehouse is malpractice — you are paying to formalize a hypothesis. Leave it alone. Mark it in the inventory as exploratory and revisit in a quarter.
Stage 2: Operational. The artifact has survived past its hypothesis phase. Two or three people now depend on it. The logic has accreted into formulas nobody wants to re-derive. It is being copy-pasted into deck appendices and emailed to the CFO. This is the stage where the cost of leaving it shadow starts to exceed the cost of absorbing it. The right move is a thin warehouse model — one dbt model, one downstream view, one ownership conversation — that reproduces the artifact’s outputs faithfully. Faithfully matters. If the absorbed version differs from the spreadsheet by even 1.5%, the team will keep the spreadsheet and ignore the model.
Stage 3: Load-bearing. The artifact is in the board pack. It is in compensation calculations. It is in the forecast the CFO defends to the audit committee. At this stage shadow status is no longer tolerable, but the absorption project is also no longer cheap. Treat it as you would any production system migration: dual-run for a quarter, reconcile to the cell, get the operating team’s signoff before retiring the original, and put a named owner on the canonical version. Skipping any of these steps will cost you the relationship with the team that built it, and that relationship is worth more than the artifact.
When not to absorb
The honest answer to “should we absorb this?” is “usually not yet, sometimes never.”
Three signals say leave it alone. First, the artifact’s logic is genuinely team-specific — it encodes judgment calls only that team is qualified to make, and centralizing it would force the central function to take ownership of business logic it does not understand. Second, the artifact changes faster than your warehouse release cadence; absorbing it would slow it down enough that the team would just start a new shadow artifact next to the absorbed one. Third, the artifact has a known sunset — a one-quarter initiative, a migration, an integration project — and will be dead before any warehouse model on it would pay back.
Absorption is not the goal. A high-trust relationship between the data function and the operating teams is the goal. Sometimes that means absorbing. Sometimes it means writing down, in the inventory, that this artifact is sanctioned shadow data, owned by this team, and the central function’s role is to support it rather than replace it.
The data leaders who get this right stop counting shadow artifacts as a failure metric. They count the ones the operating teams asked them to absorb. That number is the one that says the function is trusted.