The Data Team Maturity Ladder

Here is a claim that will annoy every process owner who reads it:

The majority of maturity initiatives I audit are not maturity initiatives.

They are organizations reaching for the controls of a mature company without building any of the capabilities those controls assume exist.

I wrote recently about a director who announced a blanket 24-hour lead time on change tickets and called it “an organizational maturity step” (that piece is A Calendar Is Not a Control, and this is its bigger brother). The rule was bad, but the rule isn’t the interesting part. The interesting part is what that organization looks like underneath the rule.

No CI/CD in the data team. No true orchestration, just jobs firing on timers and hope. No access request flow, so permissions travel by DM and goodwill. No standardized change intake, so every ticket is a different shape. And governance that means something different in every department that says the word.

Now re-read the policy… every change must be submitted 24 hours in advance for review.

Review what, exactly? There’s no pipeline producing a diff. No deployment history to compare against. No dependency graph to check blast radius. No access model to verify who can even touch the thing. The board is being asked to inspect a shipment with no manifest, no packing list, and no seal on the container.

You can’t govern what you can’t diff.

That single sentence is why maturity is sequential with dependencies… just like your pipeline. Skip the sequence and every downstream control fails silently, because the artifacts it was designed to inspect were never built.

The Ladder

I use a five-stage ladder when I audit an organization’s operating maturity. It applies to IT broadly, but I’m going to walk it as a data team ladder, because data teams are where I keep finding organizations standing on rung one while announcing rung-four policies.

Two rules about the ladder before we climb it. First, you cannot skip rungs. Each stage produces the raw material the next stage consumes. Second, the most dangerous place on the ladder isn’t the bottom. It’s the stage where things feel orderly, because feeling orderly kills the budget appetite for becoming safe.

Stage 1: The Cowboy Stage

You know you’re here when: changes go straight to production, the deploy process is “Dave does it,” and the incident response plan is Dave’s cell number.

There’s no version control worth the name, no separation between where you experiment and where the business runs, and knowledge lives in heads instead of repos. If you’ve read The 10-Year Junior, you’ve met the residents: capable people who’ve been allowed to operate without discipline for so long that the org can no longer tell the difference between experience and tenure.

The stage-one organization isn’t lazy. It’s usually fast, and that’s the problem. Cowboy shops deliver quickly right up until the day they don’t, and then nobody can reconstruct what changed, when, or why. The business reads that day as “the data team is unreliable.” The truth is the organization never bought reliability. It bought speed on credit, and the invoice arrives as an outage.

The way out: version control on everything, environment separation, and a rule with no exceptions: if it isn’t in Git, it didn’t happen. This is not a tooling purchase. It’s a behavioral one.

Stage 2: The Paperwork Stage

You know you’re here when: there are forms, tickets, lead times, and a recurring meeting, and none of them have ever caught a defect.

This is where the organization I described lives, and it’s where most organizations stall for years. Someone senior notices the chaos of Stage 1 and reaches for the lever that’s cheapest to pull: administration. Mandatory fields. Approval chains. A 24-hour rule.

And the meetings genuinely do get calmer. That’s the trap I named the Ceremony Trap, and it’s lethal precisely because it works on the observable surface. Leadership sees order and concludes safety. But nothing about the change itself got safer, because the paperwork wraps the same undisciplined work Stage 1 was producing. The ticket is a nicer envelope on the same unreviewed contents.

Here’s the tell that separates paperwork from progress: ask when the review process last rejected something for a technical reason, and what happened next. In a Paperwork Stage org the answer is “never,” or worse, “once, and the team just resubmitted the same thing with a longer description.”

The way out: stop investing in the envelope. Take the energy going into intake forms and spend it one rung up, on the discipline that gives the paperwork something real to describe.

Stage 3: The Discipline Stage

You know you’re here when: a change is a pull request, a deployment is a pipeline run, and “who has access to this table” is a query, not an investigation.

This is the rung the organization above skipped entirely, and it’s the load-bearing rung of the whole ladder. Stage 3 is where the engineering fundamentals arrive:

• CI/CD for data work. Transformations deploy through a pipeline with tests, not through someone pasting SQL into a production notebook. Now every change has a diff, a test result, and a rollback path. Now, and only now, does a change ticket contain something a reviewer can actually review.

• Real orchestration. Dependencies are declared, not remembered. When the finance load fails, the system knows what downstream jobs to hold. Blast radius stops being folklore and becomes a graph you can query. You cannot classify a change’s risk if nobody can tell you what depends on it.

• Access request flows. Permissions granted through a request, tied to a role, with an audit trail. This one deserves a hard look in the mirror: an organization that makes a schema change wait 24 hours for review while production access gets granted in a Slack thread is guarding the front gate of a building with no back wall. When the auditor comes, and in regulated industries the auditor always comes, the access sprawl is the finding, not the ticket lead time.

