On being "technical" as an engineering manager

∙ 4 minute read

In a recent article on Increment, Will Larson asks: “Do engineering managers need to be technical?” It’s a strange question because, as Larson points out, the answer seems an obvious “yes,” yet it’s surprising how often, and how surreptitiously, this question comes up.

One of the oft-maligned side-effects of moving from engineer to management is the atrophy of one’s programming and other technical skills. After a few years, this can lead some managers down the road to imposter syndrome — to wonder whether they are still “technical” or “technical enough” for the job.

This is often compounded by the hiring process, particularly when an experienced manager seeks out a new role elsewhere. One of the challenges many companies often face when hiring an engineering manager is creating an interview process that balances evaluation of people skills and technical skills. Companies want a process that evaluates both a candidate’s leadership abilities and experience as well as their technical abilities and experience. Generally, however, the process that gets implemented tends to skew things one way or the other, largely swayed by the bias of the interview panel or hiring manager. Teams want someone who can lead, but they also want someone who is “technical.” What they get is what they value more. Even teams who place great emphasis on leadership still tend to worry if a candidate is “technical enough” for the job, in the same way they wonder if someone is a “culture fit.”

Few would argue against the idea of having an engineering manager with relevant technical experience. At this point in the evolution of the software industry, it’s a fairly universal practice to only hire engineering managers who come from a software engineering background. Technical experience, to some degree, is a de facto requirement for nearly any engineering management role.

Of the myriad reasons for this, perhaps one of the most important is the need for a manager to be able to ask good, informed, pointed questions. Sometimes this is necessary to help sniff out risk. Sometimes this is to help ensure a team has thoroughly explored a problem space. Sometimes it’s for coaching. Sometimes it’s to make sure a problem even needs solving, or is the right problem to solve. Sometimes it’s to better assess priorities. Technical experience in a particular domain allows you to do all of this better because you can more easily recognize the shape of certain problems, as well as anticipate some of the challenges one might encounter in trying to solve them. Remember: A manager’s job isn’t to be the most technically competent person in the room; it’s to get the best out of everyone in the room. But without technical experience, you don’t know what you don’t know, and that makes it difficult to ask the right questions.

So, we know that we want managers with technical experience. But what does it mean for a manager to be “technical?” Not much. I have to agree with Larson; it’s high-time we give up this silly designation and start diving into specifics.

… “being technical” has lost whatever definition it once had and has completed its devolution from demarcation to slur.

Context matters. The question we ultimately care about is not whether a manager is “technical,” but whether that person is the right fit for the role (and whether they remain the right fit for the role). “Engineering manager” means different things in different places at different times for different teams. A new front-end team at a small startup has different needs than a backend team at a rapidly growing mid-sized startup, or than a mobile engineering team at a large, established company. Sometimes a manager might be expected to write code, but most of the time that’s simply impractical and unnecessary. So it’s important to be clear about not just what “technical” means given the context, but also what “technical enough” means. You have to dive into details:

There’s no right answer. What teams should care most about is that their manager is “technical enough” to help analyze problems in the domain in which they work. And this all comes back to being able to ask good, pointed, analytical questions. In an industry with plenty of “technical engineering managers,” that’s what matters most.