The Physics of Software Delivery

If you’ve watched Interstellar at least a dozen times (which is totally normal, right?) you know the scene: some of the crew lands on Miller’s planet, near a massive black hole. Same laws of physics on the planet, but time moves differently — one hour on the surface equals seven years back on the ship. Everything feels normal while they’re there. They return to the ship to find 23 years have passed.

—

You’ve been in this meeting. The CEO bought AI coding tools twelve months ago and wants to know why the team isn’t shipping faster like teams at every other company obviously are.

You know the answer is somewhere in the tangle of review queues, dependencies, and the migration that’s been deferred for three quarters. You say something about those things. The room glazes over. Everyone nods. Nothing changes. That’s the Miller’s planet feeling — code is being written, PRs are merging, dashboards are green, everything looks the same. But the dynamics underneath have shifted, and the room can feel it without being able to name it.

The job is genuinely hard, and the industry has a long history of promoting people into leadership without teaching them how software delivery actually works or how to explain it to the people around them. If that meeting keeps ending the same way, it’s usually not because you don’t understand the problem. It’s because you don’t have the language to make the non-technical people in the room understand it.

That’s what this piece is about: the physics of software delivery — the constraints you work with, not around. They’re not literally physics — but they’re patterns robust enough that ignoring them reliably produces the same outcomes, across enough organizations and enough years that treating them as constraints rather than suggestions is the pragmatic move. You can ignore gravity, but gravity doesn’t care. Software delivery works the same way, and AI hasn’t overridden any of it — but it has changed the terrain these forces operate in.

These physics are well-studied, but most engineering leaders have never been taught to articulate them — and the non-technical people in the room have never been taught to listen. It’s remarkable, if you think about it: in 2026, C-suite leaders aren’t expected to understand how software delivery works — while having detailed expectations of how it’ll work for them. You wouldn’t hire a CFO who didn’t understand cash flow. You wouldn’t hire a CMO who couldn’t explain customer acquisition cost. But nobody expects a CEO to understand why 100% utilization makes teams slower, or why the “big bang release” creates more risk than shipping incrementally. This cuts both ways. Engineering leaders who can’t explain flow physics in terms a CFO understands are part of the gap too. The work ahead isn’t one-sided blame — it’s both sides learning each other’s language. The physics are your contribution to that mutual understanding, and learning to articulate them is how you turn that meeting into a different conversation.

When I started managing around 2017, I realized there was no canon — no shared body of knowledge that engineering leaders were expected to master. Everyone was improvising from instinct and pattern-matching, including me. The ideas I was picking up from books and podcasts in my first months weren’t common currency; experienced managers I worked alongside hadn’t encountered them either, not out of laziness, but because nobody had ever asked them to. Engineering leadership had enormous gaps in its fundamentals that nobody noticed because nobody checked.

Your CFO asks for headcount-to-output ratios. Your board wants metrics that look like factory metrics. Product wants certainty on timelines. These expectations aren’t irrational — they follow from the dominant paradigm for how organizations think about producing things. Optimize the line. Measure throughput. Add capacity to increase output. They’re just wrong for software.

Code is design, not manufacturing. In a factory, you optimize the machines. In software, you optimize the system that humans work within: the processes, the tooling, the information flows, the organizational structure. When something breaks, the instinct to blame individuals is almost always a misdiagnosis — the system produced the outcome, and fixing the system is the job. When a stakeholder asks “why can’t we just add more engineers?” or “why is this taking so long?”, they’re applying manufacturing logic to design work. The belief that individual talent is the primary lever, the “just hire better people” instinct, the pressure-as-motivation play — these all follow from treating software like assembly, and they all make things worse.

Pushing back on this is uncomfortable, because the people holding the manufacturing mental model often have power. Telling your CFO “software doesn’t work that way” isn’t enough. You need to explain how it does work — that the leverage is almost always in making your existing team more effective, not in adding heads. That the system people work within determines their output more than individual talent does. That process isn’t bureaucracy; the right process is infrastructure for speed.

In practice, it means walking your partners through a specific example. “We added two engineers last quarter and velocity didn’t change — here’s why. The bottleneck was deployment review, not coding capacity. More engineers just meant more code waiting in the same queue.” Concrete, connected to something they already noticed, framed in terms they care about.

AI has made this conversation harder, not easier. Non-technical stakeholders can now literally watch AI produce code — and it looks like manufacturing. The machine takes an input and produces an output. This strengthens the wrong mental model in a way that didn’t exist before: nobody used to be able to point at a machine writing code and say “see, it is a production line.” Now they can, and it confirms the prior they already held. The engineering leader’s job of explaining “code is design, not manufacturing” just got harder, because now there’s something they can point at that looks like proof you’re wrong. You need language for this: “Yes, AI produces code. No, that doesn’t mean software is manufacturing. The hard part was never typing — it was deciding what to build, how to build it, and making sure it works in a system that’s already running.”

