There is a version of this problem that plays out on almost every engineering team at some point. Output feels slow. Features take too long. Someone suggests improving developer tooling, or hiring more engineers, or switching frameworks. The implicit model is that more code, written faster, equals more throughput. That model is wrong, and the evidence has been accumulating for years.
The Debugging Leadership piece that prompted this makes a point worth examining with some data behind it: the constraint for most teams is not how quickly developers type. It is everything that happens to code after it is written.
What the Numbers Actually Show
LinearB’s engineering intelligence research found that across surveyed teams, the average PR cycle time is about 4.4 days from open to merge. The active coding portion of that: roughly 20 minutes. The rest is wait time. Waiting for a first review, waiting for comments to be addressed, waiting for CI, waiting for approval from someone who is in three other meetings.
Swarmia’s analysis puts the median time to first review at 13.5 hours. Pull requests with more than 400 lines of change take roughly three times longer to merge than those under 50 lines. That second finding alone has practical implications for how work should be structured, and it has nothing to do with how fast anyone writes code.
This is not a new discovery. Mik Kersten’s “Project to Product” (2018) introduced the concept of flow efficiency as a way to measure how much of a feature’s total lead time is spent on active work versus waiting. For most enterprise software organizations, Kersten found flow efficiency below 15 percent. That means at least 85 percent of the time between “work starts” and “work ships” is idle time. The code is sitting in a queue somewhere, waiting for a human or a system to process it.
The DORA research program, now maintained by Google, has been tracking software delivery performance since 2014. Their findings, published annually and synthesized in the book “Accelerate” by Nicole Forsgren, Jez Humble, and Gene Kim, show a 6,570x difference in lead time between elite and low-performing teams. Elite performers measure lead time in hours. Low performers measure it in months. The gap is not explained by elite performers writing more code. It is explained by how their delivery pipelines are structured.
Little’s Law and the Queue Problem
There is a mathematical reason why adding more development capacity to a bottlenecked pipeline does not improve throughput. Little’s Law, originally derived for queuing systems in operations research, states:
Cycle Time = Work In Progress / ThroughputIf a team has 20 items in active development at any given time and completes 5 items per week, the average cycle time is 4 weeks. Cutting work in progress to 10 items, with everything else constant, cuts cycle time to 2 weeks. No one writes code faster. No one is hired. The team just limits how many things are simultaneously in flight.
This is the central insight from Eliyahu Goldratt’s Theory of Constraints, which Gene Kim explicitly built on in “The Phoenix Project”. The fictional IT manager in that book spends the first half of the story trying to hire more people and work more hours before finally realizing the constraint is a single overloaded operations team. Speeding up development just creates a larger pile of work waiting for that team. The system cannot go faster than its slowest stage.
For most software teams, code review is that stage. Not because reviewers are slow or careless, but because review is often treated as an asynchronous, low-priority activity that happens whenever a developer has a free moment between their own assigned work.
The Misapplied Optimization
This matters more now because AI coding tools have introduced a new variable. Tools like GitHub Copilot, Cursor, and others can meaningfully accelerate the code-writing phase of development. There is genuine value in that. But if the average coding time on a PR is already 20 minutes and total cycle time is 4.4 days, making the 20 minutes faster by 50 percent saves you 10 minutes and leaves the other 4 days and 23 hours unchanged.
The SPACE framework, published by Microsoft Research in 2021, makes a related argument about how to measure developer productivity. The authors, including Forsgren, argue that measuring only activity metrics like commits and PRs misses the most important factors. Flow state, satisfaction, and communication overhead all matter. A developer writing 3x more code per hour who then waits 3 days for a review is not 3x more productive in any meaningful organizational sense.
The “Software Engineering at Google” book documents that Google identified code review latency as one of the primary productivity drains on their engineering organization. Their internal research found developer satisfaction and throughput correlated strongly with having code reviewed within 24 hours. Not with IDE features or language tooling choices.
What the Constraint Actually Looks Like
Dominica DeGrandis, in “Making Work Visible”, describes five “thieves of time” that systematically harm software delivery: too much work in progress, unknown dependencies, unplanned work, conflicting priorities, and neglected work. All five are organizational problems. None of them are solved by writing code faster.
The DevOps Handbook frames this through the “Three Ways”: optimize for flow from development to operations to customer, then build feedback loops, then enable experimentation. The first way requires identifying and protecting the constraint, not flooding it with more work.
In practice, this means a few things that teams resist because they feel counterintuitive. Smaller pull requests. Not because smaller PRs are inherently better code, but because they move through the review queue faster and with fewer context-switching costs for reviewers. Explicit review SLAs. Many organizations have no formal expectation about when a review should happen, which means it happens whenever it happens. Limiting WIP deliberately. Saying “we are only working on five things at once” feels like slowing down. The cycle time data suggests it speeds things up.
The Organizational Difficulty
The reason this problem persists despite the evidence is that the symptoms are visible in the wrong place. When features ship slowly, the intuitive reading is that not enough code is being written. The queue of waiting PRs is less visible than a story pointing to a developer’s output. Managers who track commit counts and story points see the coding phase; they often do not see the hours and days items spend waiting.
There is also a political dimension to acknowledging that the constraint is review or deployment process rather than developer effort. It implicates different teams and different decisions. Saying “we need to write code faster” asks engineers to work harder. Saying “our review process is the bottleneck” asks for a structural change that involves everyone downstream.
The State of DevOps reports have consistently found that high-performing teams are distinguished not by technology choices but by organizational practices: code review culture, deployment automation, psychological safety to report failures, and clear ownership of services. These are not problems that any tool solves directly.
Writing code is the part of software development that is most legible to tooling and measurement. It produces artifacts you can count. It is also, in most teams, not the part that determines how fast value reaches users. The constraint is almost always downstream, in the handoffs, queues, and approval chains that code passes through after the editor is closed.