The New Bottleneck

• 1: Why Coordination, Not Coding, Sets the Pace
• 2: Use AI to Find Friction Before You Use It to Go Faster
• 3: Where the Bottleneck Moves
• 4: The Bottleneck Removal Loop

1 - Why Coordination, Not Coding, Sets the Pace

Three Forces Set the Speed of Any Flow

Coordination cost is not a vague complaint. When work crosses people and teams, three forces govern how long it takes.

1. Wait time rises with utilization

Wait time scales with how busy a resource is, roughly as %busy / %idle. A resource that is 90% busy makes work queue at about nine times its own duration. This is why busy people feel productive while everything waiting on them slows down. The fix for flow is rarely “work harder.” It is to stop loading shared resources to the point where queues explode.

2. Coordination risk compounds

Each dependency roughly halves your odds of arriving on time with quality. With n dependencies, a clean on-time pass is about 1 in 2ⁿ.

Every team you must wait on, every approval, every shared environment is another coin flip you have to win.

3. Knowledge decays across handoffs

The unwritten knowledge surviving n handoffs is about 1 / 2ⁿ. Half is lost at the first handoff, three-quarters by the second. The intent in someone’s head does not travel cleanly across an email, a ticket, and a standup. What arrives at the far end is a lossy copy.

The Three C’s of Coordination Cost

Those forces surface as three recurring problems. Name them and you can attack them.

They conspire to make it unlikely you arrive on time, with quality. Contention and Coupling create the queues. Coherence is the knowledge that decays on the way.

Underneath the Three C’s: Knowledge

Look closely and the three C’s are one constraint wearing three coats. Contention is waiting for the person who knows. Coupling is needing knowledge or output that lives with someone else. Coherence is shared knowledge, decaying at every handoff. The dependency you wait on is almost always a dependency on something someone else knows and you do not. That is why knowledge is the deepest constraint in delivery: remove a knowledge dependency - make the understanding discoverable rather than locked in a person - and you drain a queue, decouple a team, and restore coherence at once. The rest of this subsection is, at root, about finding and removing knowledge dependencies.

The Golden Rule

From the same math comes the single lever that matters.

Removing a dependency roughly doubles your odds of arriving on time with quality.

It is the inverse of the 1-in-2ⁿ curve. Go from four dependencies to three and your odds rise from 6% to 12%. From three to two, 12% to 25%. This is why the leadership move is dependency removal, not local acceleration. You do not win by making one step faster. You win by deleting a step you used to wait on.

Where the Dependencies Live

If coordination is the constraint, where in the organization does it sit? In Wiring the Winning Organization, Steven Spear and Gene Kim describe any organization as three layers.

graph TD
    L3["Layer 3 - Social circuitry<br/>org, system, and process architecture;<br/>how information and decisions flow"]
    L2["Layer 2 - Tools and instrumentation<br/>IDE, CI/CD, infrastructure-as-code,<br/>telemetry, work tracking, AI assistance"]
    L1["Layer 1 - Technical object<br/>the code, and the developers,<br/>architects, and testers who touch it"]
    L3 --> L2 --> L1

    style L1 fill:#e8f4fd,stroke:#1a73e8
    style L2 fill:#fce8e6,stroke:#d93025
    style L3 fill:#fce8e6,stroke:#d93025

Most AI effort lands on Layer 1, the code. The coordination cost lives in Layers 2 and 3, the tools and the social circuitry. That is the mismatch this whole subsection exists to correct.

The Numbers Make the Misdiagnosis Unmistakable

Map a typical enterprise value stream and the lead time runs about 281 days. Actual coding is roughly 32 of them, about 12%.

So the reflex “developers are slow, let’s add AI” aims at the wrong target:

• Make coding 50% faster and you save about 16 days. A 6% improvement.
• Take coding all the way to zero and roughly 88% of lead time is untouched.

The constraint was never the typing. It is everything around it. That is the physics, and the rest of this subsection follows from it: the highest-leverage use of AI is not to write more code, but to remove the dependencies that dominate the other 88%.

Sources

