When You Are the Bottleneck

I came back from a three-day absence to two hundred and ninety-seven unread messages.

The number is exact because I counted it. I counted it because I had started, around that time, to track a few small numbers about my own work. I had a quiet suspicion that something was going wrong, and I wanted to see whether the data would confirm it. Two hundred and ninety-seven was a high number. It was also, when I went back and looked at the previous three months, not an unusual one. The mean for a three-day absence had been around two hundred and forty. The trend had been upward.

I sat at my desk on the Monday morning and started working through the queue. Decisions, mostly. Some were small, several were not, and a few were urgent in ways that had been costly to defer. By Wednesday I had cleared the queue and was, for about an hour, caught up. Then a new escalation arrived, and then another.

Around lunchtime on the Wednesday, I sat in front of my coffee and noticed that I was not unhappy. I was tired, in the particular way that comes from being needed. I had cleared two hundred and ninety-seven decisions in two and a half days, the queue had moved, things had unblocked, and the teams I worked with had been waiting on me and I had delivered.

I sat with that feeling for a long time, because it was the feeling I had been chasing, professionally, for about two years. And it was, I had begun to suspect, the problem.

How the queue gets built

The version of me that had built the queue had built it slowly, one decision at a time, over months. Each individual decision had been reasonable. A team would face a difficult call and ask me to weigh in. I would weigh in. The decision would be better than it would have been without me, marginally, in the immediate case. The team would learn that asking me produced a useful answer. The next time, they would ask sooner. The time after that, they would ask before they had thought through the question themselves, because asking was cheaper than thinking, and the answer would arrive faster than they could have arrived at it on their own.

Each step of the pattern had felt like helping. Each step had been helping, if you looked at the individual transaction. What I had not been looking at was the cumulative effect on the system around me. The teams I worked with had been getting slower at deciding, while I had been getting better and faster at deciding for them. The two trajectories had been moving in opposite directions for a long time before I noticed.

What is hard about being the bottleneck is not the work. The work, by the time you are the bottleneck, is something you have become good at. You can hold five conversations in your head at once. You can move between contexts in seconds. You can read a four-paragraph escalation, identify the actual decision the writer needed help with, and respond with the answer in two sentences. You are, at this point, genuinely good at your job.

What is hard is that nothing in the day-to-day texture of being good at this job tells you that the work has become a problem. The problem is invisible from inside the work. From inside the work, you are responsive, available, and useful. The teams who come to you receive answers. The escalations that land on your desk get resolved. The data, if you bothered to look at it, would say that throughput on your specific desk was the highest it had ever been.

The data I should have been looking at was different data. It was not how many decisions I was making. It was how many decisions the teams around me were making without asking me. That number had been falling for a long time, and nobody, including me, had been counting it.

The framework that gives itself away

When I finally saw the pattern, my first instinct was to fix it the way I would have fixed any other delivery problem. I would build a process. I would establish criteria for which decisions came to me and which did not. I would create a delegation framework. I would put it on a wiki page. I would communicate it to the teams at the next sync.

I started drafting. About a paragraph in, I noticed something.

The framework I was drafting required a decision from me about how each kind of decision should be handled. The framework itself was a decision the teams were going to have to ask me to make. I was, at the moment of noticing the bottleneck, making it slightly worse by trying to fix it.

The framework itself was a decision the teams were going to have to ask me to make.

That was the smaller realisation. The larger one was that the bottleneck was not, in any straightforward sense, an organisational problem. It was a problem about me. The version of me who had become the bottleneck was the version of me who had needed to be needed. The decisions the teams kept asking me to make were not decisions they could not make on their own. They were decisions they had stopped making on their own because asking me had become easier, and asking me had become easier because I had, slowly, made the asking easy.

I had wanted to be the person whose desk things went through. The system had given me what I had asked for. The cost of having been given it was that I had become the constraint on the throughput of the trains I worked with, and on the development of a generation of leaders who should have been making these decisions themselves.

