The bottleneck trap

Overview

Lesson 5 showed the gardener model: enabling with guardrails so the squads decide alone. This lesson measures what happens when the architect does the opposite —when they insist that every decision passes through them— and it's the most important lesson of the module, because it touches the central danger of the craft: becoming the bottleneck. And it does so with the module's whole marquee simulation, the one that puts a number on the coordination cost of a funnel-architect against a distributed model.

Here's an idea to internalize before anything: the bottleneck isn't a character defect; it's a structural consequence. It doesn't happen only to authoritarian or disorganized architects. It happens —mathematically— to anyone through whom more work has to pass than they can process, however well-intentioned, capable, and hardworking they are. A brilliant architect who wants to review everything cannot, not because they lack talent, but because the five squads together generate more decisions than a single person can attend to. When arrivals exceed capacity, a queue forms, and the queue doesn't stabilize: it grows without end, and the wait time accumulates. This lesson proves it with a simple queuing simulation and fixed data, so you see the mechanism with your own eyes: it's not that the architect is slow; it's that the "everything passes through one" structure generates a queue that no amount of personal effort can empty.

Connection with the module. It's the third and last of the lessons that define the architect by what they do, and the dark reverse of lesson 5: if you don't enable (lesson 5), you become the bottleneck (this one). It also closes the arc of the "dictator" pathologies that began in lesson 4 (chasing the right decision) and continued in lesson 5 (dictating instead of enabling): the bottleneck is its measurable consequence. Watch the frontier: leadership without authority in depth —how to influence so you don't have to approve everything, disagree and commit, the load-bearing conversations— is module 4, which explicitly mentions "not becoming the bottleneck" as one of its topics. Here we install it and measure it; module 4 develops the leadership techniques to avoid it.

An analogy: the only open checkout at the supermarket

Imagine a supermarket on a Saturday at noon, full of people. There are ten checkouts, but for some reason only one is open, staffed by the fastest and most expert cashier in the store. They're excellent: they scan at top speed, don't make mistakes, are friendly. But there's only one.

People arrive at the line faster than a single cashier, however fast, can ring up. What happens to the line? It doesn't stay a fixed size: it grows. Every minute more customers arrive than leave, so the queue lengthens nonstop. At 12:00 there are five people waiting; at 12:30, twenty; at 1:00, forty, with abandoned carts of people who got fed up and left. And here's what matters: the problem isn't the cashier. The cashier is excellent and working at maximum speed, without a break. The problem is structural: a single checkout for a Saturday's demand can only generate a growing line. You could bring the best cashier in the world and the line would keep growing, maybe a bit slower, but growing. The only real solution is to open more checkouts —distribute the ringing-up— so total capacity matches demand.

The architect who wants every decision to pass through them is that only open checkout. It doesn't matter how fast, brilliant, and hardworking they are: if the five squads generate 46 decisions a week and they can process 20, the queue of decisions waiting for their review grows without end, exactly like the supermarket line. The squads are the customers with full carts, waiting. And the solution isn't "the architect works faster" —they're already maxed out— but opening more checkouts: enabling the squads with guardrails so most decisions are rung up alone, and only the few that really need the architect reach their checkout. This lesson measures the line of the two configurations.

Worked example: the queue that grows without end

We model Mercado's decision flow as a queue. Each week, decisions arrive that need the architect's review. The architect has a fixed review capacity per week. If more arrive than they can process, the surplus stays in the backlog (the line) waiting for the next week, and that wait time accumulates. We compare two designs over 10 weeks:

• BOTTLENECK — all 46 weekly decisions pass through the architect (the lesson 5 dictator model, the only open checkout).
• DISTRIBUTED — only the 7 cross-team ones go up to the architect; the rest self-approve with guardrails (the gardener model, several open checkouts).

# The bottleneck, measured. Mercado's 5 squads generate decisions that
# need review. A single architect has limited capacity per week. If
# what arrives exceeds their capacity, a BACKLOG forms and the wait ACCUMULATES.
# We compare two designs over 10 weeks:
#   BOTTLENECK  : all 46 decisions/week pass through the architect.
#   DISTRIBUTED : only the 7 cross-team ones go up; the rest self-approve with guardrails.
ARRIVALS_ALL = 46          # decisions/week (sum of the 5 squads)
ARRIVALS_CROSS = 7         # only the cross-team ones
ARCHITECT_CAPACITY = 20    # decisions an architect reviews per week
WEEKS = 10