Share

There are orgs that put engineers on three projects and two on-call rotations because every stakeholder’s priority was “the top priority,” and no was willing to force the trade-off. The physics of why that doesn’t work have been well understood for decades — small batches, fast feedback, continuous flow. The research from DORA, from lean manufacturing, from queuing theory all points the same direction: speed and quality aren’t in tension when you’ve built the system that makes both possible — testing, CI/CD, monitoring. Without that infrastructure, speed does trade against quality, which is why so many leaders reasonably believe they’re in tension. Organizations with the fastest deployment frequencies also have the lowest change failure rates. Accelerate documented this years ago. DORA has confirmed it repeatedly since.

Those physics haven’t changed. But the pipeline they operate on has.

The flow model most of us carry in our heads — requirements, design, code, review, test, deploy — assumed distinct stages with humans at each one. AI is collapsing those stages. An AI agent can propose a fix, write the test, and open the PR. What used to be three flow stages becomes one. The physics still apply — small batches, fast feedback, continuous flow — but they apply to a pipeline that’s a different shape than the one we built our practices around.

The “author” abstraction is breaking, and that’s load-bearing for the entire flow. Code review assumed someone wrote the code and could explain it — why this approach, why not that one, what tradeoffs were considered. When the author is an AI agent, review shifts from “check a colleague’s logic” to “reverse-engineer unfamiliar code written by a system that can’t explain its choices.” That’s a fundamentally different cognitive task, and it’s slower per line, not faster — even as the volume of code to review goes up.

And then there’s a set of questions we don’t have answers to yet.

What does “small batches” mean when AI can produce a 500-line change in seconds? The physics still say small is better for deployment risk — but AI’s default output is often a massive diff. Do we need new practices for decomposing AI output into deployable increments? Does the concept of “batch” change when the production cost drops to near zero?

Code review is another practice under pressure. If AI wrote the code and AI also reviews the code, where does the human enter the loop? Audit? Spot-check? Only on high-risk changes? Some teams are experimenting with different models; nobody has consensus yet.

Feedback loops get stranger. The physics say fast feedback catches problems early. But feedback on AI-generated code goes to whom? The person who wrote the prompt? The team that owns the system? The feedback loop is intact in theory and broken in practice, because the person at the receiving end may not have the context to act on it. And there’s a deeper problem: the AI doesn’t accumulate understanding the way a junior engineer does over months. You can correct an AI agent’s mistake, and it will make the same mistake on the next task. Feedback loops in the traditional flow model assumed participants who learn. The loop completes, but nothing compounds.

Then there’s ownership. Flow models assume accountable humans at each stage. When AI handles writing and testing, the human’s role shifts toward specification and validation — a fundamentally different position in the pipeline. The practices for that role don’t exist yet.

The physics of identifying and removing constraints haven’t changed — even as the constraints themselves shift. The skill is the same: find where work actually waits, and remove the dependency.

I led a project at Indeed that did exactly this. Product teams owned pieces of web surfaces, but they couldn’t deploy their own changes — every update had to go through the team that owned the hosting application for review and deployment. Lead times for even simple changes were measured in weeks. We built a micro-frontend platform that let product teams own their piece of a page end-to-end: their code, their deploys, their schedule. Lead times dropped from weeks to days, and minutes for quick fixes. We didn’t make anyone work faster. We removed the dependency that was making everyone work slowly.

“Where are we slow?” is a different question than “Who’s pulling their weight?” The first drives improvement. The second destroys trust and teaches people to game numbers. The line between the two is thin — and what you measure shapes which question your organization is actually asking. Measure individual output — lines of code, story points, PRs merged — and you get engineers who optimize for those numbers at the expense of everything else. Measure how work flows through the system, where quality breaks down, how engineers experience their own work — and you get improvement. Metric theater is almost inevitable once dashboards get executive attention — organizations adopt DORA metrics and optimize the numbers instead of the outcomes the numbers represent, and the dashboard looks great while the customers can’t tell. The answer isn’t no metrics. It’s the right metrics, interpreted with judgment, grounded in research like DORA and SPACE rather than folklore.

The instruments we had were imperfect but directionally useful. PRs merged roughly correlated with work done, because a human wrote each one. Story points completed roughly tracked team capacity. Lines of code was always a bad metric, but at least it measured something a human actually produced. Those correlations are broken now. An engineer directing AI might merge 20 PRs that represent less judgment and design work than 2 PRs a colleague wrote by hand. A team that “completed 40 story points this sprint” means something fundamentally different when AI did the implementation. The instruments aren’t just imprecise anymore — they’re measuring a different thing than they used to, and the people reading the dashboards don’t know that.

