When I became a Director of Engineering, people warned me that I would miss coding. What I really underestimated was how hard it would be to stay out of the details when I knew a topic well. I often caught myself thinking: ll just have a quick look at the repo and figure out how to solve this.
That quick look rarely stayed quick.I would open repositories, trace dependencies, sketch architectures, read old tickets and build my own understanding of the problem and a solution. I genuinely enjoyed it. But the deeper I went, the more attention the topic consumed. It still takes time to build enough context. It takes time to separate symptoms from causes. It still takes time to understand the local history, the constraints, the people involved and the trade-offs the team has already considered.
While I was forming my own opinion about an implementation detail, I was not spending my attention on hiring, team health, strategy, alignment or the next organizational bottleneck. I was investing director-level attention into problems other people were able to solve. Expertise made my poor time investment feel productive.
This pattern rarely happened in areas where I was not an expert. If a Staff Engineer explained a complex backend topic outside my expertise, I naturally stayed at the right altitude. I asked questions. I challenged assumptions. I tried to understand the trade-offs and impediments without pretending I knew more than the people closest to the problem. It was only in my comfort zone that I started diving into details. I think this is one of the traps of senior leadership.
Expertise makes leading harder and doing easier
Expertise creates confidence, but it also creates temptation. Solving the problem yourself often feels faster. It feels productive and satisfying. You get immediate feedback and the comforting feeling of making progress. Coaching or mentoring someone else through the problem takes longer. Asking questions instead of providing answers can feel inefficient, especially when you think you already know the answer.
There are moments when a senior leader should go deep. Sometimes the technical risk is large enough that you need first-hand context. Sometimes the team is missing a perspective you can provide. Sometimes there is actually nobody else who can reasonably solve the problem in time. But this should be a deliberate choice and not a reflex.
The first hour of deep diving often looks harmless. You learn enough to ask better questions. The second and third hour are where the shape changes. You are no longer building context for a leadership decision. You are becoming another person solving the problem.
In my opinion it is perfectly fine for a director to help solve hard technical problems. The danger starts when the organization quietly learns that any technical problem becomes the director’s problems. Then expertise turns into dependency. People wait for your opinion even on minor topics. Teams optimize for your review. Decisions slow down until you have looked at the details. Your strength becomes part of the system’s bottleneck.
I still go deep when I need to. Technical curiosity is part of the job and I do not want to become detached from the engineering reality of the organization. But I now try to be much more deliberate before I spend serious attention on a topic. Before opening a repository, I ask myself:
- What decision am I trying to make?
- Am I the right person to make it?
- Is this more important than the other things that need my attention?
- Would my involvement increase the team’s ownership or reduce it?
- Am I helping because others cannot solve this or because I enjoy being able to solve it?
If I cannot answer those questions, there is a good chance I am falling into the expertise trap. I suspect every leader has their own version of it. It does not have to be technical. Whatever got you promoted is often the thing that is hardest to let go of. Becoming a better leader does not mean abandoning your strongest skills. It means making them available without letting them consume the attention your role needs elsewhere.