Elite is now table stakes

The scoreboard changed and nobody sent a memo.

Deployment frequency, change failure rate, mean time to recovery, the metrics that meant world class for a decade, are now the floor. You used to put an elite rating on a slide for the board. Today it is the price of entry.

And the processes that earned that status have quietly flipped sign. Careful human review on every pull request, manually sequenced deployment gates, engineers owning every step from commit to production: for years those were best practices.

They are friction now.

The claim

Elite is table stakes, and the practices that got you there are the thing holding you back from what comes next.

I've always treated DORA's four keys as a smoke alarm, never a scoreboard, and this is part of why. A scoreboard tells you when you've won, whereas a smoke alarm only tells you when something is wrong. Hitting elite used to feel like winning. Turns out it was just the alarm staying quiet.

The gravity of past success

The old way felt right, produced results, and built careers, which is exactly why it pulls so hard.

Nobody defends a bad process for long. A good one is different, because it has a track record, people who are proud of it, and a story about the incident it once prevented, so it survives on merit long after the conditions that made it meritorious have gone. The review-every-change rule is the clearest case. It was the cheapest control available when one engineer wrote one change a day, and at machine volume it stops measuring anything (I've made the longer version of that argument in nobody has to approve the agent's merge). The practice did not get worse. The world moved and the practice stayed put.

It's those practices in particular for a reason. Coding was only ever fifteen to twenty-five percent of shipping software. Review, testing, deployment, integration and monitoring are the other three quarters, and that is where every elite process lives, so when generation speeds up the pressure lands there first. The things you were proudest of are sitting exactly where the new constraint is.

Being good at the old thing

I had to learn this about my own organisation.

Fifteen years of being exceptionally good at software delivery was the single biggest obstacle to becoming the company we needed to be next. Deep institutional knowledge, hard-won customer confidence, production systems at enormous scale, engineers genuinely proud of how they build.

All real. All earned. And a meaningful amount of it wrong for where we were going.

A company founded two years ago carries none of that weight and has nothing to unlearn, because it never learned the old patterns. That is why the transition is harder for the good organisations than for the mediocre ones, and why it's open-heart surgery on a running system rather than a migration.

The conversation that has to happen

Telling an engineer who spent eight years perfecting a workflow that their workflow is now a bottleneck is not a comfortable conversation. It's the one that has to happen.

The hardest sentence in engineering leadership right now is some version of: the way you've been doing this is good, and it's not enough anymore. Both halves are true. Drop the first and you've insulted someone who earned their pride, drop the second and you've told them nothing. Hard conversations work when they're plain, and this one needs both halves said plainly in the same breath.

The transformation does not happen in the announcement or in the maturity model. It happens in thousands of those small conversations, a manager sitting with an engineer and saying it out loud.

The uncomfortable middle

Expect a wildly uneven distribution, and don't treat it as a failure.

We had teams genuinely pushing into agent-driven delivery loops and teams where half the engineers were still in tab-completion mode, in the same organisation, reporting up the same chain, at the same time. The instinct is to treat the lagging teams as problems to solve under pressure: ship a mandate, set a deadline. What matters more is that each team has a clear picture of where it is, where it is going, and what the next concrete step looks like. A team that knows its next step is moving. One under a deadline with no next step is performing.

Compliance isn't the finish line

Some things genuinely are non-negotiable. Every engineer has the tooling and every engineer uses it.

But pressure alone does not produce the shift. An engineer who opens the tool because they were told to, doesn't trust it, doesn't know how to use it well, and can't see how it connects to their actual work isn't AI native. Compliant, yes. Compliance is not transformation, though, and an adoption number can't tell the two apart.

The real work sits in the middle ground: clear expectations paired with genuine support, structured time to experiment, paved paths that give people the best possible first experience, managers who can explain what's changing and why, and engineers who made the shift sharing what worked with those who haven't. Culture moves through behaviour in dense clusters, not through a mandate sent from the top.

Slow and messy. It doesn't compress into a quarter.

What I'd take from this

If you're already elite, congratulations. You've earned the right to start the harder part.

Write down the three practices your team is proudest of. For each one, ask what it was protecting against and whether the pipeline could protect against that now. Some will survive. The ones that don't are where your next year of speed is hiding, and they will be defended hardest by your best people.

That's fine, they earned the argument. Have it with them anyway.