• Standardized intake. One change request shape, with required artifacts: the diff, the rollback plan, the affected assets. Not because forms are virtuous, but because a reviewer can’t compare risk across tickets that don’t share a structure.

Notice what Stage 3 actually is. It’s the Paperwork Stage’s promises, kept by engineering instead of administration.

The way out is the way in: pick the highest-traffic pipeline, put it under CI/CD end to end, and use it as the reference implementation everything else migrates toward. Do not attempt all four fundamentals org-wide simultaneously. That’s how discipline initiatives die.

Stage 4: The Lane Stage

You know you’re here when: different changes take different paths, and the person approving a change could have personally caught its failure mode.

With Stage 3 producing real artifacts, risk classification finally becomes possible instead of performative. Standard changes get pre-approved runbooks and just flow. Normal changes get review scaled to their blast radius, and that review happens in lanes: the data platform owner approves data changes, because a generic board that can’t tell a Delta table from a dinner table approves everything and catches nothing. Emergency changes get an expedited path, because production doesn’t wait for Thursday’s meeting.

This is where the Change Lane Protocol from the companion piece lives, and this is the stage the 24-hour rule was cosplaying. The difference between a Stage 2 lead time and a Stage 4 lead time is that the Stage 4 version is a function of risk, backed by artifacts, enforced by someone competent to judge them. Same calendar. Entirely different control.

The way out, if you’re stuck here: the usual Stage 4 failure is lanes on paper with a bottleneck in practice, one heroic approver drowning in tickets. The fix is pushing more volume into the standard-change runbooks so human judgment is spent only where it compounds.

Stage 5: The Platform Stage

You know you’re here when: governance stops being a meeting and becomes infrastructure.

The controls move into the platform itself. The pipeline blocks the deploy that fails tests; no human needed. The catalog enforces who reads what; access review is a report, not a project. Change failure rate is tracked and correlated to incidents, so the organization can finally answer the only question that matters about its own process: is this working?

If you’ve read The Medallion Masterclass, you already know the destination: governance is the architecture. Stage 5 is that principle applied to how change itself moves through the organization. The board still exists up here, but it has been demoted to what it was always good at, coordination and cross-team trade-offs, and relieved of the gatekeeping job it was never equipped to do.

The Ladder Audit

If you suspect your organization is standing on a lower rung than its policies claim, here’s the audit. Run it before the next “maturity initiative” gets announced, not after.

1. Locate the real rung, using evidence, not aspiration. The test for each stage is behavioral: can you produce a diff for last Tuesday’s change? Can you name every downstream asset of your top pipeline without asking a human? Is there a ticket trail for the last five access grants? Wherever the evidence stops, that’s your rung. Not the org chart’s opinion. The evidence’s.

2. Name the skipped rungs out loud. Write the gap list plainly: no CI/CD, no orchestration, no access flow, no standard intake. This list is politically uncomfortable, which is exactly why it must be written down. An unnamed gap becomes a permanent one.

3. Cancel or reframe any control that assumes a rung you haven’t built. The 24-hour rule assumed reviewable artifacts. If those don’t exist, the rule is cost with no control, and honest leadership pulls it back rather than defending it. Reframe it as a Stage 4 destination: “lead times return when they have something to review.”

4. Fund the next rung only. Not a three-year transformation program. The next rung. For the organization in this piece, that’s Stage 3, starting with CI/CD on the highest-traffic pipeline and an access request flow, because those two produce the artifacts everything above them consumes.

5. Define the promotion test before you start. Decide in advance what evidence moves you up a rung, the same way you’d define a data quality gate before the pipeline runs. Otherwise “maturity” gets declared by memo again, and you’re back where this article started.

Look at what every step has in common. Each one requires somebody who can stand in front of a policy that feels like progress and correctly call it ceremony, and that judgment only comes from having watched both versions play out in production. The audit isn’t hard to read. It’s hard to run, because the person running it has to know what each rung’s failure looks like from the inside.

The Verdict

The director who announced the 24-hour rule wasn’t wrong that the organization needed to mature. The diagnosis was right and the ladder confirms it: that org has real, fundable, fixable gaps. The failure was sequencing. They ordered the security checkpoint before pouring the foundation, and now everyone will stand in line at a gate that protects nothing.

Maturity isn’t the presence of controls. It’s controls arriving in the order that makes each one real.

So before your organization announces its next maturity step, ask the ladder question: what rung does this policy assume we’re standing on, and are we actually standing there? If the answer is no, you haven’t found a maturity step.

You’ve found the gap where one should have gone.

---

Finding your organization’s real rung, naming the skipped ones in a room full of people who approved the skipping, and sequencing the climb is exactly the work Gambill Data does. We audit the ladder, not the org chart. Book a strategy call.

Coming soon for the engineers: what to do when your leadership announces a rung-four policy while you’re living on rung one, and how to push the ladder argument upward without becoming the problem.