Beware the manager who codes too much

Dispelling the myth of the hands-on engineering manager

I read an interesting article by Anton Zaides over at Leading Developers that laments the Slow Death of the hands-on engineering manager, which made me perform the Spock eyebrow maneuver. You know the one:

The myth

I’m not writing this simply to refute a newsletter with over 10,000 subscribers, and I don’t disagree with everything Zaides wrote, but I am disappointed to see someone with such a large following perpetuate (perhaps unknowingly) what I think is a harmful myth in the tech industry: that Engineering Manager’s need to be very hand’s on in order to be effective leaders. What Zaides calls the slow death of the hands-on manager is actually a good thing. All too often, organizations fail to understand that the engineering manager is not a tech lead. 

Recently there has been a resurgence of this myth of the hands-on manager, with tech companies advertising roles that expect a manager to divide their time between substantial individual contributions to the codebase as well as handling all the responsibilities of a people manager—which is untenable and creates managers who succeed at wearing one hat but fail at wearing the other. 

To make matters worse, behemoth tech company trendsetters like Amazon are planning to do mass layoffs of managers, undermining the purpose and value of management altogether. I predict this is going to backfire on Amazon because other big tech companies have already experimented with working without managers, and it didn’t work. But it’ll cause a lot of career damage while they find out the hard way.

[Aside: I’m not saying that operating without managers is impossible. There are some intriguing case studies such as Morningstar that seem to have pulled it off—but they have a very different corporate culture that is people-first and egalitarian, the total opposite of how totalitarian companies like Amazon tend to function.)

Zaides says that there are two types of engineering manager:

1. Super hands-on - they take tasks in every sprint, know the codebase, and help the team fix hard bugs.

2. Full-time managers - attending meetings all day, having 1:1s, zero coding time.

Reality

In my opinion, example 1 above describes the role of a Tech Lead, not a manager. Example 2, whether you like it or not, is more realistic in terms of what an actual Engineering Manager should expect. Think about it: if you’re leading a tech team that consists of smart and talented software engineers that you have hired for the role, why would you need to spend much of your own time coding? And why did the organization hire you or promote you as a manager if what they really wanted was another software developer? No, what your team needs from you is oversight, guidance, coaching, mentoring, support, career advice, someone to set an example as an attentive, empathetic, and authentic leader. Trust your team to write the code, that’s why you hired them. 

Zaides goes on to say that Engineering Managers should find small coding projects to work on in order to stay sharp and technically proficient—and I have no problem with that. I totally agree that if you can fix bugs, create little apps or efficiencies to save time, or cut down on monotony and repetition it will benefit you and your team. That’s a cool and generous thing to do. Not only does it keep you up-to-date on new coding practices, languages, and frameworks, but being able to understand the code your team members are working on will validate your ability to empathize with them much more than if you never opened an IDE. Your developers will appreciate you being able to speak their language and grok the problems they are trying to solve. But staying outside the critical path is crucial, I can’t stress that enough. If you end up distracting the team too much by having large changesets that need reviewing, development branches that prevent code deployments or anything that causes major fires in production you are going to earn resentment and distrust from your direct reports.

Environmental hazards

You must also beware of the trap that any side work in code could severely distract you from your core responsibilities as a people leader. You should never let a code project make you unavailable or inaccessible to a direct report who needs you to be their leader at any given time. If you’re too heads-down and in the flow state when your team needs you to help with an overall strategy, facilitate an important discussion, make a critical decision, or handle a tough interpersonal conflict among team members, you will end up having a detrimental effect and you won’t build a good reputation as a manager that people want to work for. And I say this from experience, because I’ve worked as a manager/tech lead who was very much a front-line code wrestler while simultaneously trying to lead from the back, and it was a world of hurt for both myself and my team.

Another thing, be careful that you’re not projecting an air of superiority: maybe you were the smartest person in the room when you were a software developer, but you’re supposed to be a humble leader now. Don’t behave narcissistically and try to portray yourself as the expert who sets all the standards that your developers must adhere to. They need room to experiment, learn and grow, through trial and error and the right balance of autonomy and guidance. It might be okay to be a smart-ass when you’re a developer, but not so much when the people whose career is in your hands need you to be open-minded and in possession of a growth mindset. 

You should also be aware that your own manager may be a believer in the myth of the hands-on manager, because, as I’ve written about before, this is kind of an institutional problem born from a toxic tech idea that real techies are always coding and that soft skills aren’t as important and don’t require any effort to cultivate. The truth is, that developing the soft skills of a great manager is a whole journey unto itself and shouldn’t be taken lightly or neglected. Learning how to relate to people, how to motivate and inspire them, how to read them, and detect problems that prevent people from being their best at work is something you absolutely should be committed to if you want to become an effective leader. You’ll be doing yourself and other managers in your organization a disservice if you act in a way that undermines the value of people management. If you put little energy into the essential work that managers should do on a team and focus instead on writing code you’re sending a signal to upper management that your role isn’t very critical at all and maybe, just maybe, they should save some money and emulate the Amazon way in future. 

Choose the right path for you

In my opinion, if you find yourself missing the code wrangling so much that you resent having to close your code editor to have a 1:1 meeting or deal with some managerial overhead then you probably shouldn’t be in the role of Engineering Manager. You might want to consider moving back into a software development role. In this case, there’s no shame in recognizing that you have more passion or affinity for one track over the other. Either track can lead to future career growth and higher earnings, so there’s really no reason to force your round self into a square hole. 

---

Okay, my eyebrow is hurting so I’m going to lower it back down now. Leading Developers has some worthwhile content and I hope Anton Zaides will appreciate that I’m not trying to start a flame war, just adding to the conversation. Thanks for reading.