Devops on Mike's Blog

The Platform Leverage Model

Mon, 14 Sep 2026 09:00:00 +0000

Leverage = Reliability × [ Reach × Depth − ( Cognitive Load + Toil ) ]

TLDR: That’s it! End of lecture.

But seriously, this blog post is based on a talk I gave at Yorkshire DevOps in Leeds on 10 September 2026, but with the added bonus of less difficult questions at the end.

The DevOps measuring tape was built for application teams what ship features although DORA’s 2025 report says AI only pays off on a solid platform, so DevOps is back in fashion. Yey! Take that nay-sayers.

But! Yes another but. The point of a platform team is leverage: a few multiplying the many. Fournier and Nowland, in the O’Reilly Platform Engineering book, define the job as managing complexity to deliver leverage to the business. Four things go in, gated by a fifth.

The model in all its glory.

It’s written as a formula because the relationships are multiplicative and subtractive, not because you should put numbers in it. In my experience on infrastructure/platform/cloud/DevOps teams, they often feel neglected by the research and constantly playing catch up. I wanted to give the engineers a way to keep the work that they do relevant and provide benefit, that aligned with the research, back to the customer.

Explain the model, Mike

Reach is how many teams actually use the thing, and it only counts if they had a choice. Where use is mandated, reach is how many teams would still use it if the mandate were lifted. Teams building copies of work because your work is too slow is reach draining away.

Depth is how much more a team can do because you exist. A new service that took six weeks now takes an afternoon, and when starting something costs almost nothing, people start ten times as many things. Multiply the two: if either is zero you have nothing.

Then subtract the friction. Cognitive load is what anyone has to hold in their head to get the thing done: the steps, forms and tickets for them, the tools, exceptions and “ask Dave” for us. Count the steps, don’t survey the feelings. Toil is the repetitive work we do by hand on our own side. Google’s SRE rule: under half the team’s time, leaving at least half for building the things that get rid of it. If the thinking you cause and the toil you carry outweigh the value, the bracket goes negative and the platform is a net cost.

Finally, multiply by reliability, 0 to 1. Call it the base: everything else passes through it, so nothing above it can lift a platform nobody trusts. DORA’s 2024 report found teams using an internal platform got more done but had 14% more failed changes. A platform raises what’s possible and, but if you’re careless, weakens what’s underneath.

Reliability multiplies rather than adds because it’s the one thing DORA doesn’t file with delivery. Its metrics measure how well teams ship code. Staying up was moved into a separate box labelled operational performance, and that box is our job.

Why it needed writing down

My master’s degree in DevOps sent me down the Accelerate and DORA rabbit hole. Rigorous and peer reviewed. Excellent. Then Forsgren moved on to SPACE, a framework for measuring developer productivity, and the focus shifted to developer experience alone. DevEx has a body of research behind it now. There is no PlatEx or OrgEx!

The DORA website tells platform teams to use their same metrics to measure their own performance, alongside satisfaction and adoption surveys. But it’s a yardstick built for somebody else’s work.

We appear in the research on bad days only as well! We are incident responders in a SPACE side-note and as capabilities other teams have in DORA’s catalogue. Nowhere do we appear as the people who build and maintain it. And the rulebooks we’re handed aren’t the same kind of thing. DORA and Accelerate are peer-reviewed research but the SRE book is Google describing Google. ITIL is a committee framework whose change advisory boards are directly contradicted by Accelerate.

The org chart as it sometimes feels!

Slightly more kindly, Flow Engineering calls it a supportive value stream: further from the paying customer, and less measured. Team Topologies (a most excellent resource) draws the platform as a large bluey grey slab at the bottom but is the one of the few resources to apply some reasoning to how they are created and interact.

Yet DORA’s advice is to shift down: move the platform out of developers’ heads. DevEx then measures the developers’ load going down but nobody measures where it went. Paula Kennedy of Syntasso asked at PlatformCon 2022 whose load it is anyway, and warned that shifting all of it onto the platform team isn’t reducing it!

How to use it

The values say why we work this way. The model says what good looks like on the ticket in front of you.

Above the model sit the values: the Three Ways (flow, feedback and continual learning, which I file as findings so all three start with an F) and CALMS (culture, automation, lean, measurement, sharing). The model runs over the ticket in your hand and the work coming next. So, before touching a keyboard, you have five questions:

