The Day I Realized I Was the Bottleneck

Being needed for everything feels like importance. It is a ceiling, not proof of value.

Everything routed through one point. The point was me.

I came back from four days offline to forty-one unread threads, and thirty of them were waiting on me specifically. Not waiting on a decision, the team could have made on its own. Waiting on me. A deploy held because nobody else would approve it. A design parked because someone wanted my read before they “committed to anything.” Two engineers stuck on a question only I could answer, because the answer lived in my head and had never lived anywhere else.

For about an hour, I felt important. That is the embarrassing part, and I am going to leave it in, because it is the whole story. The pile of things that needed me looked, at first, like proof that I mattered. It took the rest of that day to see it as what it actually was: a queue forming behind a single point of failure, and the single point of failure was me.

I had spent two years quietly becoming the person everything routed through, and I had filed that under seniority. It is closer to the opposite. A senior engineer is supposed to raise the ceiling on what a team can do without them. I had become the ceiling.

How it happens, which is the part nobody warns about

Nobody decides to become the bottleneck. It accumulates, one reasonable choice at a time.

It starts because being the bottleneck is genuinely efficient in the short run. I knew the payment flow better than anyone, so the payment questions came to me, and answering one took ninety seconds, while teaching someone to answer it took an afternoon. So I answered. Every time I answered instead of taught, the fast choice, the correct-feeling choice, I made myself a little more central and the team a little more dependent. The dependence was invisible because it looked like helpfulness. I was always available. I was always right. People learned, sensibly, to wait for me rather than risk being wrong without me.

The cruel detail is that competence makes this worse, not better. The more reliably good my answers were, the less reason anyone had to build their own, and the more rational it became for the whole team to route through the one person who would not get it wrong.

By the end, I was in every design review, every incident, every hiring loop, every “quick question.” I told myself this was leverage. It was the precise opposite of leverage. Leverage is when the system produces good outcomes without you in the loop. I had built a system that produced good outcomes only with me in the loop, and then I had gone on vacation, and the outcomes had simply stopped.

What being needed did to my judgment

Being the person everyone needs comes with a feeling, and I should be honest that the feeling is good. It is a small, steady hit of significance, available all day, every day a thread lands in my name. I am fairly sure I was, without admitting it, optimizing for that feeling. Not consciously. But the choices I made all happened to keep me at the center, and a choice that consistently flatters the person making it deserves suspicion.

That is the quiet damage. It is not only that the team slows down. It is that the bottleneck has a motive, usually hidden even from himself, to stay the bottleneck. Delegating means giving up the significance. Teaching means watching someone do, slower and worse, the thing I could do fast and well, and resisting the urge to take it back. Every instinct that made me good at the work, the speed, the standards, the impatience with mistakes, pushed me toward staying on the critical path.

I think this is why the bottleneck problem is so sticky. The person best positioned to fix it is the one who benefits most from leaving it broken.

[embed]Why the Best Technical Communicators Explain Less, Not More The Senior Engineer’s Toolkit, Part 3saeedhbi.medium.com

The unwinding was worse than the realization

Seeing it took a day. Acting on it took the better part of a year, and most of that year felt like getting worse at my job.

The first thing I had to do was let decisions get made without me, which meant letting some of them get made worse than I would have made them. A design went out that I would have built differently. It was fine. Not what I would have done, fine. I had to sit with the gap between “the way I would have done it” and “a way that works,” and accept that the second one was the goal, because the first one did not scale past my own two hands.

The second thing was harder, and I am still not good at it. I had to stop answering. When the payment question came, I had to route it to the person who should own payments and then stay quiet while they worked it out, even when I could see the answer, even when staying quiet cost the team an hour, it would not have cost if I had just said the thing. Those hours felt like a waste. They were not a waste. They were the price of the answer living in a second head, and then a third.

Side note, because it surprised me: writing things down turned out to matter more than I expected. Half the reason everything routed through me was that the knowledge existed only as me. The boring work of putting it somewhere other than my own memory did more to unblock the team than any clever delegation scheme.

The objection I kept raising to myself

The obvious counterargument, and I made it to myself for months, is that sometimes the bottleneck is correct. Sometimes a decision genuinely needs the most experienced person in the room, and routing it elsewhere to make a point is just process theater. That is true. Early in an incident, or on a one-way-door architectural call, being the single point is sometimes exactly right.

But that was not most of what was queuing behind me. Most of it was ordinary, and I had let ordinary things require me because requiring me felt better than not requiring me. The senior skill is not refusing to ever be the bottleneck. It is being able to tell the difference between the decisions that actually need me and the ones that had merely learned to wait for me, and then ruthlessly pushing the second kind back out. I had become bad at that distinction precisely because I had stopped looking for it.

[embed]How I Decide What Problems Are Worth Solving (And What to Ignore) Prioritization isn’t ranking problems by importance. It’s choosing which ones to leave broken and being able to defend…saeedhbi.medium.com

What changed in how I see the job

Early on, I measured my value by how much I was needed. A full queue meant I was important. That is I now think, exactly backward, and it took becoming the bottleneck to feel why.

A more experienced version measures value by output: how much good work ships with my hands on it. Better, but still a trap, because my hands are finite and they become the limit.

The version I am still growing into measures value by what ships well without me. Whether the team makes good calls when I am offline. Whether the knowledge lives in more than one place. Whether my absence for four days is something nobody particularly notices. The best senior engineers I have worked with are slightly invisible in exactly this way: their teams hum along, and it is genuinely hard to point at what they do, because what they do is engineer themselves out of the critical path so thoroughly that the path stops running through them.

I came back from those four days off to a queue that told me I had made myself indispensable. I had thought that was the achievement. It was the bug. I still feel the pull of the full queue, still get a small hit when someone needs me specifically, and I suspect the difference between me now and me then is not that the pull went away. It is what I have learned, most days, not to trust it.