DevOps is one of the most misused and misunderstood terms in software engineering. Ask ten engineers what DevOps means and you’ll get ten different answers. Some will say CI/CD. Some will say shared responsibility. Some will say it’s just a job title for ops people who can code.
I want to introduce a mental model that I find useful: the two scales of DevOps.
Scale 1: The Scale of Development
The first scale is about developer flow — how fast and how safely can your engineering organisation ship software?
Key metrics (from the DORA research):
- Lead Time for Change — from commit to production
- Deployment Frequency — how often you deploy
- Change Failure Rate — how often deployments cause incidents
The Scale of Development encompasses everything that affects these metrics:
CI/CD
The pipeline that takes code from commit to production. Build, test, scan, deploy. The goal is to make this fast, reliable, and automated. A slow CI/CD pipeline kills flow.
Developer Experience (DX)
Everything that affects a developer’s ability to work effectively: local development environments, tooling, documentation, onboarding, cognitive load of the codebase.
A team with poor DX will move slowly regardless of how good the pipeline is.
Flow Efficiency
Derived from Lean manufacturing. Of the total time from “idea” to “shipped”, what fraction is actual work vs waiting? In most organisations, the ratio is terrible — 10-20% active work, 80-90% wait time (in queues, review, etc.).
Improving flow efficiency often has more impact than improving individual speed.
Emergent Design
In fast-moving systems, big-upfront design doesn’t work. You need the capacity for continuous, incremental design improvement — refactoring, abstraction, simplification — as a first-class engineering activity.
Scale 2: The Scale of Life
The second scale is about production reliability — when things are running in production, how do you keep them running?
This is the domain of Site Reliability Engineering (SRE).
Key metrics:
- MTTD — Mean Time to Detect (how fast do you know something is wrong?)
- MTTR — Mean Time to Resolve (how fast can you fix it?)
- SLO/SLI/SLA — Service Level Objectives, Indicators, Agreements
The Four Golden Signals
Google’s SRE book defines four signals that, if monitored, give you a complete picture of production health:
- Latency — how long requests take
- Traffic — how much demand is hitting the system
- Errors — rate of failed requests
- Saturation — how “full” the system is (CPU, memory, connections)
SLOs and Error Budgets
SLOs (Service Level Objectives) define the target reliability of a service — e.g., “99.9% of requests succeed in under 200ms”. The gap between 100% and the SLO is the error budget.
Error budgets align incentives: development teams want to ship features fast; SRE teams want stability. The error budget is the negotiated zone where both can happen. If the budget is being consumed too fast, you slow down releases. If there’s plenty of budget, you can move faster.
DevOps vs SRE
DevOps and SRE are often treated as competing philosophies. They’re not — they’re complementary.
DevOps is a cultural movement: shared ownership, collaboration between dev and ops, automation of toil. SRE is Google’s implementation of that culture, with specific practices and metrics.
You can think of it this way:
- DevOps defines the what (goals, culture, principles)
- SRE provides the how (practices, metrics, tooling)
Cognitive Load
One concept that cuts across both scales is cognitive load — the mental burden placed on engineers.
Team Topologies (Skelton & Pais) makes this the central constraint of team design. Teams that own too much, or work with systems too complex to reason about, move slowly and make more mistakes.
Architectural decisions — how services are split, how teams are structured, what shared platforms exist — should be evaluated in terms of their cognitive load impact as much as their technical properties.
Books worth reading
- Accelerate — Forsgren, Humble, Kim — the research behind DORA metrics
- The SRE Book — Google — the canonical SRE reference
- Team Topologies — Skelton & Pais — team structure and cognitive load
Next: The blueprints - case study, specification and architecture review