def simulate(arrivals_per_week, capacity, weeks):
    backlog = 0
    total_wait = 0         # "decision-weeks" of accumulated wait
    for _ in range(weeks):
        backlog += arrivals_per_week
        reviewed = min(backlog, capacity)
        backlog -= reviewed
        total_wait += backlog    # what stays in queue waits another week
    return backlog, total_wait


bl_backlog, bl_wait = simulate(ARRIVALS_ALL, ARCHITECT_CAPACITY, WEEKS)
di_backlog, di_wait = simulate(ARRIVALS_CROSS, ARCHITECT_CAPACITY, WEEKS)

print(f"Architect capacity: {ARCHITECT_CAPACITY} reviews/week. Horizon: {WEEKS} weeks.")
print()
print(f"{'design':<14}{'arrive/wk':>12}{'backlog':>10}{'wait(dec-wk)':>17}")
print("-" * 53)
print(f"{'BOTTLENECK':<14}{ARRIVALS_ALL:>12}{bl_backlog:>10}{bl_wait:>17}")
print(f"{'DISTRIBUTED':<14}{ARRIVALS_CROSS:>12}{di_backlog:>10}{di_wait:>17}")
print()
print(f"With everything through the architect, the queue grows without end: {bl_backlog} decisions")
print(f"stuck in week {WEEKS} and {bl_wait} decision-weeks of accumulated wait.")
print(f"With guardrails, the queue stays at {di_backlog}: the architect stops")
print("being the bottleneck of the 5 squads.")

What to expect. Running the file, the output is exactly this:

Architect capacity: 20 reviews/week. Horizon: 10 weeks.

design         arrive/wk   backlog     wait(dec-wk)
-----------------------------------------------------
BOTTLENECK             46       260             1430
DISTRIBUTED             7         0                0

With everything through the architect, the queue grows without end: 260 decisions
stuck in week 10 and 1430 decision-weeks of accumulated wait.
With guardrails, the queue stays at 0: the architect stops
being the bottleneck of the 5 squads.

Read the two rows, because the contrast is the whole argument, and it's brutal.

In BOTTLENECK, 46 decisions arrive per week and the architect processes 20. Each week, 26 go unreviewed and accumulate. After 10 weeks there are 260 decisions stuck waiting for review —260 things the squads can't close because the architect hasn't gotten to them— and the accumulated wait is 1430 decision-weeks. That number is the funnel's coordination cost: the sum of all the time the decisions spent waiting in line. And it doesn't stabilize: if we ran the simulation 20 weeks instead of 10, the backlog would be 520 and the wait would grow quadratically. The queue has no equilibrium; it grows without end, exactly like the single checkout's line.

In DISTRIBUTED, only 7 decisions arrive —the ones that really cross squads and need the architect— against a capacity of 20. The architect processes them all each week with capacity to spare. The backlog is 0. The accumulated wait is 0. No line, no stuck decisions, the squads move forward without blocking. The same architect capacity (20), the same people, but the result is the difference between a system that drowns and one that flows.

Here's the lesson to engrave: the difference between 1430 and 0 isn't the architect's talent; it's the structure. The BOTTLENECK architect and the DISTRIBUTED one could be the same person, equally brilliant, working equally hard (20 reviews/week in both cases). The only thing that changed is how much work was made to pass through them. In the first design, everything; in the second, only what really needs it. The bottleneck isn't cured by working more —the BOTTLENECK architect is already maxed out— it's cured by changing the structure so fewer things have to pass through them. That structure change is exactly enabling with guardrails (lesson 5). Lesson 5 told you how to open more checkouts; this one shows you, in numbers, why it's the difference between drowning and flowing.

Look at how the backlog grows week by week in BOTTLENECK —this is what "grows without end" means—:

BOTTLENECK: backlog at the end of each week (46 arrive, 20 reviewed)
 wk  1 |##                 26
 wk  2 |####               52
 wk  3 |######             78
 wk  4 |########          104
 wk  5 |##########        130
 wk  6 |############      156
 wk  7 |##############    182
 wk  8 |################   208
 wk  9 |##################  234
 wk 10 |####################  260   <- and keeps rising 26 each week, no ceiling

