One of the things I underestimated when becoming a Director of Engineering was how difficult it would be to stay out of topics I knew well. Most people told me it would be hard to stop coding. But the harder part was not writing code. It was resisting the temptation to use my technical expertise whenever a problem looked familiar enough.
When discussions became technical, I could usually follow them without much effort. If a migration was stuck, a dataset was poorly documented, or teams disagreed about an implementation, I often caught myself thinking: I’ll just have a quick look.
That quick look rarely stayed quick.
I would open repositories, trace dependencies, sketch architectures, read old tickets, and slowly build my own understanding of the problem. I genuinely enjoyed it. I like figuring things out. I like digging into messy systems, structuring the issues, and proposing solutions. The problem was not that I was bad at it. The problem was that I was good enough at it to keep going.
But the deeper I went, the more attention the topic consumed. A complicated technical problem does not become cheap just because I understand the domain. It still takes time to build enough context. It still 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.
And all of that time came from somewhere.
While I was tracing one service dependency, I was not thinking about the operating model of the organization. While I was forming my own opinion about an implementation detail, I was not spending that attention on hiring, team health, strategy, alignment, or the next organizational bottleneck. The opportunity cost was not abstract. It was very concrete: I was investing director-level attention into problems other people were able to solve, while leaving problems only I could solve untouched for longer.
This was the actual rabbit hole for me. Not that I missed coding. Not that I wanted to be the smartest person in the technical discussion. The rabbit hole was that expertise made a 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 drifting into execution.
I think this is one of the traps of senior leadership.
The better you are at something, the harder it is to lead instead of doing.
Expertise creates confidence, but it also creates temptation. Solving the problem yourself often feels faster. It feels productive. It is also satisfying. You get immediate feedback and the comforting feeling of making progress. Coaching someone else through the problem takes longer. Delegating requires patience. Asking questions instead of providing answers can feel inefficient, especially when you think you already know the answer.
But leadership leverage often sits exactly in that uncomfortable space.
The goal is not to stop using expertise. That would be naive. There are moments when a senior leader should go deep. Sometimes the risk is large enough that you need first-hand context. Sometimes the team is missing a perspective you can provide. Sometimes there is nobody else who can reasonably solve the problem in time.
But that should be an intentional choice, not a reflex.
The first hour 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.
It is perfectly fine for a director to help solve hard technical problems. The danger starts when the organization quietly learns that hard technical problems become the director’s problems. Then expertise turns into dependency. People wait for your opinion. Teams optimize for your review. Decisions slow down until you have looked at the details. Your strength becomes part of the system’s bottleneck.
That is a bad trade.
A director’s job is not to avoid technical depth. It is to build an organization that can solve important technical problems without depending on the director as the default escalation path.
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 the 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 entering 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.