Who else is going to need this? (Reach)
What will it let them do that they couldn’t before? (Depth)
How much will anyone have to hold in their head, them or us? (Load)
What’s left for us to do by hand next time? (Toil)
Does it stay trustworthy? (Reliability)

Carry those and every ticket becomes proactive work. Also, another point to make is that this was all relevant to work being done for developers from the platform engineers perspective. But all of these should equally apply to how work affects the platform engineers themselves as well. Are we also reducing our own cognitive load by doing this? Are we reducing toil? Remember those batch scripts we used to write? We’ve always done this and the research tells us to trust those instincts.

A lens, not a target

When a measure becomes a target, it stops being a good measure. Goodhart’s law. Chase a toil percentage and you’ll hit it without anything getting easier. Accelerate carries the same warning, via Deming: whenever there is fear, you get the wrong numbers.

Nobody has published a tested measure for platform teams. I looked and there was fewer than a dozen proper studies, and the lack of a tested measure named as a major gap. This is a way of thinking, not an instrument. There’s still more work to be done in this field to bring it up to speed with DevEx. OrgEx perhaps?

When the answer is “we need a platform”

When the model says the work isn’t moving anything, “we need a platform” is a useless sentence. Ask for one of these instead.

The IDP ladder, thinnest first. Every rung counts as a platform.

Six shapes for an internal developer platform, thinnest first. The pattern is what you have to ask for: a person, then a template, then a pipeline, then a button, then a product, then nothing. Team Topologies and the CNCF count rung one, which can literally just be a wiki page. Fournier and Nowland draw the line at rung two: no software, no platform. DORA’s minimum viable platform is one golden path, which lands at rung three.

Most estates I’ve worked on live on rungs one to three and do real leverage there. Every rung costs more to run, so climb when the rung you’re on keeps failing the five questions, not when the next one just looks impressive.

A quiet day

For us a good day is a quiet one. No incidents, and room to learn, maintain and build. Quiet isn’t idle. Quiet is winning!

Every organisation has an infrastructure layer, whatever it calls it, and it deserves more than the research applies. Use the model as a start, or a basis for the actual work you/we/they deliver. Or even as a platform for your platform. Ahem.

This post contains affiliate links. As an Amazon Associate I earn from qualifying purchases. Thanks for your support.

Take Us To Your Leader!

Fri, 24 Jul 2026 09:00:00 +0000

Engineering teams are running a different operating model to before. It isn’t a bunch of engineers any more. It’s a bunch of engineers, each orchestrating a handful of agents. The tooling for this arrived faster than the thinking did, and now we’re all trying to catch up.

Here’s a summary of opinion pieces and academic studies into this brave new world, and where I think the gap still is:

What the evidence says

DORA, State of AI-assisted Software Development 2025 — still the best-grounded starting point despite being from 2025. Nearly 5,000 respondents, and one finding that reframes everything: AI is an amplifier. It magnifies whatever your organisation already is. DORA identified seven capabilities that determine whether that amplification helps or hurts, and the platform one is still the greatest piece of guidance for AI readiness that I have seen anywhere ever — where internal platform quality is high, AI’s effect on organisational performance is strong and positive; where it’s low, the effect is negligible.

Anthropic — the 2026 Agentic Coding Trends Report and the Claude Code documentation — the vendor view (I count Claude as the incumbent in this case). Its Trend 2, “single agents evolve into coordinated teams”, predicts 2026 is the year the single chat thread gives way to one orchestrator coordinating specialised sub-agents — and it states that users require new skills in task decomposition, agent specialisation and coordination protocols, plus version control that can handle simultaneous agent-generated contributions. The docs then say that one human as “team lead” coordinating three to five agent teammates inside a single session, work sized so each teammate owns a different set of files because “two teammates editing the same file leads to overwrites” (for keeping sessions fully apart, they point to a separate technique, git worktrees). All of it, though, is orchestration inside one owner’s control: one team per session, one developer, no sharing a team across sessions. The guidance for running an agent team is genuinely good. There is no guidance on a whole team of developers each running their own agentic robo squad.

