- Runs against
- How a change reaches production today
- Measured on
- Four measures, in two opposing pairs
- You get
- Environments in code, and a rota that works
The gap between merged and running
A change is not delivered when it is approved. It is delivered when it is running, and somebody can tell whether that made things better or worse. The distance between those two points is where most delivery problems actually live.
It usually shows up as a set of small, tolerated frictions: an environment only one person can rebuild, a deploy step that is really a person, alerts tuned to CPU rather than to anything a customer would notice, and a rota that is one engineer’s phone. None of those is an outage. Together they set how fast the team can move and how badly it hurts when something breaks.
So the work is to make the path explicit: infrastructure described in code, pipelines that deploy it, and monitoring tied to what you actually promised.
What the work covers
- Infrastructure as code Terraform, Ansible and Crossplane, so an environment is a file with a history rather than a configuration someone remembers making.
- Pipelines Build, test, deploy and rollback defined in the repository, so a production change is a reviewed pull request rather than a person with credentials.
- Service level objectives What “healthy” means for each service, written down, with the alerts tied to those definitions instead of to CPU graphs nobody acts on.
- On-call as a system, not a person A rota, runbooks, an escalation path, and a review of every page that fired — including the ones that should not have.
- Access and secrets Who can reach production and with what — least privilege, credentials that expire, and secrets held outside the repository rather than in it.
- Cost and capacity Spend attributed to services and environments, so a rising bill has a name against it rather than a quarterly surprise.
Rollback and restore are different controls and teams routinely have only one. Rollback undoes a deployment and is bounded by your pipeline; restore recovers data and is bounded by your backups, which is a longer number and usually an untested one. The diagram above shows the first. We test the second, because “time to restore service” quietly means whichever of the two you actually need.
How the engagement runs
Four stages, each ending in something you keep. No weeks are attached: the length depends on what the baseline finds, which is the point of measuring it first.
- Stage 1 Baseline How a change reaches production today, timed end to end. What breaks, how often, and who gets woken up. Measured rather than estimated, because the estimate is always optimistic. You get: the four delivery measures for your current pipeline, as they stand.
- Stage 2 Codify Environments described in code and reproducible from the repository, starting with the one whose loss would hurt most. You get: environments you can rebuild without the person who built them.
- Stage 3 Pipeline Build, test, deploy and rollback automated, with the rollback exercised before it is needed rather than during the incident that needs it. You get: a deploy that is a merge, and a rollback you have run.
- Stage 4 Operate Objectives written, alerts tied to them, rota and runbooks in place, and then handover — to your team, or we hold the pager while they learn it. You get: objectives, alerts that mean something, and a rota with runbooks.
What you leave with
- The baseline, and the same numbers after — the only honest way to say whether any of this worked.
- Environments in code — Terraform, Ansible and Crossplane, in your repository.
- A pipeline with a rehearsed rollback — and the record of it running.
- Objectives, alerts and runbooks — plus the page-review habit that keeps them worth having.
How you will know it worked
Unlike our agent work, we have not published a method for this one, so we will not pretend to cite ourselves. What we use instead is the public standard: the four delivery measures — deployment frequency, lead time for changes, change-failure rate, and time to restore service. We take them at the start, and we take them again at the end.
Those four are not a scorecard. They are two pairs that pull against each other: the first two say how fast work reaches users, the second two say what it costs when that goes wrong. A team pushed on speed alone will ship smaller, riskier changes faster and quietly damage the other pair. A team pushed on safety alone will ship less, which improves the numbers for the wrong reason. Taken together they are difficult to game, and that is the only property that makes them worth taking at all.
What we do argue in public is that the unit of measurement should be completed work rather than activity. Applied to operations that means cost per verified incident, time to mitigation, false-positive rate, approval latency and change-failure rate — the same argument, one layer down.
The access half has a published argument too, about a different workload. We say an agent should get the smallest environment in which it can complete the task, with credentials scoped and short-lived, and that it should never inherit more authority than the work requires. A deployment pipeline is a process acting on production with borrowed credentials. The reasoning does not change because the actor is a CI runner rather than a model.
Tell us how long it takes a one-line change to reach production, and how you know. If the second half is harder than the first, that is the baseline talking.
Talk to usRelated services
GitOps Operations
Streamline your application management with our GitOps services.
Migrate to Cloud
Seamlessly migrate to the cloud with our expert guidance and support.
Product and MVP Engineering
Design it, prove it with an MVP, then build the software that outlives the prototype.