In a strong engineering organization, there are typically two main technical leadership tracks. Different companies have different names for them, and their responsibilities can sometimes overlap, but for the sake of this discussion let’s call them “leads” and “managers.”

The lead is the alpha nerd – this is the engineer who guides the team technically, acts as a technical mentor, takes responsibility for code quality, sets standards, interviews candidates, and will generally have some role (whether direct or supervisory) in the riskiest projects. Architects fall into this category, as do the most skilled coders. Leads don’t have direct reports, and spend most of their time in technical pursuits. This is the principal / architect / CTO track.

The manager, on the other hand, is typically a more administrative role. She has direct reports, and does 1:1’s with them on a (semi-)regular basis. She mentors her team on their careers, provides feedback, writes status reports, attends meetings, writes (and delivers) performance evaluations, mediates disputes, fights for resources, and has the final say on hiring for her team. She may take on some minor technical tasks, but is typically too busy following up on a hundred issues and doesn’t have time to make a significant technical contribution. This is the manager / director / VP track.

As people progress in their careers, it’s natural for them to want to take on more responsibility. Unfortunately, it’s all too common for someone with no interest in administrative tasks to latch onto the idea of a management role. I have this conversation with candidates all the time – you can see their eyes light up as I describe the lead role… Then watch as their shoulders slump as I describe what a manager does. They think they want to manage people, but what they really want is to be able to keep playing with cool toys while progressing in their careers.

Technical managers need to be technical¹, but they have to be at a point where they’re energized by the non-technical tasks that most engineers think of as annoyances. Unsurprisingly, this is hard to find. People tend toward tasks that match their personal interests, and managers who should have been leads tend to steal time from their teams to do project work. Successful managers learn to find satisfaction on completely orthogonal axes from their direct reports (and, by extension, their previous selves). You want someone who’s going to be fully committed to breaking down tasks, estimating schedules, following up with recruiters, scheduling stand ups, grooming the backlog, and so on. That doesn’t mean she’s going to wake up excited about a day of back-to-back meetings, but she’s going to be willing to prioritize the most important work, even if that means having to wade through a fair amount of tedium.²

Of course, being a manager isn’t always forever. As someone who’s bounced back and forth between lead and manager roles for some time, I can tell you that it’s easy to get burnt out on managing. But it’s easy to get pulled back in, too. Being a manager can be, and frequently is, a great experience. Many of the things I feel proudest about were things I accomplished as a manager. My most boneheaded mistakes too, but that’s the way it goes.

¹ There are those who disagree, but in my experience a non-technical manager is severely limited in how she’s able to support her team.

² Yes, I’ve read Death by Meeting. No, meetings don’t have to be boring. But you get the point.

Follow me on Twitter