Faros AI, The Acceleration Whiplash (2026) — telemetry from 22,000 developers across more than 4,000 teams. Faros state that even though throughput genuinely rose, so did bugs per developer (up 54%), incidents per pull request (up 242.7%), median review time (up 441.5%), and pull requests merging with no review at all (up 31.3%)! Their direct challenge to DORA is that mature DevOps organisations showed the same degradation as everyone else — because their review processes were sized for a lower-throughput world. One caveat I have against their reactive piece to DORA’s approach is that the report doesn’t state how they ensure the teams were definitively “high-performing”. Also “high DORA metrics” scores are not a thing. DORA metrics are not targets. I keep saying **this! That said, they clearly have uncovered an issue in delivery that is still yet to reveal itself. I think I may have some clue to it so keep reading.

HAIF: A Human–AI Integration Framework (Bara, Feb 2026) — the most operationally useful thing I’ve read albeit from a post-deployment perspective. Four rules: every AI output has a named human owner, delegation is a governed and reversible decision, validation is budgeted capacity rather than an afterthought, and human competence is actively maintained through scheduled human-only work. It adds trust tiers where promotion is slow and evidence-based but demotion is instant and anyone can trigger it. Its review principle is three words: “Verify, don’t read.” My reservation is that HAIF is output governance. It’s excellent at checking AI’s homework but doesn’t hit upon guidance and flow. It could even be argued that it hinders flow as we add extra process upon process. But it’s worth reading.

Agile in the Age of AI (Kanban Zone, June 2026) — makes the case that our coordination rituals were tuned for human cadence, and argues for leaning harder on flow: visible work, WIP limits, explicit policies on what “good” means for generated output. It also contains the line I keep coming back to. Humans move from doing the work to deciding, guiding and validating it — and that is “not a reduction in importance, but an elevation of responsibility.”

Where are you now…

So I went looking again for guidance on the part I actually care about: a whole team using AI, not one developer with a fleet of agents. It still isn’t there. What’s online is impressive — orchestration tools like Claude Squad and Conductor, “living specs” that keep agents aligned, branch isolation so parallel agents don’t collide — but every bit of it is engineer-centric. One person conducting many agents. None of it tells a delivery lead how to run a team of humans who each do this against the same trunk.

Which lands me somewhere that might sound old-fashioned: the traditional team disciplines — DevOps and Agile — matter more now, not less. The act of delegating work is the same act it always was. Story points may shrink and sprints get busier; teams may get smaller or their skills shift. But someone still has to own the boundaries, hold the intent, and make the calls no agent can be accountable for. That is delivery leadership and creativity, and no tool ships it.

And that’s why I keep pushing back on treating agents as team members. They aren’t. They don’t self-organise, they can’t change their behaviour after a retro, and they can’t hold accountability. They are capable, fast, occasionally wrong tools working entirely at the direction of the engineers running them — and they break, drift, and get repriced or repositioned by vendors and by our own organisations on timelines nobody on the team controls.

A lot of this was confirmed for me at an “Enabled Day” at Enablis, where we were handed a brief and a single day to turn them into working apps with the help of our old buddy Claude and friends. Nothing highlights issues like a blank page and a deadline. And yes. My team won! Just like Spain.

Are You Actually Ready for AI? Measure to Adopt

Fri, 17 Jul 2026 09:00:00 +0000

Are you ready?

Every organisation right now wants the same darn thing! To get AI into the hands of engineers and watch productivity climb. As it was put in a recent Yorkshire DevOps meetup - the managers want “AI AI AI”! But sometimes the engineers are pushing back. The pressure is real! But there is a hard truth buried in the research that most people skip past.

AI does not fix a struggling team. It amplifies whatever is already there.

See? That single line is the headline of the 2025 DORA report, Google’s study of software delivery, based on roughly 5,000 respondents and over 100 hours of interviews. Really strong teams get stronger with AI. Teams with a weak foundation get faster at producing the wrong things, less safely. So before you buy Claude licences for everyone, you need to answer one question: where does my team actually stand today?

The uncomfortable finding: speed without stability

The 2025 DORA data shows:

90% of respondents now use AI at work, and over 80% say it has boosted their productivity.
Yet 30% still report little or no trust in AI-generated code.
AI adoption shows a positive relationship with throughput and product performance, but a negative relationship with software delivery stability.

Teams are shipping more, faster, and breaking more while they do it! The report shows that acceleration exposes weaknesses that were already there. If your automated testing is thin, your version control is loose, or your feedback loops are slow, AI will help you fail sooner. Which is ironically also a DevOps principle borrowed from Lean but we’re not going down that road today!

