Scale ScoreThe DevOps maturity model
A DevOps maturity model describes how capable an engineering organisation is at building, testing, releasing and running software. The point is not the label. The point is that it gives you a fixed scale, so "our delivery process is fine" becomes a claim you can check rather than an opinion you have to trust.
The levels below assume everything beneath them. That is what makes it a ladder rather than a menu, and it is why skipping rungs does not work: automated deployment without automated tests just ships bugs faster.
Level 0: Table stakes
Can the team change the code safely at all?
- Everything is in version control
- Work happens on short-lived branches, not directly on main
- Changes go through review before merging
- Automated tests exist and run before merge
Roughly a third of teams do not fully clear this level. The usual gap is inconsistent code review rather than missing tests.
Level 1: Intermediate CI
Does the build catch obvious mistakes before a human does?
- Linting and static analysis run on every pull request
- Regression tests cover past bugs
- Code coverage is measured and visible
Teams strong at Level 0 but missing Level 1 ship breaking changes regularly. Users find them instead of the test suite.
Level 2: Continuous delivery
How often can a small change reach production safely?
- Merging triggers an automatic deploy to staging
- Smoke tests run against staging before promotion
- Production deploys are a button press, not a runbook
- Deploys cause little or no user-facing downtime
This is the level that most determines whether an acquirer's roadmap is achievable, and the one buyers probe hardest.
Level 3: Observability
When something breaks, do you find out before your customers?
- Infrastructure and application dashboards exist and are watched
- Alerts route to someone who is actually on call
- Logs are centralised and searchable
The clearest tell is how the team learned about their last significant outage. If the answer is a customer email, this level is not in place.
Level 4: Advanced CI
Do you know what is in your software and whether it is safe?
- Dependencies are inventoried and scanned
- Vulnerability scanning runs continuously, not annually
Rarely reached before a company has enterprise customers forcing the issue, and a common source of diligence surprises.
Level 5: Advanced CD
Is the whole pipeline itself managed as a product?
- Dynamic analysis in the pipeline
- Deployment notifications and ChatOps
- Server configuration managed as code
Genuinely optional for most companies. Absence here is not a finding; presence is a strong positive signal.
How to place a team honestly
Self-assessment against a maturity model fails in a predictable way: people score the process they designed rather than the one that runs. Three things make it more honest.
- Ask for the number, not the practice. "How many production deploys last month?" is checkable. "Do you practise continuous delivery?" is not.
- Ask more than one person, separately. The gap between how a CTO and an engineer describe the same release process is often a full level, and that gap is the most useful thing the exercise produces.
- Anchor on the last real incident. How the team found out, how long recovery took, and what they changed afterwards tells you more about Levels 2 and 3 than any list of tools.
Where this gets used
Maturity models show up most often in two places: internally, when a team is deciding what to improve next, and in technical due diligence, where a buyer needs to compare one target against another on a consistent scale. The delivery sections of most technical due diligence checklists map onto Levels 0 through 3.
If you want the same framework presented as a self-scoring benchmark rather than as a model, see the engineering practices benchmarks. For the outcome metrics that sit alongside it, see engineering KPIs.