Mental Models: DevOps

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.

1. CALMS — the mindset. Acronym coined by Jez Humble: Culture, Automation, Lean, Measuring, Sharing. (I first heard about it in the SRE Workbook.)
2. The Infinity Loop — the “Eight” shape, a way to explain CI/CD and continuous improvement. (No specific book — do you have one?)
3. The Three Ways — the law of FLOW plus feedback and continuous improvement. (src: the DevOps Handbook.)
4. 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

3. The Three Ways — flow, feedback, improvement

The three ways:

1. Flow — an arrow from left to right. Value moves through.
2. Feedback — the arrow from right to left. Signals come back.
3. 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 four metrics + the ABBA sandwich

1. Deployment frequency — how often do you deploy? (how often an idea goes from step 1 plan to step 5 release)
2. Lead time to deployment — how long each deployment takes. That's the bottleneck.
3. Change failure rate — if you deploy often and break things often, your product ends up worse for the customer than if you were deploying less. Unless…
4. Mean time to recover — …you can fix errors fast.

Looking at the picture, the four metrics form an ABBA sandwich:

• A = change (outside): Deployment Frequency (count) + Lead Time to Deployment (time)
• B = errors (middle): Change Failure Rate (count) + Mean Time to Recover (time)

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.