In The DevOps Handbook, the same argument is made about automation in general: automating a broken process only lets you make mistakes faster and more reliably. AI is automation in full beast mode, so the risk is larger, not smaller.

Two ways to get your baseline

1. The DORA Quick Check

DORA publishes a free Quick Check that scores your team on the four key delivery metrics (deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time) and shows how you compare to others. It takes a few minutes and gives you an immediate, industry-benchmarked read on your delivery performance. Start here if you want a fast, external reference point.

Those four metrics are not arbitrary. They come out of the years of research written up in Accelerate, which found that these measures reliably separate high performers from the rest. That is the whole reason to start with them: they are the closest thing our industry has to an objective baseline.

2. A DevOps Maturity Model (my tool!)

The Quick Check tells you how fast and safe your delivery is. It does not tell you why, or what to fix first. That gap is exactly why I built the DevOps Maturity Model (DMM).

The DMM is a small, self-hosted web tool that:

Scores your team across dimensions like Automation, Infrastructure and Culture
Tracks your progress over time on a graph
Generates the start of a gap-analysis report so you can plan improvements
Is fully customisable to your team’s own language and priorities

It runs locally via Docker or NPM, so your data stays with you, and it deliberately avoids the discouraging language of formal performance tiers. The point is to make even basic adoption feel like progress. I wrote about the thinking behind it in more detail in my DevOps Maturity Model post.

One caveat! Accelerate actually argues against maturity models. Forsgren writes that “maturity models are not the appropriate tool to use or mindset to have”, and recommend capability models instead: multidimensional, outcome-focused, and never “finished”. I built the DMM anyway! The reason is practical. During my MSc research I could not find a single practising engineer who used capability modelling in the real world, whereas maturity models were something teams instantly recognised and would actually sit down and engage with. The DMM is my attempt to keep the approachability of a maturity model while still pointing people at the capabilities they need to improve.

Used together, the Quick Check gives you the outcome level and the DMM tells you which practices to work on to move on. That is your readiness baseline.

Turning the baseline into an action list

Your scores point at weak spots. Here is what to do about them. Most of this is ordinary good engineering, not AI.

Secure these foundations first. These are the practices DORA’s research ties to high-performing teams, with fuller explanations at dora.dev/capabilities. Treat the list as a checklist and score yourself honestly. Any item you cannot tick, AI will expose it! Not improve. For example:

Version control — every change to code and settings is recorded, and any of it can be undone.
Automated testing — the system checks its own work on every change, so mistakes show up in minutes instead of reaching customers.
Fast feedback — a broken change is flagged within minutes of being made, not days later.
Small, frequent releases — teams ship small changes often, rather than large risky ones now and then.
Automated release and rollback — putting a change live, and pulling it back out, is quick and routine.
Independent teams — a team can deliver its own work without waiting on several others.

Then two AI-specific moves:

Write and enforce an AI policy — short, clear rules on what is allowed, what tools are available (via SSO) and block the rest at network level. AI-written code must be reviewed exactly like human-written code. A policy no one enforces is just a suggestion.
Give AI your own context — connect it to your codebase, documents, knowledge base and standards. Generic AI gives generic answers; your own context is where the value lies.

And one that never changes: product direction stays human. AI speeds up building things. It does not tell you which things are worth building. Oh no no. That still comes from you and your users.

None of this is really about AI anyway. Getting ready for AI and getting good at delivering software are the same job. Fix the weak spots you have flagged, and readiness follows.

Where to start?

If you take one thing from this, let it be the order of operations:

Measure. Run the DORA Quick Check and a DevOps Maturity Model assessment. Get an honest baseline.
Find your weakest foundation. Usually it is testing, feedback speed, or coupling. Fix that before you scale AI.
Write the policy, connect the context, then roll out. In that order.

AI is not a shortcut past the hard work of good engineering. It is a multiplier on top of it. Measure first, and you will know whether that multiplier is working for you or against you.

References and further reading

