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.