The DevOps Maturity Model: A Practical Framework for Self-Assessment

Most teams that call themselves "doing DevOps" are actually somewhere in the middle of a maturity curve, not at either end of it. Knowing where you sit on that curve — and what specifically blocks the next stage — is more useful than any tool comparison, because the same tool produces very different results depending on how mature the team using it is.

Quick Answer

A DevOps maturity model has five broad stages: ad hoc (manual deployments, no monitoring, tribal knowledge), managed (version control and basic CI exist but deployments are still manual and risky), defined (CI/CD pipelines, infrastructure as code, and a documented process everyone follows), measured (DORA metrics tracked and used to drive decisions, proactive monitoring and alerting), and optimizing (continuous improvement is itself automated and instrumented — the team tunes its own pipeline based on data, not opinion). Most organisations are stuck between "managed" and "defined," and the blocker is almost always process and ownership, not tooling.

Written by [Neil Millard](/about), a cloud and automation specialist with 20+ years' experience delivering infrastructure for organisations including Barclays, HMRC, Marks & Spencer, and AXA.

Why a Maturity Model, Not Just a Checklist

A checklist tells you whether you have a tool. A maturity model tells you whether that tool is actually changing outcomes. A team can have Jenkins, Terraform, and Prometheus installed and still be firmly at "ad hoc" maturity if deployments are still manual, infrastructure changes are still made by hand against the config the pipeline claims to manage, and nobody looks at the dashboards until something is already on fire. Maturity is about behaviour and process consistency, not tool inventory.

The Five Stages

1. Ad Hoc

Deployments happen manually, usually by whoever is available and knows the steps from memory. There is no automated testing gate before code reaches production. Monitoring, if it exists, is reactive — someone notices the site is down because a customer complained. Configuration lives on individual servers, not in version control. Knowledge of "how this actually works" lives in one or two people's heads.

Signs you're here: deployments require a specific person to be online; there is no rollback procedure faster than "redeploy the old version by hand"; nobody can tell you the last time a deployment failed because failures aren't tracked.

2. Managed

Source code is in version control (this stage genuinely doesn't exist without it). Some form of continuous integration runs tests automatically on commit or pull request. However, deployment is still a manual, often risky, step — someone SSHes into a server or clicks a button in a way that isn't fully repeatable. Infrastructure is provisioned by hand or via ad hoc scripts rather than a declarative tool.

Signs you're here: CI is green but "deploy day" is still a stressful, manual event; infrastructure changes are made directly in the cloud console and then, maybe, retroactively documented.

3. Defined

A real CI/CD pipeline exists: commit triggers build, test, and an automated (or one-click) deployment to production, following a documented, repeatable process — see what is deployment pipeline and why does it matter for what that pipeline typically looks like. Infrastructure is defined as code (Terraform, CloudFormation, or similar) rather than click-ops. The process is consistent enough that a new engineer can follow it from documentation rather than needing to shadow someone.

Signs you're here: anyone on the team can deploy without help; a fresh environment can be recreated from code, not from memory of "what we did last time."

4. Measured

The team tracks the DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — and actually uses them to prioritise work, not just to report them upward. Monitoring and alerting are proactive: the team finds out about degradation before customers do. Post-incident reviews happen and produce concrete follow-up actions, not just a summary.

Signs you're here: you can answer "how long does it take a change to reach production" with a number, not a guess; alerts fire on leading indicators (error rate creeping up), not just hard outages.

5. Optimizing

Improvement itself is instrumented and continuous: the team uses its own metrics to identify the next bottleneck (a slow test suite, a manual approval gate that adds two days for no safety benefit, a flaky deployment step) and fixes it as routine work, not as a special initiative. Feedback loops from production (feature flags, canary analysis, real user monitoring) feed directly back into what gets built next.

Signs you're here: the pipeline itself has an owner and a backlog, the same as a product; the team can point to a specific metric that improved as a direct result of a specific process change.

How to Self-Assess

Be honest about the stage of your slowest significant process, not your best one. A team with excellent CI/CD for application code but manual, undocumented database migrations is not at "defined" maturity overall — it's at whatever stage the migration process is at, because that's where the risk concentrates. Walk through a recent deployment and a recent incident and ask, at each step, "was this automated, documented, and repeatable, or did it depend on a specific person knowing something?"

If you want a structured version of this rather than a self-guided walkthrough, there's a short DevOps maturity assessment that scores this across the same dimensions.

Common Blockers Between Stages

Ad hoc → Managed: usually a tooling gap (no CI configured yet) combined with a trust gap — someone doesn't believe automated tests will catch what they catch manually. The fix is incremental: automate the tests that already exist before insisting on more coverage.

Managed → Defined: almost always an ownership gap, not a tooling gap. Teams often have all the pieces (CI exists, Terraform exists) but nobody has been given the mandate to wire them together into one pipeline, so each service does it slightly differently.

Defined → Measured: teams frequently skip straight past this because DORA metrics sound like reporting overhead rather than a decision-making tool. The blocker is cultural: metrics need to inform prioritisation (e.g., "our change failure rate is high, so we're investing in better staging tests this sprint") or they become a dashboard nobody looks at.

Measured → Optimizing: this stage requires slack — time not fully consumed by feature delivery — to actually act on what the metrics reveal. Teams permanently running at 100% feature-delivery capacity rarely get here regardless of how good their metrics are.

Where This Fits Into a Wider DevOps Programme

Maturity assessment is a starting point, not an end in itself — pair it with the practical checklist in DevOps best practices once you know which stage you're actually working from, since the highest-leverage next step is different at each stage (a team at "ad hoc" needs CI before it needs better monitoring; a team at "measured" needs the opposite).

If you'd rather talk through where your team actually sits and what the highest-leverage next step is, that's exactly what an office-hours call is for.