Even DORA’s four keys face pressure. Deployment frequency was meaningful when each deployment represented a human decision to ship. What does it measure when AI agents deploy continuously? Lead time for changes: the coding portion drops to near-zero, so lead time increasingly measures everything except coding — requirements clarity, review, deployment infrastructure. That’s useful, but it’s a different signal than it was before. Change failure rate: we don’t yet know whether AI-generated changes fail at different rates or in different patterns than human-written changes. (Yes, DORA’s survey-based methodology has real limitations — self-reported data, correlation-not-causation concerns. But the directional findings hold across years and thousands of teams, and the alternatives are worse: gut instinct, or no measurement at all.)

Early research is consistent: individual output metrics go up while delivery throughput stays flat and stability gets worse. The instruments are telling us that making individuals faster didn’t make the system faster. That’s either a measurement artifact or a real signal that faster output creates new problems downstream. Either way, the old interpretation of these numbers doesn’t hold.

And then there’s the deeper question: what does “developer productivity” even mean when an engineer’s contribution is increasingly about judgment, problem selection, and review quality rather than code production? How do you measure the quality of someone’s AI collaboration — is the person who writes better prompts more productive? Is that even the right frame? The old instruments don’t work, the new ones aren’t built yet, and the honest leader says so — in specific terms, explaining which instruments are broken and why, rather than pretending the old dashboard still means something.

At Stripe, I tried to shift how we represented developer productivity for senior leadership. The existing metric — PRs per developer per day — wasn’t wrong, exactly. In the broad sense, it told you something. But it was useless for identifying actual productivity problems or opportunities. It couldn’t tell you why a team was slow, or where the friction lived, or what intervention would help. Despite presenting alternatives grounded in SPACE, despite offering a more nuanced picture of what was actually happening, senior leadership stayed anchored to that single number. It felt concrete. It felt comparable. And that was enough for them, even though it couldn’t drive improvement. That’s the physics of measurement in action: the metric that’s easiest to understand wins, even when it’s the wrong one.

I share that story not as a success but as a caution — and a recognition that this advocacy is genuinely hard. A successful version of that conversation probably starts earlier, before the simple metric becomes entrenched. It connects measurement to something the CFO already cares about: “Here’s why we can’t tell you what’s actually slowing us down with the current metric, and here’s what we’d need to measure instead.” It frames the change as giving leadership better information, not taking away the number they’re comfortable with. I didn’t do that well enough at Stripe. The physics were right; my advocacy wasn’t.

A team that’s 100% allocated to feature work and somehow still slow — you’ve seen this, and you probably already know why. The codebase is degrading, the tooling is falling behind, the tests are getting brittle, and the deployment pipeline is accumulating manual steps that nobody remembers adding. None of this announces itself. It compounds silently, like interest on debt — until it doesn’t, and suddenly you’re in crisis mode wondering what happened. The infrastructure nobody wants to touch because the last person who did broke production for a day. The migration that’s been “next quarter” for two years.

Technical debt, infrastructure rot, accumulated friction — these are physics. They’re what happens to every codebase that’s being worked on. You don’t get to choose whether to pay for maintenance. You only get to choose whether you pay continuously, in small manageable amounts, or catastrophically, all at once, when something breaks hard enough to make the business notice. AI is changing the character of what you maintain. Code nobody fully wrote. Code generated faster than institutional knowledge can form. Code where there’s no author who can explain the design decisions because there weren’t design decisions — there were prompts. The entropy physics are the same, but the nature of the debt is unfamiliar, and we’re still learning what maintenance practices need to look like for code produced this way.

The most common accelerant is deadlines that leave no room for maintenance. Fix both the timeline and the scope, and quality is the only thing that can give — tests get skipped, edge cases get ignored, the team quietly takes on months of future drag. Timeboxes work, but only when scope is negotiable. “We have six weeks, what can we ship?” is a fundamentally different question than “Ship all of this in six weeks.” The justifications all sound reasonable in isolation — “we’ll address tech debt next quarter” except next quarter has its own features, “innovation week!” where maintenance becomes a once-a-quarter hackathon — and they all come from the same place: nobody outside engineering understands that the codebase is the capacity to deliver features.

Making the case for maintenance investment is one of the harder advocacy challenges — and AI has added a new wrinkle. The case for maintaining code that a machine wrote sounds to a non-technical leader like maintaining a machine’s output, which sounds like it should be the machine’s job. The explanation requires a new frame: the machine writes code, but it doesn’t own code. Ownership — understanding, maintaining, evolving — is still human work, and AI-generated code may need more human stewardship, not less, because nobody has the deep familiarity that comes from having written it. The framing that’s worked best in my experience for the broader maintenance case: “We can ship X features this quarter, or we can ship 0.8X features and protect our ability to ship X features next quarter too. Without the maintenance investment, next quarter is going to be 0.6X, and the quarter after that is worse.” Concrete, connected to the timeline they care about, framed as a trade-off rather than an expense.

