Your CEO Has Detailed Opinions About Software Delivery and No Idea How It Works

Most executives can tell you exactly how long a feature should take. Two weeks, they'll say, with real confidence. What they usually can't tell you is why the last three features each took longer than that. The estimate is precise; the understanding underneath it is missing. That gap – between confident expectation and absent mental model – is one of the quietest and most expensive problems in software, and an engineer named Rebecca Murphey put her finger on it this year in an essay called "The Physics of Software Delivery".

If you don't know her work, the short version is that Murphey is a longtime engineering leader who writes clearly about how software actually gets built, for an audience that mostly already knows. What makes this particular essay worth bringing to a different audience – the executives and founders who fund software but don't build it – is one observation, and it's sharp enough to sting.

The observation

Her point is this: in 2026, C-suite leaders aren't expected to understand how software delivery works, while holding remarkably detailed expectations about how it'll work for them. And nobody finds that strange.

Think about how odd that actually is. We'd never accept it about the company's finances. A CEO who had strong opinions about the quarterly numbers but couldn't read a balance sheet would not last. Yet the same person can have firm views about engineering velocity, release dates, and "why this is taking so long" while holding no working model of how the work converts effort into outcomes. Software is, for many companies, the thing that produces most of the value. And it's the one major function leaders are quietly excused from understanding.

That excusal is the root of a lot of broken trust between leadership and engineering. Not malice on either side. A missing translation.

Code is design, not manufacturing

The core misunderstanding is a single category error, and Murphey names it cleanly: code is design, not manufacturing.

Here's what that means, in plain terms. In a factory, the design is finished before production starts. The hard thinking happened up front; the assembly line just produces copies, and you make it faster by optimizing the machines. People instinctively model software the same way – as a factory where engineers are the machines and features are the output, so if you want more features, you push the machines harder.

But writing software isn't the production step. It is the design step. The act of writing code is the act of figuring out what to build and how it should work – every line is a small design decision, and most of the difficulty is in the deciding, not the typing. There's no separate assembly line to speed up, because the thing being "manufactured" is the understanding itself. This is why "just hire better engineers" or "just have them work faster" so reliably disappoints. The leverage isn't in the individual machine. It's in the system people work within: the processes, the tooling, the information flows, the way the team is organized. That system, far more than individual talent, is what determines output.

And here's the hard part for a leader to hear. The honest answer to "why won't this go faster" is usually: the system you've built around these people is what's slow. That's not a sentence most executives are braced for, so it rarely gets said. The expectation stays detached from the reality, and the trust erodes a little more each quarter.

The data executives never get shown

This isn't just a philosophy argument. There's hard data, and it's the kind that looks like a win until you understand it.

A quick bit of vocabulary first, because the numbers depend on it. Most software teams use a system called continuous integration, or CI, that automatically tests and combines everyone's code. The "main branch" is the canonical version of the software – the one that actually ships. "Mean time to recovery" is how long it takes to get back to healthy after something breaks. Keep those three in mind.

CircleCI, a company that runs CI for thousands of teams, published its 2026 State of Software Delivery report drawn from 28 million of these automated workflows. They found that engineering throughput – the raw volume of work moving through the system – rose 59% year over year. The biggest jump they've ever recorded. More code, more activity, more motion, exactly what you'd expect AI-assisted coding to produce.

And yet, for the median team, main-branch throughput – the work that actually reached the shippable version – fell 7%. More code went in; less software came out the other end. Main-branch success rates dropped to 70.8%, well under the 90% mark considered healthy, and mean time to recovery climbed to 72 minutes. All that extra code piled up against the parts of the process that didn't speed up: review, integration, testing, release. The pipeline became the bottleneck, and the bottleneck got more congested.

Now picture two people reading "throughput up 59%." The executive who models software as a factory sees a triumph – the machines are running hot. The person who understands the system sees a traffic jam forming, because they know writing code was never the constraint. Same number, opposite conclusions. The entire difference is whether you've been taught how the work works. That's the literacy gap, made visible in a single statistic.

Diagnostics begins with the room, not the pipeline

I do delivery diagnostics – the work of figuring out why a team isn't shipping the way it should – and the instinct in this work is to reach for instrumentation first. Wire up the standard delivery metrics, measure cycle time, find the constraint. That instinct is half right. The metrics matter. But I've come to believe the first work isn't in the pipeline at all. It's in the room where the work gets funded and judged.

Because if the people paying for the work believe code is manufacturing, no dashboard will fix the relationship. They'll read every metric as evidence the team is underperforming, since their mental model has no slot for "the system itself is the constraint." You have to translate the physics before the numbers can mean anything. And the physics aren't complicated to convey: small batches move faster than big ones; fast feedback beats careful planning; the right process isn't bureaucracy, it's the infrastructure that makes speed possible. Speed and quality stop trading against each other only once you've built the system – testing, CI, monitoring – that lets you have both. It's not an accident that the organizations with the fastest deployment frequencies also tend to have the lowest failure rates. That's not a paradox. It's the physics working as designed.

There's a search query that's been rising for us, quietly: "why teams don't trust me." It comes, I think, from managers and leaders who can feel the distance between themselves and the people doing the work and don't know what's causing it. Often the answer is this exact gap. The team and the leadership are both right and both stuck – not because anyone is incompetent, but because they're operating from different models of how the work works, and nobody has reconciled them.

Closing that gap is the highest-leverage diagnostic move there is, and it doesn't start with a tool. You don't fix a trust problem with a metrics deck. You fix it by teaching the room to read the deck the same way – so that "throughput up 59%, shipping down 7%" lands, for everyone, as the warning it actually is.