Some time ago, I published a blog post entitled “Love to Code”. The post was loosely inspired by a blog post from Jeff Atwood and another by Joel Spolsky, only my post was specifically advocating that people who *manage* Software Engineers should love to code. In hindsight it didn’t offer much in the way of interesting content; it was essentially an emotional appeal for managers to stay in the weeds and keep their hands dirty, because intuitively as a manager I felt those things made a difference.
In the time since, I’ve crystallized my thinking on both 1) the goals for an Engineering Manager (and I’m using that term loosely to mean “anyone who manages engineers”, whether it’s a small team or a large organization) and 2) why an Engineering Manager needs to love to code and stay technical to achieve those goals, and I figured that it made sense to go and touch up the old post with some of my more recent musings. In my mind the primary goals of every Engineering Manager are to increase team engineering throughput and channel that throughput in the right direction by:
- Mentoring and growing engineers on the team.
- Hiring (and occasionally firing) engineers so that the team is staffed with the right number and mix of people.
- Organizing engineers on the team to minimize friction and execute on the product vision.
- Directly contributing engineering horsepower when appropriate/necessary.
Note that I’m not claiming that this is an exhaustive list of goals, and in many contexts an Engineering Manager may have a many other goals in addition to this set. For example as an Engineering Manager on the Service Availability initiative at Riot Games, I spend a lot of time thinking about the roadmap for the technical products that we’re building and thinking holistically about our company-wide hiring strategy for engineers (which are related to, but not identical to #3 and #2 in the list). I am claiming that this list is as close as it gets to a lean set of goals that apply to managing Software Engineers in any context. I would argue that none of those goals are fully achievable by a manager who isn’t technical or doesn’t spend some time doing engineering work, and I’ll briefly explain why.
Mentoring engineers requires some measure of empathy and understanding on the part of the mentor and respect on the part of the mentee, and those things are best established by spending some time shoulder to shoulder in the trenches. The process of hiring engineers involves making a call on a candidate’s technical chops based on a very thin slice of data, and a hiring manager will make better hiring decisions if she is doing engineering work because she understands the nuances of what it takes to be successful. The effects of Conway’s law dictate that teams will produce software that mirrors the shape of the organization, which makes it vital that managers driving the discussion on how to best organize are familiar with the technical domain. And finally, every team will go thru crunches where an extra set of experienced hands on deck can make the difference between shipping the product on time or missing deadlines.
The skeptic will argue that each of these things can be outsourced to others (for example to Senior Software Engineers on the team or elsewhere in the organization). To be clear, I don’t fully disagree; goals are fluid and both the priority and ownership of the goals may change based on context. I fully acknowledge that in large cross-functional organizations at some level, a leader can’t be an expert in every function. As a brief aside, this is why I think that an organizational structure like Riot’s “matrixed” model is more effective (which probably warrants a post of it’s own). I will claim that over the course of a career, Engineering Managers who stay technical, love to code, and focus on this set of goals will be far more effective than those who drift into “pure people management” territory and cross-their fingers, hoping that others can fill in the gaps and help them to accomplish goals that they aren’t equipped to deliver on.