Ask HN: How hands-on should an Engineering Manager be? I've been in various engineering management roles over the last ~10 years of my career, and the amount of hands-on coding has varied a lot. What works for you? |
Ask HN: How hands-on should an Engineering Manager be? I've been in various engineering management roles over the last ~10 years of my career, and the amount of hands-on coding has varied a lot. What works for you? |
First, my philosophy on management is that you are constantly asking yourself two questions:
1) How can I help you? (e.g., unblock you, mentor you, take stress off your plate)
2) How can I get out of your way? (i.e., trust you to do the job you were hired to do)
For 2-3 engineers, I'd say anywhere between 50% and 10% of time should be spent hands-on in the code. I'll go ahead and lump code reviews in there. Since there are so few engineers, you probably aren't spending 40 hours a week in meetings and managing people problems, so that gives you time to still be involved technically. I think this is a sweet spot where most engineers I know would like to be in.
For 4-8 engineers, I'd go closer to 10% to 0% being hands-on in the code, including code reviews. I recommend EMs do code reviews as often as possible, so you aren't out of touch with your codebase, but at this stage, you're likely spending more time in project management meetings and 1:1s, and so you have less time to write code. This is fine, because again, you're involved but spending more time on the people side of things.
For 8+ engineers, you're almost certainly at the 0% code point and are spending most of your time in meetings or high-level architectural reviews. This is also fine -- good, even! But at this point, you've lost the benefits of smaller team management that can be hands-on in the code. It might be time to consider hiring another manager or promoting from within to get back to that level of technical mentorship and rigor.
Remember, your goal is to enable your team to be successful, and as the team grows, most of that entails being a shield to protect your team from external requests and also to facilitate their growth, whether personal or professional. As the team grows, your force multiplier stops being code-based and becomes people-based, and the more you can delegate and facilitate your team's growth, the more successful your team will be.
A Director of Engineering writing code is probably not the best use of her time. If she instead spends that time unblocking two of her ICs so that they can do their job, that's way more efficient than doing it herself.
A LOT of new engineering managers struggle with this. In fact, I'd say most EMs that I know have a hard time letting go of the code, and act almost like principal engineers or architects, instead. For small teams, this isn't a bad thing, but it doesn't really scale well.