Mental Models: DevOps
Table of Contents
This post answers:
- How does DevOps make teams perform better?
- How can you measure that performance?
New to DevOps and drowning in buzzwords — CALMS, DORA, The Three Ways, the infinity loop? Here’s one picture that ties them together, plus a mnemonic you’ll actually remember. Ten minutes, four models, done.
DevOps exists because Devs ship change and Ops protect stability — conflicting goals, by design. DevOps breaks the silo: one team, one flow, from idea to customer, with measurement at every step.
The four mental models
Each one comes from a book — sources listed below.
- CALMS — the mindset. Acronym coined by Jez Humble: Culture, Automation, Lean, Measuring, Sharing. (I first heard about it in the SRE Workbook.)
- The Infinity Loop — the “Eight” shape, a way to explain CI/CD and continuous improvement. (No specific book — do you have one?)
- The Three Ways — the law of FLOW plus feedback and continuous improvement. (src: the DevOps Handbook.)
- DORA — the success measurement from the DevOps Research and Assessment. (src: Accelerate.)
1. CALMS — the mindset
How to remember the key aspects of DevOps culture? The acronym comes from Jez at a conference. The SRE WORKBOOK says the most important parts are C and S:
- C = Culture. Software development is about CONTINUOUS LEARNING, which needs a BLAMELESS error culture in teams and EGOLESS POSTMORTEMS.
- S = Sharing. The world is complex, so a team studies different aspects of software engineering, tries things out, measures the results, and then SHARES. The whole team benefits.
Learn and share things!
2. The Infinity Loop — continuous improvement, CI, CD, monitor
Draw a horizontal 8, split it in eight parts, and (bear with me) repeat out loud:
“Please Can Big Team Release Only Daily on Monday” = Plan, Code, Build, Test, Release, Deploy, Operate, Monitor
Maybe you have a better mnemonic — for now it’ll do.
It shows how you go from an IDEA (before Plan), to READY (after Tests), to the customer (Operate, Monitor), and back to idea (after learning from your customers).
Inside the loop, three familiar groups:
- Continuous Integration — Plan, Code, Build, Test
- Continuous Deployment — Release, Deploy
- Software Reliability — Operate, Monitor
Want CI/CD in two minutes? Watch Fireship’s DevOps CI/CD Explained in 100 Seconds.
3. The Three Ways — flow, feedback, improvement
The three ways:
- Flow — an arrow from left to right. Value moves through.
- Feedback — the arrow from right to left. Signals come back.
- Continuous improvement — the action of acting on the feedback.
The most important is Flow. Whatever breaks it is a BOTTLENECK. Optimization anywhere outside the bottleneck is useless and WASTEFUL.
Flow is best visualized with a KANBAN board — a tool from Taiichi Ohno of Toyota. Post-its on a board; when you move them into your “Active” column, you call them Work in Progress (WIP). You want to limit your WIP — if you don’t, you won’t get more things done, you’ll just burn out.
4. DORA — what “high performing” actually means
What does “high performing” actually mean? DORA answers it with three surprising findings:
- Ship more, ship more often → better quality. Counter-intuitive — you’d think: produce less to break less. The data says otherwise.
- Speed and quality aren’t a trade-off. They go together, and the skill is learnable.
- The unit of performance is the team, not the individual. Explored in depth in Team Topologies (topic for another day).
The DORA metrics count successful change (= VALUE) delivered to the customer.
👉 Click to show the five metrics + the DORA mnemonic
Throughput: three stopwatches ⏱️. How fast does change flow to the customer, including the fix when something breaks? Measured in time or count.
- D — Deployment frequency: how often you deploy to production.
- D — Delivery lead time (DORA calls it change lead time): how long a change takes from commit to production. That's where the bottleneck shows.
- R — Recovery time (failed deployment recovery time, formerly "mean time to recover"): how long it takes to get back on track after a deployment breaks something.
Instability: two warning signs ⚠️. How often does change go wrong? Both are percentages.
- O — Oops rate (change fail rate): the share of deployments that need immediate action, like a rollback or a hotfix.
- A — Again rate (deployment rework rate, new): the share of deployments that were not planned, made only to fix an incident in production.
The mnemonic: DORA. The D counts twice (two stopwatches), the R is the third stopwatch, and O and A are the warning signs, Oops and Again. Rule of thumb: if it's a percentage, it's instability.
What’s next: DevSecOps
The same idea of removing silo thinking in companies was raised with the realization that security should not be an afterthought, but a continuous concern, leading to DevSecOps (Sec for Security). I haven’t read that much about security recently — I know about Secure By Design, but I’m looking for more mental models, especially on the DevSecOps side.
If you know a good book on DevSecOps — or a mnemonic for security culture — tell me. That’s the next thread I’m pulling.
Comments, pushback, your own mental models — 💬 on LinkedIn.