The Fundamental Mistake: Optimizing People Instead of Systems
When a team is slow, the natural response is to add process. More standups, more status updates, more approval gates. Each feels like a solution, but each adds friction. W. Edwards Deming, the quality systems theorist, estimated that 94% of problems in organizations are caused by the system, not the people operating within it. His famous formulation: "A bad system will beat a good person every time."
This isn't a comfortable idea for engineering managers. It means that when your team is slow, the first place to look is at the systems you designed and maintain, not at the developers you hired. Hiring better developers into a broken system just gives you better developers who are frustrated by the same constraints.
The Theory of Constraints, Applied to Engineering Teams
Eliyahu Goldratt's Theory of Constraints, from his 1984 novel The Goal, provides a clear framework: every system has exactly one constraint (bottleneck) at any given time. The throughput of the entire system is limited by that constraint. Improving anything else is waste.
Applied to engineering: if your bottleneck is code review, hiring more developers doesn't help—you just have more code waiting for the same constrained review capacity. If your bottleneck is a 45-minute flaky deployment pipeline, faster developers just hit that pipeline more often.
The five-step process:
- Identify the constraint (where does work pile up?)
- Exploit the constraint (get the most out of it)
- Subordinate everything else (optimize the rest to feed the bottleneck)
- Elevate the constraint (invest in increasing its capacity)
- Repeat (a new bottleneck will emerge)
The Five Patterns That Make Good Teams Feel Slow
Pattern 1: The Review Queue Bottleneck
Signal: PRs sit open for more than a day before first review. Developers context-switch to new tasks while waiting, then rebuild mental context. Merge conflicts accumulate. Features "done" two weeks ago haven't shipped.
Structural problem: Review is treated as secondary activity, competing with feature development for cognitive budget. Feature development always wins because it's visible and measured.
Diagnostic question: "What is the average time between a PR being opened and receiving a first substantive review comment?" If more than four hours, review is your bottleneck.
Pattern 2: The Unclear Ownership Trap
Signal: A feature is "almost done" for three weeks. Work is happening, but it never reaches the finish line because final steps (cross-team sign-off, dependency on another service, design decision) are nobody's clear responsibility.
Structural problem: Accountability without authority. The developer who owns the ticket doesn't own the decisions needed to close it.
Diagnostic question: "For the last five features that took longer than estimated, where specifically did they slow down, and who had the authority to unblock them?" If the answer is consistently "we were waiting for [another person/team/stakeholder]," unclear ownership is your bottleneck.
Pattern 3: The Sequential Dependency Chain
Signal: Frontend waits for backend API. Backend waits for database schema. Database schema waits for product decision. Product decision waits for design mockup. Everything is blocked; everyone is waiting.
Structural problem: Work is scoped and estimated as if dependencies don't exist. Then dependencies appear and everything stalls. Goldratt called this "dependent events with statistical variation"—delays compound, they don't average out.
Diagnostic question: "In our last three sprints, how many tickets were blocked at some point, and what were they blocked on?" If blocked tickets account for more than 20% of the sprint, dependency management is your bottleneck.
Pattern 4: The Deployment Anxiety Loop
Signal: Features ship at a reasonable pace but don't reach users. Deployments are infrequent (weekly or monthly) because deploying is stressful. Pipeline is slow, flaky, or poorly understood. Rollback is manual. Last three deployments each caused an incident.
Structural problem: The pain of deployment is treated as a reason to deploy less often, when it's actually a signal to invest in making deployment safer. Accelerate (Forsgren, Humble, Kim, 2018) found that teams that deploy more frequently have fewer incidents because each deployment is smaller, blast radius is smaller, and rollback is faster.
Diagnostic question: "How long does a typical deployment take, and what is the failure rate of our last ten deployments?" If a deployment takes more than thirty minutes or fails more than 20% of the time, deployment friction is your bottleneck.
Pattern 5: The Meeting Saturation Problem
Signal: A developer's calendar has four recurring meetings per day. Remaining time is fragmented into blocks of 45 minutes or less—not enough for deep work. Developers feel busy but produce a fraction of their capability.
Structural problem: Meeting schedules are designed around the manager's calendar, not the maker's cognitive needs. Cal Newport's research on deep work and Paul Graham's essay on the maker's schedule vs. manager's schedule both confirm: creative technical work requires long, uninterrupted blocks.
Diagnostic question: "How many developers on the team have at least two uninterrupted blocks of three or more hours per day, on most days?" If "most don't," calendar fragmentation is your bottleneck.
The Diagnostic Framework: Finding Your Bottleneck
Step 1: Map the value stream Draw every step from "idea" to "in production," including waiting time between steps. A typical value stream: Idea → Refinement → Design → Dev → Code Review → QA → Staging → Approval → Deploy → Production. For each transition, estimate average waiting time.
Step 2: Calculate the DORA metrics Accelerate identifies four key metrics:
- Deployment Frequency: How often do you deploy to production?
- Lead Time for Changes: How long from code commit to code running in production?
- Mean Time to Restore (MTTR): How long to recover from a failure?
- Change Failure Rate: What percentage of deployments cause a failure?
Low-performing teams deploy monthly or less, have lead times of months, MTTR of days, and failure rates above 15%. High-performing teams deploy multiple times per day, lead times of hours, MTTR of minutes, and failure rates below 5%.
Step 3: Identify the constraint Where does work pile up? Where is the longest waiting time? That's your bottleneck.
What to Do Once You've Found the Bottleneck
Apply the five-step process. For example, if code review is the bottleneck:
- Exploit: Limit work-in-progress (WIP) so reviewers aren't overloaded. Swarm on reviews as a team.
- Subordinate: Make review the highest priority for everyone—no new work until review queue is empty.
- Elevate: Invest in better tooling (auto-merge, CI checks), or hire more reviewers.
If deployment is the bottleneck, invest in CI/CD. Automate rollback. Make deployments small and frequent. The goal is not to eliminate all constraints—that's impossible. The goal is to keep finding and resolving them, one at a time.
Final Thoughts
The next time your team feels slow, don't ask "who is slowing us down?" Ask "where does work get stuck, and why?" Map your value stream. Measure your DORA metrics. Find your bottleneck. Fix it. Repeat.