• Scott Prugh, “Coordination Costs and How Organizations Win with AI,” Forum 2026 - the coordination-cost model this page synthesizes.
• Steven Spear and Gene Kim, Wiring the Winning Organization, IT Revolution, 2023 - the three-layer model and the simplification levers used in the removal loop.
• Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project - the wait-time-rises-with-utilization result, popularized for technology leaders.
• Troy Magennis - modeling of how each added dependency compounds delivery-schedule risk.
• Mary and Tom Poppendieck, Lean Software Development - tacit-knowledge loss across handoffs.

Related Content

• Use AI to Find Friction Before You Use It to Go Faster - the stance and the five properties that turn the Golden Rule into action
• Where the Bottleneck Moves - which dependencies surface where, as agent speed rises
• Value Stream Map - the mapping technique behind the 281-day number

Content contributed by Bryan Finster.

2 - Use AI to Find Friction Before You Use It to Go Faster

Four Principles

Principle 1: Treat AI as a Diagnostic Before an Accelerator

The first capability AI gives an enterprise is not speed; it’s visibility. When an agent struggles to make a small change, it reveals where the system depends on implicit knowledge, a dependency you could not see before. If generated tests are brittle, behavior was never specified. And when code is ready but cannot move, that constraint was downstream all along.

Read these as system signals, not “AI is the problem.” Every place an agent stalls is a coordination cost made visible, and the start of your improvement backlog.

This is the most honest feedback a delivery system can get, because an agent is a literal executor. It cannot lean on tribal knowledge, read a hallway for context, or quietly work around a vague requirement the way an experienced developer does. So where it stalls is objective feedback on a knowledge gap: the system depended on something nobody wrote down, and now you know exactly where. Start Here makes the same point - an agent exposing a gap “is not a flaw in the agents, it is the diagnostic working as intended.”

Principle 2: Measure Dependencies Removed and Value Acceleration, Not Adoption

High usage is not high value. A team can roll out copilots to everyone and leave the delivery system exactly as coupled as before. Two measures matter, and neither is adoption.

• Leading: did a dependency leave the system? This is the Golden Rule’s test, visible in the time from idea to clear intent, the wait for a design decision, the share of changes validated automatically, and the number of controls moved from a meeting into the pipeline.
• Outcome: is value actually moving faster? Shorter lead time, more frequent safe delivery, less work aging in queues.

Count the dependencies you removed and the time saved. But judge yourself on whether the system got faster at turning ideas into value. Output is abundant. Accelerated flow is scarce.

Principle 3: Use the AI Enablement Properties to Accelerate

Once you have named the dependency, the five properties are how you remove it. Point them at Layers 2 and 3, the process and the organization, not just at Layer 1, the code. That is AI Process Engineering: every property applied is a dependency removed, and by the Golden Rule, your odds doubled.

But the payoff is lopsided, and a leader has to respect the limit. AI can do the work, but it cannot accept the work. It can draft the requirement, the design, and the code, but only the real user can confirm a change matches their job. When the same scarce expert both takes in the work and signs it off, AI speeds up the front and leaves the back untouched, and the bottleneck just moves to where automation cannot help. So the move has two halves: aim the properties at the dependencies they can remove, and deliberately fund the human judgment they cannot.

Principle 4: Build Intent, Safety, and Control Into the Flow

Agents are fast and literal. They act safely only inside boundaries they can see. Everything a human used to carry in their head - the requirement’s real intent, the architecture rule no one wrote down, the security expectation, the unspoken fact that “done” includes an audit artifact - has to become something the system can enforce: testable intent, constraints expressed as rules, checks built into the pipeline, quality gates that encode real behavior. This is Coherence made executable.

The same logic governs controls. At human speed an organization survives late-stage gates. At agent speed they become traffic jams, because every control outside the flow is a dependency, and dependencies create queues. Security, audit, and quality matter more when AI accelerates implementation, not less. What must change is their location.

A control built into the path every change travels is an accelerator. The same control bolted on at the end is a bottleneck.

The Five AI Enablement Properties

Five properties describe how AI removes a dependency. Each one, applied, is a dependency removed.

The mechanism is simple. AI enables independence of action, and every removed dependency doubles your odds.

