Stop Apologizing for Being the Bottleneck

For most of my career, a bottleneck had one correct response: remove it. If a process slowed down at a person, a team, or a tool, the job was to find that point and engineer it away. If the point was you, the job was to make yourself unnecessary. It was less a strategy than a reflex.

Don't be the bottleneck.

Then, in a meeting today, a colleague apologized for being one. He was worried that work was piling up waiting on him. When we actually looked at what he was doing, though, he wasn't blocking anything. He was the quality gate. The work stopped at him because that was where someone had to decide whether it was good enough to keep going.

That reframed something for me. I'd spent years treating every bottleneck as a defect. I'd never stopped to ask which ones were holding something up.

The image that came to mind was a dam.

What a dam is for

A dam is, by any definition, a bottleneck. It takes a river and makes it wait. And almost everything we value about a river comes from that waiting.

Dams give us power, from the oldest water mills to modern hydroelectric plants. They give us reserves: drinking water, plumbing, irrigation for farmland that would otherwise depend on the weather. They give us control. A wet season doesn't drown the valley, and a dry one doesn't empty the riverbed. They make rivers navigable and create lakes where there were none.

Remove the dam and you don't get more water. You get the same water at the wrong times. Floods destroy homes, farms, and lives. Droughts do the same, just slower. Everyone downstream spends their resources repairing instead of building. The cities shrink to whatever an unpredictable river can support.

What matters is that a dam is not a wall. It has spillways, gates, and operators. It's a valve. The value isn't in stopping the water but in deciding when, and how much, gets through.

A dam is a damn good bottleneck.

The dam in your codebase

The fashionable position in software right now goes like this: AI made writing code nearly free, so the constraint has moved to review. Humans reading pull requests are now the slowest part of the pipeline. Remove the humans, and throughput follows.

It's a category error. It mistakes a control for a constraint.

The teams making this argument look at all the water stacked up behind the dam, every unmerged PR and every pending review, and imagine how much more would grow if it were simply released. So they blow up the dam.

What follows isn't abundance. It's weather. Instead of building a city, they spend their days fighting floods and droughts: regressions, incidents, rollbacks, rewrites. Instead of building reservoirs, they're bailing water and calling it velocity.

Picture a team that lets its agents merge straight to main once the tests pass. The first month looks incredible. Merge counts triple, the backlog empties, the dashboard turns green. By the third month, half of every sprint goes to incidents nobody can trace, because nobody read the code that caused them. The agent writes the fixes, too. Nobody reads those either.

The volume of generated code is going up. That makes the dam more important, not less. Something has to hold the water back, filter it, and test it before it reaches the people downstream. That something is judgment, and judgment is slow on purpose.

The obvious objection is that the dam can be automated too: tests, linters, an AI reviewer checking the AI author. Those can help, the way screens and filters inside a dam help. But a dam also needs an operator, someone who decides how much to release and answers for it when the valley floods. You can't hold a model responsible for that call.

So if you've found yourself at the point where the work piles up, don't apologize for it. Ask whether you're a blockage or a dam. If you're a dam, your job isn't to get out of the way. It's to be well-engineered: clear about what passes, fast at releasing what's ready, and unmovable about what isn't.

Your highest leverage long term role isn't throughput engineering. It's dam building.