DISTRIBUTED: backlog at the end of each week (7 arrive, up to 20 reviewed)
 wk 1..10 |  0   (the queue never forms)

Deep dive: why the bottleneck is so hard to see from inside

If the bottleneck's cost is so clear in numbers, why do so many architects fall into it and not notice? Because from inside it feels exactly the reverse of what it is. It's worth naming the mirages, because they're the trap.

It feels like being valuable. The funnel-architect is extremely busy: their calendar is full of reviews, everyone seeks them out, nothing moves without them. That constant demand feels like importance —"they need me for everything"—. But being the most requested resource isn't being the most valuable; often it's being the most blocking. The feeling of "they need me for everything" and "I'm the bottleneck of everything" are the same reality seen from two angles, and from inside it's easy to confuse the second with the first.

Others pay the cost, invisibly. The architect sees their work (they review 20 decisions, they feel productive). They don't see the 26 decisions that stayed in line that week, nor the squads waiting, nor the 260 stuck at the end. The bottleneck's cost —the 1430 decision-weeks— doesn't appear on the architect's calendar; it appears dispersed across five squads that move slowly, and since it's dispersed, no one attributes it to "everything passes through the architect". The funnel is invisible to the funnel.

Each individual decision seems reasonable to review. The architect didn't decide "I'm going to be the bottleneck". They decided, one by one, "this decision is important, better I review it", "this one too", "this one just in case". Each review, in isolation, seems prudent. It's the sum —46 weekly reviews— that's impossible, but the sum isn't visible when you decide one at a time. That's how you reach the bottleneck: not by one big decision to control everything, but by hundreds of small reasonable decisions of "better I review this one too".

The external signal that does give away the funnel. Since the architect doesn't see it from inside, they have to learn to read the external signals. The clearest: the phrase "we're waiting for the architect to..." said by the squads frequently. Others: the architect is the slowest to respond and the most people depend on that response; projects stall when the architect is on vacation or sick; the architect works nights to "catch up" with reviews. All are symptoms of the only open checkout. If they appear, the problem isn't that the architect needs to work more or better; it's that the structure is making more work pass through them than any person can process, and the only cure is to distribute —open more checkouts with guardrails—.

There's a cost the simulation doesn't show and it's even worse: the decision that's never made. The queuing model measures the decisions that wait in line, but assumes they all eventually reach the architect. In reality something more corrosive happens: when the squads see everything takes weeks to pass through the funnel, they stop bringing up decisions. Some they make in secret, without the cross-cutting view the architect would have contributed —and there the quality the funnel meant to protect does drop—. Others simply aren't made: the team avoids anything that requires passing through the architect, and the system stagnates at a friction minimum. The bottleneck, then, doesn't just delay decisions; it degrades and discourages them. An architect who wanted to guarantee quality by reviewing everything ends up achieving the opposite: worse decisions, made to avoid their line, or not made at all. The visible queue of 260 decisions is only the part you see; beneath it there's an invisible queue of decisions the squads stopped attempting.

The cure, in one sentence. The architect doesn't scale by getting faster; they scale by becoming less necessary for each decision. It sounds paradoxical —the architect's goal is to become less indispensable in the day-to-day— but it's exactly the point. An architect who designed good guardrails, built capable squads, and left the why recorded (lesson 4) can go on vacation for two weeks and Mercado doesn't stall, because the decisions didn't depend on their presence. A funnel-architect can't take a day off without the line accumulating. The measure of an architect's maturity isn't how much they're needed; it's how much the system keeps working without them. The bottleneck maximizes the first; the gardener maximizes the second.

Common mistakes

Confusing "they need me for everything" with being valuable. What happens: the architect is saturated with reviews and consultations, everyone seeks them out, and they read that demand as proof of their importance —when it's proof they're the bottleneck—. Why it happens: from inside, being the most requested resource feels like being the most valuable, and the cost (the squads waiting) is invisible to the reviewer. How to spot it: if the architect is the most sought-after resource and the most blocking, if nothing moves without them, or if the squads often say "we're waiting for the architect", it's a funnel disguised as indispensable. How to fix it: change the success metric from "how much they need me" to "how much the system works without me", and distribute with guardrails until the line disappears. The architect scales by becoming less necessary for each decision, not faster.