Knowledge sits first for a reason. It is the deepest of the three C’s, and it is the one earlier automation could never touch. A script, a pipeline, a workflow engine can only execute a process someone has already written down; it cannot supply knowledge that was never captured. An agent can. It reads the codebase, the tickets, the chat history, and the runbooks and infers and extracts the understanding that lived in someone’s head - it discovers the process rather than merely following one. That is why ACD does more than expose a knowledge gap: it can fill it. The diagnostic that finds the missing knowledge and the tool that supplies it are the same tool.

The payoff is lopsided because the flow of work is dominated by wait time and coordination cost. Pointing AI at that, rather than at the 12% that is coding, is what produces order-of-magnitude improvements in lead time and quality. Applied to real coordination-heavy work, removing dependencies has compressed multi-week analyses into days and lifted on-time odds from single digits to coin-flip or better. Every win came from removing dependencies, not from typing faster.

One Guardrail

AI Process Engineering is not permission to skip engineering discipline. Integrating AI is software engineering. To be great at it you must be great at DevOps and CI, because that is your safety net. As the 2025 DORA report, State of AI-assisted Software Development, found, AI is “an amplifier, magnifying an organization’s existing strengths and weaknesses.” Point it at a strong delivery system and it accelerates; point it at a broken one and it magnifies the dysfunction. The advance is augmentation, not replacement. Keep your critical thinking.

This is the same point the Agentic CD section makes from the engineering side: an agent-generated change must meet or exceed the same quality bar as a human-generated change. The pipeline does not care who wrote the code.

Related Content

• Why Coordination, Not Coding, Sets the Pace - the physics these principles act on
• The Bottleneck Removal Loop - where you apply the properties, repeatedly
• Pitfalls and Metrics - measuring value acceleration rather than adoption
• Pipeline Enforcement and Expert Agents - how controls move into the flow

Content contributed by Bryan Finster.

3 - Where the Bottleneck Moves

The Product Delivery Lifecycle

To turn “where does work stop?” into a classification you can act on, you need a shared map of the journey, one stable enough that business, engineering, security, and audit can all point to the same place and mean the same thing. Stripped to its spine, the product delivery lifecycle (PDLC) has seven phases, and it loops, because delivery is a cycle, not a line.

graph LR
    P1["P1<br/>Discovery"] --> P2["P2<br/>Design"]
    P2 --> P3["P3<br/>Build"]
    P3 --> P4["P4<br/>Verify"]
    P4 --> P5["P5<br/>Deploy"]
    P5 --> P6["P6<br/>Operate"]
    P6 --> P7["P7<br/>Support"]
    P7 -.-> P1

    style P2 fill:#e8f4fd,stroke:#1a73e8
    style P3 fill:#e8f4fd,stroke:#1a73e8
    style P1 fill:#fce8e6,stroke:#d93025
    style P4 fill:#fce8e6,stroke:#d93025
    style P6 fill:#fce8e6,stroke:#d93025
    style P7 fill:#fce8e6,stroke:#d93025

Each phase answers one question:

• Discovery decides what is worth building and why.
• Design decides how it should work.
• Build implements it.
• Verify proves it is correct, secure, and safe to release.
• Deploy approves the change and moves it to production.
• Operate runs it reliably.
• Support sustains, fixes, and improves it, and feeds what it learns back into the next Discovery.

This is not a custom model. It lines up with the backbone of the major lifecycle frameworks - the classic SDLC, the DevOps loop, and ISO/IEC/IEEE 12207. We use plain verbs so every discipline can read the same map.

The Bottleneck Moves to the Ends

The reason a delivery leader should care about the map is what AI does to it. AI compresses the making phases hardest, Design and Build (shown in blue above), because that is the work AI is most able to generate. It barely touches the rest. So as creation cost falls, the constraint moves outward to the phases generation does not cheapen (shown in red):

• Discovery, where the hard part is deciding what is worth building.
• Verify, where correctness, security, and trust still have to be proven. A cheap-to-write change is not a cheap-to-trust one.
• Operate and Support, where the system has to run and be sustained in the real world.

This is the asymmetry from Principle 3 drawn onto the lifecycle: AI can do the work, but it cannot accept it. The bottleneck moves from the middle of the PDLC to its ends.

