From Engineer to Manager: keeping your technical skills

I became an Engineering Manager over two years ago. One of my main challenges during this time has been to find the balance between my leadership duties towards my team and my desire to keep coding.

I figured I must not be the only one struggling with this, so I thought I’d give my two cents.

Why engineering managers should be technically competent

In my opinion, hands-on, technically competent managers are the best leaders for engineering teams (and the ones who escape the Dilbert Principle most of the time). As a technically competent manager you will:

• Be able to understand the hidden complexity associated with the tasks your team has to perform, making it much easier to communicate with the team members, and simplifying that message for non-technical stakeholders like Product or Marketing.
• Mentor your team of engineers more effectively and be able to lead by example in the technical domain.
• Be aware of new tools and frameworks your team might be using and be able to give better technical direction.
• Be more likely to be trusted and respected by their team of engineers. That is not to say that non-technical managers can’t be respected or trusted.
• Keep your options open to go back the Individual Contributor track in the future.

Ok, we agree it is a really good idea to keep and improve your engineering skills. But that doesn’t come without challenges.

Coder vs Mentor

The first challenge you will likely face is the conflict between your engineer self and the mentor self: Your engineer self will want to solve all the interesting technical challenges your team faces. In the other hand, your mentor self should want to give the problems to team members who can use them to improve their skills and become better developers.

This problem can be acute in teams with many junior members and a lack of senior engineers to mentor them. In that case, the engineering manager will have to put even more emphasis on the mentorship aspect of her role.

Make your team successful

Your team and your people come first, before any coding. It’s a necessary condition: If and Only If your team is successful you can dedicate some time to coding.

As a manager you are not building a product, you are building a team that knows how to build products. Thus, making your team succesful should be your primary goal and metric to evaluate yourself against. If you lead a successful team of happy engineers, the team’s success will speak by itself and you will need to spend less time in meetings trying to explain or sell your achievements to your peers and superiors.

A self-sufficient team of empowered individuals where you are not the decision bottleneck will give you some additional bandwidth to spend doing something else.

Your words have more weight

Another challenge for me was being too vocal or expressing my opinions too strongly when the team was discussing how to tackle technical problems. I was unaware of this problem until a team member let me know during an open feedback session with the whole team. She said something like “You are too opinionated during our technical discussions… you should give more room to others”

While some managers are indeed very vocal and use power speech, I learned the hard way that it will prevent others from expressing any different/dissenting opinions they might have and you will probably end up with a worse solution to your problem.

My advice?

Always speak last and ask questions rather than give answers

I can’t stress enough how important this is. Hands-on managers have to be fully aware that every word they say or write is potentially silencing her team member’s ideas or proposals in some way.

James Everingham goes even further and suggests that just by observing, a manager is already changing the outcome of a project in his Quantum Mechanics analogy:

The observer effect is real in the workplace, and you can affect the outcome of any project as a manager simply by inserting yourself. Often, a manager will take their team into a room and say, “Here’s what we need to do,” or “Here’s what I’ve been thinking,” or “Here’s one way we can think about this…” as they start sketching on a whiteboard. They’re trying to add value. We always want to add value. But if you’re in any position of authority and you do this, you’ve just limited the number of outcomes and your path to success pretty dramatically.

Maker vs Manager

A more logistical challenge I faced was trying to blend the Maker’s schedule with the Manager’s. In Paul Graham’s words (emphasis added):

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

In short, the fragmented, reactive and meeting-driven schedule of managers simply doesn’t bode well with the concentration coding requires (which is a kind of Deep Work). One could say the characteristics of the manager’s and maker’s schedule are antagonistic: an engineer needs as few distractions as possible while a manager who doesn’t attend meetings or doesn’t interact with other teams can get her reputation penalized for “not being visible enough” in the organization.

Don’t mix the two schedules

http://dilbert.com/strip/2012-05-30

Don’t even try. It’s a recipe for feeling frustrated and unproductive. Like water and oil, the best is to keep them in their natural state: separated and independent from each other.

I try to separate my schedules with natural interruptions like lunchtime break. Grouping all my meetings back-to-back in the morning, while exhausting mentally, leaves my afternoon free to wear my Maker hat and concentrate in tough programming problems. I try doing so at least twice a week.

I found that having an ample lunchtime break, having a walk outside the office if at all possible, is perfect for my mind to disconnect and reset from meetings and come back refreshed to code productively.

While wearing your Maker hat you should avoid all possible distractions. To begin with, turn off email. Then, close all the distracting tabs from your browser — ehem, Facebook, ehem — or open a new browser window just to consult the documentation you need. Lastly, I would also turn HipChat/Slack off. Of course you should always leave some communication channel open for urgent issues, for the right people (your team) to reach you if necessary.

Being able to be productive and focused depends heavily on the context you are physically and mentally in. By tweaking and adjusting your environment (working from a different desk/place, listening to certain type of music, whatever works for you), you can go a long way to triggering the right mental context to be as productive as you can.

You can get many more tricks on how to deal with shallow vs deep work in Cal Newport’s Deep Work.

Being the code bottleneck

Given your busy schedule you will probably find it difficult to finish any coding tasks in a timely manner, which means you will probably be blocking some feature from getting merged and deployed to Production. Even worse, if something goes wrong, you might not be able to tend to urgent technical issues like live site issues or pipeline breaks.

As the team leader you should be busy shielding your team from distracting meetings and conversations while they can focus on coding. Again, your job is not to code but to ensure that your team can code effectively, and help your team socialize their achievements.

Your code doesn’t have to ship

A good friend gave me this advice when we were talking about hands-on, technical managers:

You can’t be your team’s bottleneck. You need to coach and mentor your team members to be able to tackle all technical challenges without your help. You should never be needed to write production code. A great use of your coding time is the non-feature dirty work. Make the build faster, extract some shared behavior into a nice library. Look for things that will make things more productive or more fun for the team. You can also keep your technical skills by focusing on coding Proofs Of Concepts, explore new technologies for your team to use, or work on side projects within the company or on your own.

I took that advice to heart and I couldn’t be happier with the results. Not only do I feel less stressed knowing that I am not the technical bottleneck of the team, but my team members have had many more opportunities to face challenges by themselves, learn and become better developers in the process.

In order to pass down my technical knowledge I pair code on interesting problems and I also run “Clean Code Sessions” where the whole team solves technical problems together through mob programming or just share some technical knowledge and opinions.

Nowadays the bulk of my coding is on side projects, either in Expedia (like the Expedia Alexa Skill) or my own side projects like markpress or my useless-but-cool-looking Rolex GMT Chrome Start tab extension.

Conclusion

Being a manager who can code is like having two jobs. It requires hard work, and lots of dedication. It’s very easy to feel overwhelmed or burned out if you don’t manage well the fine balance between leading and growing your team and honing your tech chops.

I’d say you need to love both leadership and coding to pull it off, as you will need to spend lots of your free time improving your manager self and/or your maker self, but hey, it’s worth it! And after all, this is life.

Further reads

• Developer turned manager — Article by Stackoverflow’s David Haney
• Average vs Great manager — Article by Facebook’s Julie Zhuo
• Maker’s schedule, Manager’s schedule — Article by Paul Graham
• Deep Work — Book by Cal Newport
• Team of Teams: New Rules of Engagement for a Complex World — Book by General Stanley McChrystal
• The Principles of Quantum Team Management — Article by James Everingham, Head of Engineering at Instagram.

If you enjoyed this article you may also like my take on high performing teams and their culture.