The Automation Maturity Model
Five honest stages of automation maturity, what each one feels like from inside a team, and how to move up one level at a time.
Maturity models are frequently used badly — as a scorecard to wave at leadership. Used well, they do one useful thing: they tell you which single constraint is currently holding you back, so you stop spreading effort across five initiatives that cannot pay off yet.
The five stages
flowchart LR
S1["1. Manual<br/><small>documented runbooks</small>"] --> S2["2. Scripted<br/><small>ad-hoc scripts, run by hand</small>"]
S2 --> S3["3. Orchestrated<br/><small>pipelines, triggered by events</small>"]
S3 --> S4["4. Declarative<br/><small>desired state, continuous reconciliation</small>"]
S4 --> S5["5. Self-managing<br/><small>detects, decides, remediates, reports</small>"]
Stage 1 — Manual
Work is performed by people following documentation, if documentation exists. The characteristic symptom is that outcomes vary by operator. Two engineers deploy the same release and get different results.
The constraint here is knowledge, not tooling. Before scripting anything, write down what is actually done — including the undocumented steps experienced operators perform from memory. Half of stage-1 automation failures come from scripting the documented process rather than the real one.
Stage 2 — Scripted
Individual steps are scripted, but a human decides when to run them and in what order. Scripts live in personal directories or a shared drive, and often only run correctly on their author’s machine.
The constraint is reproducibility. The move to stage 3 is less about writing more scripts than about giving the existing ones a home: version control, dependency declaration, a defined execution environment, and a way to run them that is identical for everyone.
Stage 3 — Orchestrated
Steps are composed into pipelines with defined inputs, ordering, and failure handling, triggered by events rather than by people. This is where most organizations sit, and it is a genuinely good place to be.
The constraint is drift. The pipeline correctly applies changes, but nothing verifies that the system stayed the way the pipeline left it. Somebody makes an emergency console change, and the next pipeline run either overwrites it unexpectedly or fails on unexplained state.
Stage 4 — Declarative
The system is described as desired state, and a reconciler continuously drives reality toward that description. Manual changes are detected and either reverted or surfaced. This is the operating model described in The GitOps Operating Model.
The constraint is decision-making. The system can apply any state you declare, but a human still decides what state to declare and when — including during incidents at 3am.
Stage 5 — Self-managing
Defined classes of condition are detected, decided upon, and remediated without human involvement, with humans receiving a report rather than a page. Crucially, this is never global: it applies to specific, well-understood failure classes. See Self-Healing and Auto-Remediation.
Stage 5 is not “no humans”. It is “humans handle the novel, machines handle the known”.
What each stage feels like from inside
| Stage | Deploy on a Friday? | New engineer productive in | Recovery from a bad change |
|---|---|---|---|
| 1 Manual | Absolutely not | Weeks; depends on shadowing | Hours; depends who is available |
| 2 Scripted | Only with the right person online | Days, once they get the scripts working | Under an hour if the script works |
| 3 Orchestrated | Yes, with care | Days | Minutes, via pipeline rollback |
| 4 Declarative | Routinely | Hours | Minutes, via revert commit |
| 5 Self-managing | Without discussion | Hours | Often before anyone notices |
The “new engineer productive in” column is the most reliable indicator of true maturity, and the hardest to fake. Onboarding time measures how much of the system lives in code versus in people’s heads.
Moving up one stage
Two rules make the transition survivable.
Do not skip stages. Teams that jump from stage 2 to stage 4 build declarative systems on top of processes nobody has stabilised. The reconciler faithfully enforces a state that is subtly wrong, everywhere, continuously.
Move one workflow at a time, not the whole estate. Pick the delivery path for one service, take it from stage 2 to stage 3, and let that team’s experience generate the patterns the next team copies. Estate-wide transformations produce estate-wide rollbacks.
flowchart TD
A[Pick one workflow<br/>with fast feedback] --> B[Move it up exactly one stage]
B --> C[Run it long enough to<br/>hit its real failure modes]
C --> D{Stable?}
D -->|No| C
D -->|Yes| E[Extract the reusable parts<br/>into a shared module/template]
E --> F[Apply to the next workflow]
F --> B
Honest self-assessment questions
Ask these rather than filling in a scorecard:
- If the person who built our deployment path left tomorrow, could we deploy?
- When did we last restore from backup, and did it work?
- Can we tell whether production matches what is in version control right now?
- How many production changes in the last month bypassed the pipeline?
- What percentage of pages last month required a novel decision, versus following a known runbook?
The last question is the clearest signal of stage 4 versus stage 5. If most pages resolve by following a documented procedure, that procedure is a remediation candidate.
Adoption checklist
- Current stage assessed per workflow, not per organization.
- One workflow selected as the pilot for the next stage.
- The real process (including undocumented steps) has been written down.
- Onboarding time is tracked as a maturity indicator.
- Percentage of changes bypassing the pipeline is measured.
- No stage is being skipped.
Last updated 19 Aug 2026, 00:00 UTC.