The Five Bottleneck Categories

Most agent-speed delivery problems fall into five categories, each anchored to a phase of the PDLC. Name the category to know the intervention. Find it on the lifecycle to know where to look.

Read the categories against the migration and the pattern is plain. The bottlenecks AI pressures cluster at the ends of the lifecycle - requirements churn at Discovery, testing and quality friction across Build and Verify, and knowledge silos at Operate and Support - exactly the phases generation does not make cheaper. Architecture gatekeeping and deployment gates are the gate problems in between: controls an organization survives at human speed but that turn into queues the moment implementation accelerates. Both kinds are coordination costs. The map tells you which is which.

Where Each Category Points on This Site

The interventions above are not abstract. Each category maps to existing guidance you can act on today.

The output of classification is a named, classified constraint, mapped to where it lives in the lifecycle, not a hunch. The next page turns that into a method.

Related Content

• The Bottleneck Removal Loop - the four-phase method that identifies, classifies, and removes each constraint
• Why Coordination, Not Coding, Sets the Pace - why the constraint exists in the first place
• Use AI to Find Friction Before You Use It to Go Faster - the asymmetry that drives the migration

Content contributed by Bryan Finster.

4 - The Bottleneck Removal Loop

The Loop

graph LR
    P1["1. Identify<br/>& Diagnose"] --> P2["2. Re-engineer<br/>the Bottleneck"]
    P2 --> P3["3. Document<br/>& Share"]
    P3 --> P4["4. Iterate to<br/>the Next Constraint"]
    P4 -.-> P1

    style P1 fill:#e8f4fd,stroke:#1a73e8
    style P2 fill:#fce8e6,stroke:#d93025
    style P3 fill:#e6f4ea,stroke:#137333
    style P4 fill:#fff4e5,stroke:#e8710a

Use AI in every phase, not only to write code, but to solve old coordination problems in new ways.

Phase 1: Identify and Diagnose

You cannot remove a bottleneck you have not named. This phase produces a bottleneck map and a classification, and it starts with the real system rather than a maturity model. Use two techniques that work together.

Technique 1: Walk the Value Stream (the Litmus Test)

Take something from your backlog that is small, predictable, and meaningful enough to touch the real delivery system. Observe a developer, and where appropriate an agent, work the change from idea to production readiness, and record four things:

• Steps and elapsed time - where the work actually went.
• Developer interventions - every moment a human must supply context, make a judgment, execute a manual step, recover from tool friction, or interpret unclear feedback.
• Handoffs and approvals - how many people must touch or sign off on the change.
• Agentic friction - the quieter signal: where an agent can act, but not efficiently or safely. It searches for knowledge that should be discoverable, writes a test that does not reflect business behavior, waits on an environment that is hard to start, or makes a plausible change that violates an implicit standard.

This is not a performance review of the developer or the agent. It is a performance review of the system. Ask where the work waited, where it required tribal knowledge, where safety depended on manual judgment, where security or compliance entered too late, and where the pipeline gave a clear next action instead of just saying no. The output is a map of exactly where the value stream stops.

Technique 2: Context Harvesting (Read the Process Exhaust with AI)

Walking the value stream shows you where work stops. Context harvesting shows you why. Most of the knowledge about how work really flows is not in a process diagram. It is scattered across emails, chat threads, wiki pages, tickets, runbooks, meeting transcripts, and architecture decision records. People navigate it by knowing whom to ask. An agent cannot, and neither can a new teammate.

Point AI at that exhaust. Have it read the chat history around a stuck request, the wikis and runbooks for a service, the ticket trail of a recurring delay, and the transcripts of the meetings where decisions were actually made. Then ask it to piece together the real process: who is involved, what each handoff waits on, where the same questions get re-asked, and which knowledge lives in a single person’s head. What once took weeks of interviews now takes an agent a few hours.

Context harvesting does double duty. It speeds up the diagnosis, and it produces the first durable artifact, a written account of how the process actually works, that Phase 3 will build on. In the agent era, the context you harvest here becomes infrastructure later.

The output of Phase 1 is a named, classified constraint, mapped to where it lives in the lifecycle.

