Staying Hands-On as a Director of Engineering

When I first stepped into the role of Director of Engineering, I had to come to terms with a hard truth: my schedule was no longer that of a “maker.” Between one-on-ones, leadership syncs, planning sessions, and cross-functional meetings, my calendar became fragmented beyond repair. The reality is that, as a director, you cannot rely on having long, uninterrupted blocks of time to write meaningful amounts of production code. And honestly, trying to force it usually results in frustration—for you and for your team.

But here’s the good news: staying hands-on doesn’t have to mean pushing code to production every day. Over the years, I’ve found several ways to stay technically sharp and connected to the work, even while managing multiple teams and projects.

1. Code Reviews: Staying Close Without Owning the Keyboard

I no longer own big features, but I make a point to stay active in code reviews. Not as the primary reviewer (that should remain the domain of the engineers closest to the work), but as a thoughtful second set of eyes. This keeps me in touch with the codebase, lets me see patterns in team decision-making, and helps me mentor engineers through subtle design or architectural considerations.

2. Debugging and Production Support

When incidents happen, I make myself available—not as the hero who takes over, but as a supportive partner. Sometimes I’ll dive into logs, sometimes I’ll help trace issues in legacy systems I once helped build. Other times, my role is simply to ask the right questions and guide thinking. Debugging, done carefully, keeps me close to the systems and reminds the team that leadership is about rolling up your sleeves when it counts.

3. Small, Impactful Contributions

I’ve learned not to underestimate the value of fixing small bugs or chipping away at minor features. These “low-stakes” contributions are powerful: they give me a taste of the developer experience, keep my fluency with our stack from fading, and demonstrate to the team that I’m not above doing the unglamorous work.

4. Pair Programming and Technical Mentorship

For me, pairing has become one of the most effective ways to stay hands-on without derailing my schedule. An hour pairing session is manageable even on a busy day, and it gives me direct exposure to how engineers are working with our tools, frameworks, and processes. More importantly, it turns into a two-way mentorship: I share experience, and I also learn what the next generation of engineers is finding intuitive—or frustrating.

5. Leveraging Past Expertise

If you built systems before moving into leadership, don’t abandon them. You’ll often remember design trade-offs and historical context better than most. I stay engaged with these systems not by owning them, but by supporting the engineers who maintain them. It’s a great way to add value without bottlenecking the team.

6. Protecting Creative Time

Even if I don’t plan to code much in a given week, I guard at least a half-day free of meetings. Sometimes I’ll prototype something, experiment with a new library, or contribute to an open-source project. Other times, I’ll write—blog posts, technical strategy docs, or conference talks. This time isn’t just about staying technical; it’s about scratching the creative itch that drew me into engineering in the first place.

7. The Foundation: Deep Fluency Before Leadership

One caveat: none of this works if you never built deep fluency in a language and ecosystem before moving into management. It took me about a decade to get there, and I still rely on that foundation today. Fluency doesn’t mean memorizing syntax—it means understanding what it feels like to build production systems productively on a team. That muscle memory doesn’t fade easily, and it’s what allows me to jump back in, even after weeks spent mostly in meetings.

Summary

Being hands-on as a Director of Engineering isn’t about clinging to your old role as a developer. It’s about finding the right balance—participating in ways that keep you sharp, add real value to your teams, and remind you of the rhythms of software development. If you do this well, you’ll not only stay relevant as a technologist, but you’ll also lead with empathy and credibility.