How to Stay Technical as an Engineering Manager

Three proven tactics to avoid becoming a "disengaged manager" who loses credibility with their team

My first engineering management job was an internal transition from individual contributor to manager. I was the technical expert in my domain. At first I was more hands on than I should have. Over time I learned to delegate more and give people the space that they need. Slowly, over time, I evolved my leadership style.

Into something worse.

Into a "disengaged manager."

I've seen this story play out time after time in my coaching career. New managers tend to over-index on "micro managing" which is not great. Some managers learn their lesson but over-correct all the way to the other side.

The very best managers are in the details. They adapt how they lead to each situation.

And this means staying technical.

At first, this isn't much of a challenge. But the longer you continue as a manager, the harder it becomes to stay close to the details.

In this post, I'll share three tactical ways that you can apply today to increase your technical relevance, without falling into the micromanagement trap.

The 1:1 Deep Dives

You've heard it all before. 1:1s shouldn't be status update meetings. 1:1 should be their meeting, not yours.

Yeah, that's all generally true. But the fundamental rule of leadership is that there is no one-size-fits-all way to lead. This applies to 1:1 meetings as well.

Disengaged leaders make 1:1s 100% about their directs.

Engaged leaders use these meetings to dive deep into the weeds. Not in every meeting, but in most meetings. Sometimes this means double-clicking on a challenge they're having with an engineer from another team. Or about how they plan to release a new feature to production.

It also means diving into the technical details.

Yes, even opening an IDE and going over the code together.

Here are tips on how to do this well:

1. Start with your "Why?" Have a clear goal for the deep-dive. This can be building a mental map of where to draw your trust boundaries for a new employee. Or reducing risk on a critical project. It can, and often should be, to help *you* ramp up on a technical domain.

2. Focus on questions. As a leader you have to be very careful about the non-verbal signals that you communicate. When you make suggestions, respond visibly to mistakes and surprises, or talk with a know-it-all tone, your direct will respond. To avoid this trap, focus on Curiosity. Ask questions instead of make suggestions.

3. Don't discount Impact. Despite the above, don't write meaningless code. Some great places to find low hanging fruit are in everything that's just "below the line" or in solving pains for your cross functional partners. Building internal tools is a great way to build trust while delivering real value.

Write Code

You should write code.

There, I said it. Every engineering manager should write code and commit code to production once a week.

If you support a larger organization and lead through other managers you can reduce your commit frequency. You should still write code.

Most of the objections to managers who code are objection to managers who code for the wrong reasons. You do not write code because it is your job, you write code so that you can do your job. Your job is to create sustainable and positive change in the performance of the organization. You don't code to create value. You code so that you can better build the team that creates the value.

Here's how you do it well:

1. Choose tasks that are "below the line." If someone depends on you to deliver on time, you're doing it wrong.

2. Work on small tasks. The life of the manager is full of context switches and interruptions. Choose small tasks that you can make real progress on in small focus blocks that are far between.

Scratch Your Own Itch

You are still an engineer. When you face paper cuts in your own work, solve them. Writing code this way is a double win: you'll be more productive and you'll maintain your technical skills.

Consider:

1. Leverage your team's infrastructure. Even if it doesn't make as much sense, bias for using the code that your team maintains to solve your personal itch. The goal is not just to solve your own problem, it's also to have a direct understanding of what your engineers go through in their day to day.

2. Only do 80% of the work. Building tools just for yourself is very different than building a production ready system. The first 80% of the work saves you from the last 80%.

Summary

One of the highest leverage systems that I build as an engineering manager was a hacky system of scripts, chrome extensions, and personal conventions. On more than one occasion this system helped me salvage a promotion or rating.

But it didn't end there. I found myself having to represent my team in meetings with leadership. When I stayed close to the details, I could do my job well. When I didn't, I had to stutter, delay, and bring in an engineer. I didn't just lose trust as a leader, I also had to waste the time of my best engineers afterwards.

So, please, be an engaged leader.