A maturity model people didn't roll their eyes at

“Software maturity model” is a phrase that makes good engineers reach for the exit. They’ve seen it before: a spreadsheet of virtues handed down from somewhere, scored once, filed, and never thought about again. I inherited a maturity model concept that had been drafted and never actually implemented, reworked the whole thing, built the review process around it, and drove it across the org. The difference between the version that worked and the usual version that dies is worth writing down.

Define maturity as something measurable

The first trap is defining maturity as a pile of best practices, because then it’s a matter of taste and everyone argues. We defined it as a single question: how long does it take, on average, to get a feature from conception to safe production? That maps cleanly onto the DORA Four Key Metrics, and it reframes maturity as something you can actually feel, velocity with safety, rather than a compliance checklist.

From there we defined six discrete levels, from initial proof-of-concept up through full automation, with concrete requirements at each: repositories and PR approvals, then real tests and monitoring, then staging and canary, then proactive prevention, and so on. The levels had to mean something to both engineers and non-technical stakeholders, and the requirements had to be broad enough to apply across wildly different tech stacks and team sizes. Specific enough to be real, general enough to be fair.

Don’t make everyone aim for the top

The second trap is demanding that every project reach the highest level. That’s how you turn a useful tool into a tax. In the real world, a low-traffic internal tool and a customer-facing system carrying live load do not deserve the same investment in maturity.

So we set target levels per project, based on business criticality, exposure, and roadmap. The gap between a project’s current level and its target level is what tells you where to spend. A scrappy internal service at a modest level might already be exactly where it should be. A critical system below its target is where the attention goes. That single move, targets tuned to risk, is what made the model feel like help instead of judgment.

Run a real review, not a one-time audit

The third trap is scoring everything once and walking away. We stood up a recurring review panel where teams presented their projects, and the panel assigned both the current and target level and, more importantly, pointed to other teams who had already solved the same gap. That last part is the quiet superpower: the model became a way for teams to learn from each other instead of each rediscovering the same lessons in isolation.

The lesson

A maturity model isn’t a document, it’s a habit. Tie it to a metric people believe in, set targets by risk so it’s proportional instead of punitive, and run a recurring review that spreads solutions between teams. Do that and engineers stop rolling their eyes, because the model is finally answering a question they actually have: where should we spend our limited time to ship faster without breaking things?