Modernization
Engineering Practice3 min read
DevOps maturity, without the maturity model
Five questions that tell you more about a delivery process than any scored assessment, and what to fix first depending on the answers.
Working on something like this?
Get an estimateThe short version
- Time to rollback matters more than time to deploy. It sets the floor under every incident.
- If staging and production differ in ways nobody can enumerate, staging is theatre.
- Alert volume that people mute is worse than no alerting: it trains the team to ignore signal.
- Fix the step that causes the most incidents, not the step that scores worst.
Maturity models produce a number, a radar chart, and very little disagreement about what to do on Monday. These five questions produce arguments, which is more useful.
1. How long from merge to production?
Not how long the pipeline runs — how long from a change being approved to it being in front of users. If the honest answer includes a weekly release window, a change advisory meeting, and a manual smoke test, the pipeline duration is not your problem.
Long lead times are usually made of waiting rather than work. Map every step and mark which ones are a person waiting for another person.
2. How long to undo it?
This is the question we would ask if we could only ask one. Time to rollback sets the floor under the severity of every incident you will ever have — a defect that can be reversed in thirty seconds is an inconvenience, and the same defect behind a twenty-minute redeploy is an outage. It scales to whole events: a carrier porting 18,000 numbers gave each of nine batches its own rollback, and three of them used it without a customer noticing.
What good looks like
- Application changes reversible by a flag toggle, not a redeploy
- Infrastructure changes reversible by reverting a commit and reapplying
- Database migrations that are backward compatible for at least one release
- Someone other than the author able to perform the rollback
3. Can you rebuild staging from scratch?
If the answer is no, or takes a week, then staging has drifted and the confidence it provides is imaginary. The value of a pre-production environment comes entirely from its resemblance to production, and resemblance decays every time someone makes a manual change.
It works in staging is only meaningful if staging is a copy of production rather than a distant relative.
4. Who finds out first when something breaks?
There are three answers, in descending order of maturity: an alert, a dashboard someone happened to be watching, or a customer. Most teams believe they are in the first category and discover during a postmortem that they were in the third.
The follow-up matters more: how many alerts fired last month, and how many led to action? An alert stream people have learned to ignore is worse than silence, because it trains the team to dismiss the one that mattered.
5. What happens at 3am?
- Is there a rota, or is there one person everybody actually calls?
- Is there a runbook for the failures you have already seen twice?
- Does the person on call have permission to fix it, or only to wake someone who does?
- After the incident, does anything change — or is the postmortem a document?
What not to do first
Do not adopt Kubernetes to fix a delivery problem. Do not replace a working pipeline because a different tool is fashionable. Do not introduce a new observability platform while nobody is acting on the alerts from the existing one. Each of these is a project that feels like progress and defers the actual fix by a quarter. Where the infrastructure and the pipeline genuinely both need work, buy them as one engagement rather than two.
If you want the delivery-side detail, our DevOps services page sets out how we approach pipelines, infrastructure as code, and on-call practice — and Kubernetes consulting includes the section on when not to use it at all.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Often enough that a deploy is unremarkable. The frequency itself is a proxy — what matters is that changes are small, reversible, and not batched into risky quarterly releases. Teams deploying daily are usually shipping small changes safely; teams deploying quarterly are usually shipping large ones dangerously.
No, and adopting it for that reason usually sets you back. Maturity is short lead times, fast rollback, matching environments, and alerting people trust. All four are achievable on managed containers or plain virtual machines, and a cluster nobody has capacity to operate makes each of them worse.
Deployment frequency, lead time for changes, change failure rate, and time to restore service. They are a genuinely useful shared vocabulary, provided they are used to find bottlenecks rather than as targets to be gamed — deployment frequency in particular is easy to inflate by splitting changes meaninglessly.
The first meaningful improvement is usually weeks rather than months, because the highest-value fixes — scheduled non-production, a real rollback path, alerting on symptoms rather than metrics — are small. Rebuilding environments as code and changing on-call culture take longer, and the culture part is the slower of the two.