A series of small refusals

What I did, eventually, was not a process. It was a series of small refusals, made deliberately, over several months, in the moment.

Someone would come to me with a question they could answer. I would say: what do you think we should do. They would tell me what they thought. I would say: do that. The answer would, in roughly nine cases out of ten, be the answer I would have given. In the tenth case, the answer was different from mine in a way that taught me something. In none of the ten cases was the team worse off for having the answer come from them.

Sometimes a team would push back. They would say: but you usually decide on this kind of thing. I would say: I used to. I am trying not to. They would say: but what if I get it wrong. I would say: then we will fix it. We have always fixed things. We will fix this one too.

The first three or four times I said this, the conversation was uncomfortable. After about a month, the asking pattern began to change, and by six months the messages I was getting had a different shape: fewer questions, more notifications, people telling me what they had decided rather than asking me what they should decide.

The number of unread messages after a three-day absence dropped, in the year that followed, from around two hundred and forty to around eighty. Eighty was still a high number, but it was one I could clear in three hours. Two hundred and forty had been the number I had used to feel essential.

What I had not understood

What I had not understood, when I started, was how much of the work was on me rather than on the system. The framework I had begun to draft was a way of asking the system to take the bottleneck away from me. The system could not. The bottleneck was a relationship the system had with me. I had set it up over a period of years, one decision at a time. The only way to dismantle it was the same way.

Each refusal was small. Each refusal felt, in the moment, like I was being slightly less helpful than I could have been, and each refusal was, slightly less helpful than I could have been. The cumulative effect of being slightly less helpful, over a year, was that the teams around me became substantially more capable than they had been, I became substantially less central than I had been, and the work of the trains improved measurably along axes that did not include my throughput.

I had needed the system to depend on me. The version of me that had needed that was not the one I wanted to be. The work of becoming someone different was slower, less dramatic, and considerably less satisfying than I had imagined any leadership transformation should be. It was also the most useful thing I have done in any of the roles I have held.

The diagnostic

The diagnostic question that finally got me to look honestly at what was happening was a count rather than an opinion: how many decisions came to me this week that the team could have made without me?

When I first sat down to count, the inbox number on that Tuesday was a hundred and ninety-one. I had been telling myself, in the back of my head, that it was around sixty.

If you suspect you might be in the same pattern, I would suggest you do not estimate this. Count it. Estimating is a way of arriving at the answer you would prefer. Counting is a way of being told what you actually do.

What you are doing instead

A few months into the work, my wife Stephanie asked me how it was going.

I said: better. The teams are deciding more without me. The trains are running with less of me in the middle. I am working fewer hours. The decisions are getting made faster than they used to.

She thought about that for a moment. Then she said: so what are you doing instead.

I started to answer, and I had a list. I had been back out in the garden, I had been reading, I had been spending evenings with her rather than clearing the queue. Then I noticed that I was answering a different question from the one she had asked. She had not asked what I was doing with the time I had freed up. She had asked what I was doing instead.

I did not have a good answer. The version of me who had needed to be the bottleneck had been very busy, and the busyness had filled most of my professional identity. With the busyness gone, there was a question about what the leadership work actually was, once it was not being measured in messages cleared.

I am still working that one out. It has turned out to be the more useful question, although it is the one that took the longest to surface.

The scenes in this article are anonymised and, where necessary, composited from multiple professional contexts. They are intended to illustrate organisational patterns, not to describe a specific employer, programme, or team.

This is one chapter, condensed, from my forthcoming book Leading Agile When No One Agrees, which works through the Drift framework across twenty-two chapters of scenes drawn from fifteen years inside agile transformations. The book is in final preparation for a Summer 2026 publication. If this piece resonates, the companion worksheets may be useful in the meantime, in particular the Drift Check and the Side Door Audit.

More writing and book launch updates at kylehauslaib.com.