You can't hand off data readiness

Every data-readiness project I have seen die, died the same way. Not at the build. At the handoff.

A practitioner sets the stack up correctly. The tables are modeled, every metric has one definition, the tests pass. Then the project is declared done, the practitioner rotates off, and the thing gets handed to whoever is nearby to keep the lights on: a general software engineer, or worse, the business stakeholder who asked for it. Six months later the dashboards are quietly wrong, and nobody can say when it happened.

This is not a tooling failure. The stack was fine. It is an operating-model failure, and it is the part almost nobody plans for.

The stack is the easy part

I have written the technical side of this already: what ready data actually looks like, the context layer that makes it usable, and the stack you build it on. Assume all of it. A modern readiness stack is a warehouse, a transformation layer in version control, one semantic layer that defines every metric exactly once, tests and contracts on the data, lineage across the whole thing, and continuous integration that runs before anything merges.

You can assemble all of that in a week, and the pieces are mostly free now. That is exactly why it is not the hard part. The stack encodes judgment, and judgment does not ship with the repo.

Put simply: The tools are commoditized and the setup is a known quantity. What is scarce is the person who keeps it correct after the setup is done.

The non-negotiables

Before roles, the stack itself has a short list of non-negotiables. Each one exists to prevent a specific kind of rot, and skipping any single one is what makes a stack impossible to maintain by anyone but its author.

• Everything in version control, nothing changed by hand. A change you cannot see is a change you cannot review or undo.
• One semantic layer, one definition per metric. The moment revenue is redefined in three downstream places, correctness becomes unknowable.
• Tests and contracts on every asset. Freshness, uniqueness, referential integrity, and the business rules a schema cannot express.
• Lineage end to end, so the blast radius of a change is visible before you make it.
• Continuous integration that blocks the merge. A failing test that only warns is a test that does not exist.
• A named owner on every asset. An orphan table is a liability with a query bill.

Notice what these have in common. None of them makes the stack run. They make it safe to change by someone who did not build it. That is the whole point of them, and it is also their limit.

Put simply: The non-negotiables lower the bar to contribute. They never remove the need for someone who holds the definition of correct.

Why you can't hand it off

The chart at the top of this page is the mistake, drawn. Here is why it bends the way it does.

While the practitioner owns the stack, readiness stays high, because correctness is a living judgment they keep applying: this join is valid, that metric means net and not gross, this edge case is real and that one is noise. Almost none of that is written in the code, because most of it cannot be. It lives in the person.

Hand the stack to a general software engineer and the pipes stay green. Jobs run, tests pass, nothing throws an error. What the engineer cannot see is that a definition has quietly gone stale, because catching that requires knowing what the number is supposed to mean in the first place. The dashboards keep rendering. They are just wrong now, and the wrongness compounds in silence.

Hand it to the business stakeholder who wanted it, and the failure is faster and worse. They can read the output and sense when a number looks off, but they cannot safely change the thing that produces it. So the stack freezes. Nobody touches it because nobody can, and the real analysis migrates back into the shadow spreadsheets the stack was built to kill.

Put simply: A software engineer keeps it running while it goes wrong. A stakeholder keeps it unchanged until it is abandoned. Neither can keep it correct, because correctness was never in the code.

Who owns what

The fix is not to hire more people. It is to match each responsibility to the role that can actually hold it.

• The practitioner (analytics engineer, data product manager) owns semantic correctness: what each metric means, which grain, which joins are legal. This is the product, and it cannot be delegated. When they rotate off, ownership transfers to another practitioner, not to a generalist.
• The platform or software engineer owns reliability: orchestration, infrastructure, performance, the CI plumbing itself. Real and necessary work, but it is keeping the stack up, not keeping it right.
• The business stakeholder owns definitions as requirements and validation. They say what a metric should mean, and they are first to notice when it looks wrong. They contribute intent and acceptance, not code.
• The data-literate analyst contributes through reviewed pull requests, inside the guardrails the non-negotiables create. They can extend the stack. They do not own its core.

The anti-pattern is any arrow that points correctness at the wrong box: the engineer asked to maintain meaning, the stakeholder asked to maintain anything.

Put simply: Reliability and correctness are different jobs. Give reliability to the engineer, correctness to the practitioner, definitions to the business, and let everyone else contribute through the front door.

How to actually run it

So the operating model is not a handoff. It is a standing capability with an owner whose name you can say. Concretely:

• Keep a practitioner accountable for correctness for as long as the stack exists, not just until launch. Readiness is a role, not a milestone.
• Let anyone contribute, but only through the non-negotiables: a pull request, a passing test, a review by the owner. The guardrails are what make wide contribution safe.
• Give the business a fast path to flag and a slow path to change. They should be able to say "this looks wrong" in a minute, and change what produces it only through review.
• Treat the semantic layer as the one place a definition lives, and defend it. Every re-derivation downstream is a future silent error.

Put simply: Readiness survives when contribution is wide and ownership is narrow. Everyone can push on it; one role is accountable for whether it is right.

What it adds up to

Data-readiness projects rarely fail on the stack. The honest failure rates trace to data that was never ready in the first place, and the handoff is how data that was ready slides quietly back to unready. A stack is judgment made runnable, and judgment needs a keeper. You can commoditize the tools, and you should. You cannot commoditize the owner.

Put simply: Do not scope data readiness as a project you finish and hand off. Scope it as a capability you staff. The stack is the cheap part. The person who keeps it correct is the whole thing.