At Indeed, I put two developers on getting Node.js into production while keeping the rest of my team — about fifteen people — focused on work with near-term impact. Node wasn’t the priority anyone was asking about that quarter. But it was obvious we needed it to unlock frontend platform optionality, and I believed you should always be making some bets that don’t pay off this quarter, as long as the stuff that needs to ship is shipping. It took sustained effort over years — navigating skepticism, reverse-engineering undocumented infrastructure requirements, making Node apps look enough like Java apps to reuse existing tooling. That investment is what made the Mosaic micro-frontend platform possible, the same project I mentioned earlier that took lead times from weeks to minutes. The long-term bet paid off because someone protected it.

Everything I’ve described so far compounds — in both directions — and the multiplier is trust.

In some organizations, teams wait for permission on everything; in others, teams move fast, make mistakes, learn from them, and somehow ship both more and better. The difference isn’t talent, but trust. Trust compounds in a way that’s hard to see until you’ve experienced both sides — extend trust, see it returned, build muscle for extending more. But the reverse compounds faster. Every approval gate, every second-guessed decision builds muscle for control, and control creates the slowness that confirms the perceived need for more oversight.

Teams with clear context and real ownership tend to outperform teams managed through detailed instructions — at least when they have the experience, supporting systems, and goals to make autonomy productive. But the most common trust violations are inherited, not chosen. Approval culture often started as a reasonable response to a real incident, then calcified into policy. Post-mortems become blame sessions when leadership demands names rather than systems. “Alignment” theater — everyone nods in meetings and diverges in execution — compounds when nobody feels safe enough to name it.

AI introduces trust surfaces that didn’t exist before. Do you trust AI-generated code the same way you trust human-written code? Do you trust a review of AI-generated code? What does ownership mean when nobody fully authored it? These are genuinely new trust decisions, and organizations don’t have muscle memory for them yet. High-trust orgs will experiment — try practices, share what works, iterate. Low-trust orgs will default to control: mandate checklists for AI usage, ban AI in certain areas, add approval gates for AI-generated code. That compounds the control spiral — more gates, more slowness, which confirms the perception that teams need oversight. We don’t fully know yet what trust looks like for AI-generated work. The organizations that will figure it out first are the ones that already have the trust muscle to experiment and learn.

Building trust upward is some of the most political work an engineering leader does. It means asking a risk-averse executive to let teams own outcomes without pre-approval — and backing that ask with evidence. “This approval gate adds three days to every decision. Here’s what we shipped in the quarter we piloted without it, versus the quarter before.” It means running blameless postmortems even when the exec above you wants a name, and explaining why: “If we punish the person who surfaced the problem, the next problem won’t get surfaced.” It means letting your own teams ship without your sign-off, visibly, so the exec sees what that looks like — which sometimes means absorbing the risk yourself.

That meeting — the one where everyone nods and nothing changes — happens because the other people in the room don’t understand the physics. They think they have a hiring problem, or a prioritization problem, or a motivation problem. They have a physics problem, and physics doesn’t care about the headcount plan.

That conversation changes when someone in the room can explain the physics. The information is freely available — DORA publishes their research, Accelerate costs $15, conference talks are on YouTube, decades of research on lean manufacturing, systems thinking, and organizational design are a search away. The challenge isn’t accessing the knowledge. It’s translating it into language that lands with people who’ve never been expected to understand how software delivery works.

Knowing the physics lets you articulate to your CEO why the roadmap is slipping — not with “technical debt” hand-waving but with a specific diagnosis of where flow breaks down and what it would take to fix it. It lets you explain to the CFO why 100% utilization makes teams slower, not faster. It lets you make the case for sustained investment instead of hoping the next tool or the next hire will be the silver bullet.

None of this is easy, and I won’t pretend that naming the constraint is the same as fixing it. Org charts, board pressure, and the sheer inertia of how things have always been done are real forces. This work is political. It’s exhausting. Sometimes it’s blocked entirely — you make the case, you make it well, and the room still doesn’t move.

The leader who understood the physics pre-AI had an advantage. The leader who can re-read them now — who recognizes the same forces operating in unfamiliar terrain and can explain what’s actually happening — has a bigger one, because most leaders can’t yet. And some of what AI is changing is still revealing itself. The honest position isn’t “I have the complete map.” It’s “I know how to read the terrain, and I’m paying attention to how it’s shifting.”

The margin for not knowing is shrinking fast.

Share