Believing the bottleneck is cured by working more. What happens: the funnel-architect, seeing the line grow, works more hours, reviews at night, tries their hardest —and the line keeps growing—. Why it happens: they interpret the problem as a lack of personal effort, when it's structural: if arrivals exceed capacity, no amount of effort empties the queue. How to spot it: if the architect is already maxed out and the backlog keeps rising week by week (like the 26 that accumulate in BOTTLENECK), the problem isn't their speed. How to fix it: accept that the cure isn't more individual capacity but less work forced to pass through them —open more checkouts—. The fastest cashier in the world doesn't empty the Saturday line; only more checkouts do. Working more in the funnel is exhausting yourself without resolving it; the solution is to change the structure, not the person.

Reaching the funnel by accumulation of reasonable decisions. What happens: the architect never decided to control everything, but kept adding "better I review this one too" until, without noticing, everything passes through them. Why it happens: each isolated review seems prudent; it's the sum that's impossible, and the sum isn't perceived when deciding one at a time. How to spot it: if the architect couldn't say which decisions they don't review —because they review almost all— the accumulation has already happened. How to fix it: invert the default question. Instead of "should I review this?" (which almost always gives "yes, just in case"), ask "does this decision need my cross-cutting view, or can the squad make it alone within its guardrails?". By default, the squad decides; the architect only enters the few that cross boundaries. Changing the default from "I review unless it's excessive" to "I don't review unless it's architect-level" is what prevents accumulation from building the funnel.

Exercises

Exercise 1 — The queue doesn't stabilize. In BOTTLENECK, 46 arrive and 20 are processed, so 26 accumulate per week. Without running the code, calculate the backlog in week 20 and explain why "the architect just needs to catch up one weekend" is an illusion.

See solution

The backlog grows 26 per week (46 arrive, 20 are processed). In week 10 it's 260; in week 20 it would be 260 + 26×10 = 520. The queue doesn't tend toward a stable size: it grows linearly with no ceiling as long as arrivals exceed capacity.

"Catching up one weekend" is an illusion for two reasons. First: the backlog isn't a one-off spike that drains; it's a permanent imbalance between arrivals and capacity. Even if the architect heroically reviewed 260 decisions one weekend and emptied the line, the following Monday another 46 arrive and they only process 20, so the line grows 26 again that same week. The heroic weekend fixes nothing structural; it only postpones the problem a few days. Second: while "catching up", the architect isn't doing their real work (the 7 architect-level decisions, the quality attributes, being close to the code), so the heroic effort cannibalizes the one thing only they can do.

The only cure is to close the imbalance: bring arrivals down from 46 to something ≤ 20 (distribute with guardrails, like DISTRIBUTED, which brings it to 7). There's no amount of personal effort that compensates a permanent structural imbalance. Queuing arithmetic doesn't negotiate with willpower.

Exercise 2 — Diagnose the funnel from outside. You're the manager of a Mercado architect and suspect they're a bottleneck, but they insist "everything's under control, I'm just very busy". What external signals would you look for to confirm or rule out the funnel, without depending on their internal perception?

See solution

The architect's internal perception is unreliable —from inside, the funnel feels like being valuable—, so you have to read external signals, above all from the squads:

• The telltale phrase. How often do the squads say "we're waiting for the architect to review/approve/decide X"? If it's frequent, there's a line. This is the most direct signal.
• Dependence on their presence. What happens when the architect is on vacation or sick? If projects stall and decisions accumulate until they return, it's because everything passed through them. A healthy system keeps flowing without the architect.
• Review backlog. Is there a visible queue of things waiting for their sign-off that grows week by week instead of staying stable? The growing backlog is the imprint of the imbalance.
• The architect's hours. Do they work nights or weekends "catching up" with reviews? Recurring heroic effort is a symptom that the structure makes more pass through them than they can handle.
• Proportion of what they touch. Could they say which decisions they don't review? If they review almost everything (46 of 46), the funnel is already there.