Phase 2: Re-engineer the Bottleneck

Once the constraint is named, resist the reflex to add another meeting, dashboard, or escalation path. Those preserve the underlying dependency. The better question is: what dependency can we remove?

• If audit evidence requires ten follow-ups, the answer is not a better follow-up tracker. It is an evidence system with clear ownership, known sources, and automated collection.
• If capacity requests wait for months, the answer is not a more urgent email. It is a self-service workflow with decision rights, budget rules, and provisioning paths.
• If every design waits on the same architect, the answer is not more architect hours. It is architecture guidance teams and agents can apply without waiting.

Re-engineer by applying the five AI Enablement Properties and aim them at Layers 2 and 3, the process and the organization, not just Layer 1, the code. The three levers from Wiring the Winning Organization are how you rewire the architecture: slowification (slow down to design the work before you run it), simplification (break the work into smaller, independent, more linear steps), and amplification (make problems visible the moment they appear). The leadership move is choosing which dependency to remove. AI is how you remove it.

Put safety and security on the same path as speed. Re-engineering is not a permission slip for uncontrolled change. It is the opposite. If agents produce more change, the organization needs stronger proof that change is acceptable, and that proof must live in the path every change travels, not in late human review. A re-engineered bottleneck carries its safety with it: clear intent and acceptance criteria, behavioral tests tied to outcomes, security and policy checks in the pipeline, architecture constraints as enforceable rules, traceability from request to deployment, observable production behavior, rollback, and a named owner for every service and evidence source. See Pipeline Enforcement and Expert Agents.

Phase 3: Document and Share

A local improvement no one else can find becomes another silo. The work is not done when the bottleneck is gone. It is done when the next team, and the next agent, can remove the same class of constraint without rediscovering how.

The best operators do not just solve problems where they occur. They deliberately spread the knowledge throughout the organization. One without the other stalls.

• Local learning - capture the solution where the work happened, in durable form: a prompt, a runbook, a pipeline check, an architecture decision record, a service-ownership record, a test-generator pattern, an evidence template. The test is simple: can the next team apply this without asking the original team to explain it?
• Global learning - make the pattern travel. Publish it where humans and agents discover it in the flow of work: a living system of examples, prompts, artifacts, and outcomes, not a portal of stale documents. The question shifts from “did one team improve?” to “can the improvement move across the org?”

In the agent era, context is infrastructure. Documentation is not the tax at the end of the work. It is the mechanism that converts a one-time fix into organizational capability, readable by the next teammate and the next agent alike.

Phase 4: Iterate to the Next Constraint

Removing one constraint does not finish the system. It reveals the next one. That is not failure. It is the loop working as designed.

This is where the physics pays off. The Golden Rule holds that removing a dependency roughly doubles your odds, so each turn of the loop compounds the last. The goal is not to declare the system transformed. It is to build the reflex - identify, re-engineer, document and share, iterate - until removing bottlenecks is the team’s operating rhythm rather than a one-time initiative. When the whole organization runs the loop, coordination costs compound downward: every dependency removed improves the odds for every team that touches the same flow.

What to Do Next

Start small, but start with the real system. Choose one backlog item, one audit evidence flow, one capacity request, one design approval, or one deployment gate. Then:

1. Run the litmus walk.
2. Name the bottleneck and classify it.
3. Identify which dependency must be removed.
4. Use AI to help re-engineer the work.
5. Move safety and security into the flow.
6. Document the pattern and share it.

Then repeat. Do not wait for an enterprise AI operating model to be perfect. Do not wait for every team to agree on a maturity framework. Do not measure success by adoption alone. Measure whether work moves faster because the system has become clearer, safer, more automated, and less dependent on hidden human coordination. The teams that become fast will not be the teams that chase speed directly. They will be the teams that remove friction, improve quality, and make safety executable.

Related Content

• Where the Bottleneck Moves - the classification Phase 1 produces
• Use AI to Find Friction Before You Use It to Go Faster - the properties you apply in Phase 2
• AI Adoption Roadmap - one full pass of this loop, sequenced for practitioners
• Replacing Manual Validations - the mechanical cycle for moving controls into the pipeline

Content contributed by Bryan Finster.