I was the best engineer on the team. That was the problem.

The first team I led delivered on time. I want to be honest about how. I did the hard parts myself. When a migration script needed writing at nine at night, I wrote it, because I was quicker than anyone else on the team and the date was close. When a design review went badly, I rewrote the design over the weekend rather than sending it back.

We hit the date. Then two of my engineers asked to move to another team, and I could not understand why. I had protected them from all of it. That was exactly the problem. I had spent six months taking every interesting, difficult, career-shaping piece of work away from the people who needed it most, and I had called that leadership.

Absorbing work feels generous while you are doing it. Nobody is being told off, nothing is late, and you go home tired in a way that feels virtuous. The damage is invisible for months, because it shows up as an absence: the reviews your engineers never had to defend, the estimates they never had to stand behind, the awkward conversation with the supplier they never had to run.

There was a practical cost too. I became the only person who understood the parts of the system that mattered most, which meant I could not take leave, could not think beyond the current sprint, and could not be replaced on the one project that most needed me to step back from it.

What changed things was a smaller decision than I expected. I started asking, before picking anything up, whether I was the only person who could do this or simply the fastest. Almost every time the answer was speed, and speed is the cheapest thing a team has.

I would treat every task I was tempted to absorb as a training decision, not a delivery decision. Doing it yourself buys you one deadline. Handing it over, with support, buys you every deadline after that.

If the team cannot deliver without you, you have not built a team. You have built a dependency with your name on it.