Editor’s note: Adam Evans is the co-founder and CTO of RelateIQ.
When it comes to the task of finding and nurturing great engineering managers, misunderstandings at startups are all too common. It seems that many people assume great engineers don’t want to “give up” coding to take on leadership roles. To be clear, this is flat out wrong — and could create tremendous churn in your talent pool if you fail to recognize and elevate leaders in engineering as you would with any other team.
But, you might argue, engineers are introverted, right? And they would rather ponder big problems than worry about resource allocation? And they aren’t really interested in business problems as much as tech problems, correct?
The answer to all of these suppositions is “Not really.” All of these are just biases, or preconceived notions of what an engineer is like. We have some fantastically chatty engineers, and we have some quiet ones. We have some developers who would kill me if I asked them to do performance reviews, and some who genuinely enjoy coaching and mentoring as part of their jobs. It just depends.
Engineers, like all other teammates within your organization, run the gamut in terms of interest and proclivity for management roles. Some, I’ve found, just need a nudge to get there. They need you to frame the challenge in the right way to make it accessible to them.
So here’s my pitch to my engineering team: Anyone involved in management is a programmer. Being a leader within your organization requires you to master the art of motivating and coaching people, which isn’t all that different from, say, programming a person.
Sounds silly, I know, but think about it: As a programmer, your sole mission is to get a computer to do what you tell it to do — run the program the way you designed it to run. You spend all day trying to get that computer sitting across from you to follow your instructions. And it’s really stubborn. One bad keystroke and it doesn’t listen to anything you say. Maybe this metaphor is becoming more clear to anyone who has had a challenging direct report in the past.
There are major differences between programming computers and programming humans, of course, not the least of which is that some runtimes are much more volatile when you’re programming people.
Talking about programming humans really mimics how an engineer approaches a problem. Framing the management role in this way makes it instantly accessible, even to developers who never saw themselves enjoying management — and that’s something we can all agree is a welcome development.