None of these depend on the architect acknowledging the problem. And all point to the same cure, which isn't "work better": it's changing the structure so fewer things pass through them —guardrails and enabled squads (lesson 5)—. As a manager, the conversation isn't "try harder"; it's "let's design so you're not the mandatory step for 46 decisions". (How to hold that conversation and influence without imposing is module 4.)

Exercise 3 — The "necessary" bottleneck. An architect defends their funnel this way: "these decisions are too important to leave to the squads; if I don't review them, quality will drop". Using what you learned in lessons 4, 5, and 6, take apart this argument —acknowledging what's valid in it— and offer the alternative.

See solution

The argument has a valid core and a false leap. The valid part: yes, there are decisions too important to leave without the architect's cross-cutting view —the architect-level ones, the 7 that cross squads (lesson 1)—. In those, the concern for quality is legitimate. The false leap: from "some decisions need my view" it concludes "all decisions need my review", and there's the error that builds the funnel by accumulation (the 46 of BOTTLENECK). The vast majority of the 46 are local —how catalog structures its tables— and the squad makes them better than the architect because it's closer to the problem (lesson 5). Reviewing them doesn't raise quality; it lowers it, besides creating the 1430 decision-week line.

The alternative integrates the three lessons:

• From lesson 5: set clear guardrails that guarantee the quality of the 39 local ones without reviewing them one by one —"internal REST, these SLOs, logs in JSON"—. The quality of the local ones is ensured by the lane, not by the architect's approval.
• From lesson 4: for the 7 they do touch, make them reversible and leave their why recorded, so even those don't depend on the architect "getting it right" —if they're wrong, it reverts cheaply—.
• From lesson 6: accept that "if I don't review them, quality drops" is the funnel's mirage. The quality of a system with five squads can't depend on one person reviewing everything; that doesn't scale and produces the line seen in BOTTLENECK. Quality scales through guardrails and capable squads, not through a single reviewer.

In sum: the architect is right that some decisions need their view, and wrong to believe that justifies reviewing them all. The cure isn't to stop caring about quality; it's caring about it in a way that scales —the lane instead of the funnel—.

Summary and next step

In this lesson you measured the central danger of the craft: becoming the bottleneck. You saw, with the supermarket's only open checkout, that when arrivals exceed capacity the queue grows without end, and that the problem isn't the cashier —however fast— but the structure of a single checkout. And you measured it: with the 46 weekly decisions passing through a single architect of capacity 20, the backlog reaches 260 and the accumulated wait 1430 decision-weeks in 10 weeks, never stabilizing; with the distributed model of 7 decisions, the line is 0. The difference isn't talent —it could be the same person— it's how much work is made to pass through them. The architect doesn't scale by working faster; they scale by becoming less necessary for each decision, and their maturity is measured by how much the system works without them.

Before moving on you should be able to: explain why the bottleneck is structural and not a character defect; argue why working more doesn't cure it; recognize the external signals of the funnel (the phrase "we're waiting for the architect", the dependence on their presence, the growing backlog); and invert the default from "I review unless it's excessive" to "I don't review unless it's architect-level".

Lesson 7 closes the false images with the last one: Big Design Up Front. You've already seen the architect who draws the blueprint and leaves (L2), the one who detaches from the code (L3), and the one who decides everything and becomes the funnel (L4-L6). What's left is the one who designs everything up front, complete, before having the information to do it well. We'll set it against the last responsible moment —deciding each thing when its information matures, neither before nor after— and measure BDUF's overcost from deciding blind and paying the rework.

Resources

• Fred Brooks, The Mythical Man-Month (Addison-Wesley, 1975) — the classic on why adding effort to a bottleneck doesn't resolve it and often worsens it ("adding manpower to a late project makes it later"). The intuitive foundation of why the funnel-architect isn't cured by working more. In English.
• Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019) — on cognitive load and why concentrating decisions in one person or team creates bottlenecks; the solution via enabled teams and platforms. In English.
• Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. The "Architectus Reloadus" everyone must consult is this lesson's bottleneck; Fowler was already warning against it in 2003. In English.
• Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd ed. (O'Reilly, 2020), ch. 21–22 on why the effective architect delegates and multiplies instead of centralizing. "Not becoming a bottleneck" in depth, with leadership techniques, is module 4 of this guide. In English.