The interface was tricky, I knew the system, and I was fast. So, I built it myself.

This was around 2006, and I was leading an interface team of about 30 people on a big telecom program, building the links between a new system and everything around it. Some of those interfaces were hard, and more than once I did what a lot of technical leads do. I rolled up my sleeves.

Not long after that, I received my annual performance review. It had plenty of praise in it. It also had development points that were very specific. There were times I stepped in to do some of the development work myself and, as a result, neglected broader duties like managing the defect queue and the production outages. My senior manager pushed me to delegate more and escalate earlier.

That stung. In my head, I was saving the day and the team each time. However, the review pointed out that, in those instances, I had wandered away from core aspects of my job as a manager.

A NASCAR pit crew is the best picture I have for this. During a pit stop, the crew chief isn’t the one changing tires. The crew chief is watching the entire environment: the fuel, the clock, the traffic coming down pit road, the driver’s voice on the radio. If the crew chief grabs an air wrench because the tire changer is a half second slow, maybe that tire goes on a little faster. But now nobody is checking whether the fuel can is still attached when the car pulls away.

That’s what happened on my team. While I had the wrench, nobody was watching the defect queue closely. Outages weren’t getting the attention a lead should give them. The same review asked whether the offshore part of the team was producing at the same rate as the onshore part, which is exactly the question I should have been asking instead of writing code.

There was another lesson in that review. To meet a deadline, my team implemented a faster stub solution that needed rework later. The client was open to a longer-term approach, but they “wished they were aware sooner.” I’ve learned that a shortcut can be the right call, as long as the person paying for it hears about the tradeoff early. If I had been watching the whole car, I would have raised it the week we made it.

I’d love to say I fixed this habit right away. I didn’t. I love coding, and it took time for me to learn when to stay away from the temptation of “I’ll just fix it.” However, I learned a few things to help guide me when deciding if I should get hands on, and these principles are even more important in the age of AI.

Now, when I pick up a wrench, I still keep an eye on the whole machine. Every hour I spend deep in a task is an hour my broader duties are at risk of neglect. Sometimes that trade is worth it. I just want it to be a choice and not a reflex.

I’ve also gotten pickier about what kind of hands-on work a lead should take. Staying close to the work makes you a better leader, and I’d never tell a manager to stop understanding the code. However, the player-coach should take the work nobody is waiting on. If your piece runs late, nothing important should be stuck behind it.

Regarding the feedback about communicating sooner, I escalate earlier than feels comfortable. Back then, my instinct was to fix a problem myself before telling anyone about it. A client doesn’t want to be impressed by your heroics. They want to know what’s happening while they can still choose.

If a team keeps needing its lead to do the work, treat that as a staffing signal. Write it down and ask for help.

So, the next time you reach for a wrench, look up first and check who’s watching the rest of the car.