2025 DORA Report — Google Cloud, Announcing the 2025 DORA Report. cloud.google.com and the full report at dora.dev
Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble, Gene Kim. Amazon
The DevOps Handbook — Gene Kim, Jez Humble, Patrick Debois, John Willis. Amazon
Wiring the Winning Organization — Gene Kim, Steven J. Spear. Amazon
Continuous Delivery — Jez Humble, David Farley. Amazon
Team Topologies — Matthew Skelton, Manuel Pais. Amazon
Platform Engineering — Camille Fournier. Amazon
Strategic Management of Technological Innovation — Melissa A. Schilling. McGraw-Hill. Amazon
DevOps Maturity Model (DMM) — my open-source assessment tool: gitlab.com/devops-maturity-model
DORA Quick Check — dora.dev/quickcheck

Devops Maturity Model

Tue, 25 Mar 2025 10:48:43 +0000

DevOps Maturity Model

Whether you’re just starting your DevOps journey or already deep into automation and delivery pipelines, it helps to know where you currently stand — and where you could go next.

That’s why I created this DevOps Maturity Model (or DMM for short), an open-source tool designed to help teams and organisations assess, track, and improve their DevOps practices over time.

🚀 So What Is It Then?

The DMM is a simple web-based tool that:

Helps you evaluate your DevOps capabilities across multiple high level dimensions (like Automation, Infrastructure, Culture, etc.)
Lets you visualise your progress over time using a graph
Generates the beginnings of a Gap Analysis Report to help you plan improvements
Is fully customisable to match your team’s language, processes, or priorities

It’s designed to run locally (via Docker or NPM with the source code), so that you stay in control of your data.

🎯 Why Did I Make It?

It was inspired by conversations I had at my organisation. I wanted to have a way to fill the gap between DevOps knowledge and understanding (e.g. Accelerate, DORA reports, DevOps Handbook, Phoenix Project etc) and what we think of as traditional DevOps tooling (Terraform, Jenkins, GitLab, GitHub, Kubernetes etc). This model does not recommend any tooling. This is a tool to assist the user in forging communications with the wider team to produce a route to transformation aligning to DevOps principles. Additionally, I realised that most engineers are busy and have significant existing cognitive load - they might understand the requirements but fail to grasp the nuance and specifics of DevOps and need straightforward guidance. I also wanted to avoid and negative language associated with the foundation levels, such as is used in DORA’s performance levels, in order to encourage and promote even basic adoption of DevOps as a step in the right direction.

Hence, I wanted something:

Lightweight, portable and easy to present in workshops or retrospectives
That I could tailor to different teams and contexts
With enough structure to guide conversation, but not so rigid that it becomes prescriptive
That was maintainable over time
That incorporated visual elements to display results

There are many great frameworks that already exist out there, but I needed something that teams could own and evolve, not just fill in once and forget. I chose to focus on how to apply real-world changes to a project so that they could set their goals on improving the key DORA metrics.

🔍 How It Works

Start with a DevOps survey or quick value stream map of your project to get a baseline state.
Go through the model and select your current level for each subdimension (e.g. from “Foundational” to “Leading”).
Save your answers and generate the Gap Analysis Report.
Use the report to plan small experiments — a Kata or a PDCA cycle.
Revisit the model regularly to track improvements over time and use the graph to see where you’re improving (or not!).

The tool gives you a visual representation of where you’re strong, where you can grow, and how things change sprint by sprint.

🧩 Customisable & Developer-Friendly

It’s built with:

Node.js + Express backend
HTML/CSS/JavaScript frontend
SQLite database (lightweight and local)

The maturity dimensions are defined in a dimensions.json file, so you can change the structure, labels, levels, and language to fit your team’s style.

You can also run it locally using the Docker image, with a single command. No vendor lock-in. No SaaS required. Alternatively, run it in the cloud somewhere!

🛠️ Try It Out

View the repo: DevOps Maturity Model on GitLab

Run it with Docker:

docker run -d --name devops-maturity-model \
  -p 3131:3131 \
  -v devops_data:/app/data \
  registry.gitlab.com/devops-maturity-model/devops-maturity-model:latest

📝 Licensed Under GPL v3

This project is fully open source, licensed under the GNU General Public License v3.0. You’re free to use it, adapt it, and contribute back.

🙏 And Finally

Thanks for reading this post. Please raise an issue if you have any problems with the model or feel free to reach out if you find the model useful and want to ask me about it. Also, feel free to fork the model and customise it for your team or project.

N.B. DevOps banner image drawn by my daughter!