As engineering leaders, we often face the paradox of our success: the better we become at our craft, the more likely we are to be promoted into roles that pull us away from it. Yet many of us are drawn to leadership precisely because we love technology and want to have a broader impact on how it’s built.

We must ensure our people execute effectively while not distancing ourselves from the work — letting our skills languish in disuse. There are a handful of strategies for doing this effectively and some ground rules to be laid out.

What Keeps Us Away from the Code

Now that we’re managers, our responsibilities extend beyond the next Jira ticket. We’re no longer tech leads; we recruit, manage outward, negotiate priorities with Product, and attend a slew of meetings that could have been Slack threads. We focus on the strategic and operational so our team(s) can focus on the tactical implementation.

I've found this oddly controversial in conversations with more than one other engineering leader. Some believe leaders should be purely technical, simply ICs who assume management responsibilities while driving technical progress and being full-time coders. This might work in some organizations, but only to a point.

Most of my engineering management experience started off leading small teams (including my current role). Just a handful of engineers meant I could easily balance my time coding with my time managering. These were fun and exciting times.

At that point, you’re no more than a tech lead, and the management responsibilities are minimal: a few 1–1s and some interviews as you hopefully grow the team. However, there’s a critical turning point around ten engineers when things will go horribly wrong. I failed to understand this previously, which was detrimental to my and the team’s health.

Finding the Technical Sweet Spot

Managers should be technical. It’s nearly impossible to manage engineers effectively without technical credibility, and maintaining that credibility is vitally important. I’ve seen engineering managers who aren’t technical enough for their team, and their squad runs all over them. It’s simply not enough to just be good with people. You can’t lead with vibes alone.

So, how do you find the work that lets you maintain your chops and earn that continued credibility? The trick is tackling challenging problems that let you grow without getting in the way of everyone. You’re still an engineer, and engineers love to solve problems — so find some that are rewarding to solve and jump into them with aplomb.

Inspired by outstanding engineers at my previous job, I recently took on the task of updating our Java standards at work, including JVM target standardization, ensuring build environments match production environments, updating libraries, and more. As you might expect — or know — this is a thorny, tricky slog. But seeing the search results for <jvmTarget>1.8</jvmTarget> dwindle is so rewarding.

This is certainly not groundbreaking advice, but find projects like these: things that need doing that nobody will ever prioritize, bug fixes, security and maintenance work, long-horizon research and design. Just ensure that your actions aren’t potentially dangerous or catastrophic. And if you get in over your head, don’t be afraid to abandon your work and move on to something else quietly. Or don’t, and bang your head against it in your spare time until you figure out how to do things safely.

As Your Responsibilities Grow

Oof. So, after 10 people or so, even with team leads, things can get really thorny if you aren’t careful. It’s time to let go and pass the technical leadership torch. Now, you’re a safety stop for your most senior people, and it’s still just as vital that you are a credible one.

As your responsibilities grow, it’s time to rethink your contributions and workflow:

• Figure out what you can delegate and make time to contribute meaningfully
• Block off sacred coding time — I protect my Wednesday afternoons and Fridays with religious fervor
• Do Gemba walks — Make time to pair program with people
• Provide quality code reviews and thoroughly review design documents
• Be strategic about your contributions — tackle areas that give insight into multiple teams
• Rotate your focus area — Spend one quarter diving deep into one service and another during the next

It’s still easy to balance technical work while managing one team, but I suspect it’ll become more challenging as my management responsibilities grow. However, I’m committed to always making time for technical work — particularly code contributions and PR reviews.

It’s Not Just Resume Padding

Again, maintaining credibility is important, but there’s much more to this.

You are the driver for your team’s technical decision-making as well. Your Staff+ engineers lead through your authority. That makes you ultimately responsible for their decisions. You can’t afford to let costly mistakes slip through.

Developing your people is also one of your most essential duties. This means mentoring around more than just technical capabilities. Moving your mid-level engineers into senior engineers means teaching them how to navigate the political landscape at work, how to project manage and plan, how to collaborate across team boundaries, and so much more.

Also, let’s be honest — coding is way more immediately gratifying than attending another planning meeting.

This Is Harder Than You Think

Context switching is hard. You’ll be interrupted frequently during your technical work, so blocking off time is essential to get into and maintain flow. Well, try to, at least.

You’ll also be tempted to insert yourself into All The Things or do work that potentially impedes your team’s — or worse, other team’s — progress. Watch out because this is a perilous path. With your newfound freedom (and real ultimate power), you can take your time doing things, refactor, clean up technical debt, and generally have fun when you’re making contributions. You can’t afford to do all of that and be on the critical path.

And I hate to say it, but your technical solutions aren’t always the best. Keep your ego in check. It’s very easy to want to be the architect and savior of the product. You have hired incredibly talented people for a reason. Challenge them, but for their benefit — not yours.

Taking a step back

Staying technical as a leader isn’t about proving you can still code better than your team. It’s about maintaining the connection to the work and to your craft that brought you here in the first place while using your leadership position to multiply that technical impact across your organization.

I do this because it keeps me grounded and allows me to learn slowly and deliberately. I can breathe because my little side project work has no strict deadlines (though I still aim to finish things in a sprint). I always put the work my team needs me to do first, though.