Image via pixabay.com

Revisiting the Tech Lead/Manager Role

Posted in Engineering, Management

A couple years back, when I was first getting into management and learning from some of the best managers I’ve ever had the privilege of working with, I concluded that the Tech Lead/Manager (TL/M) role—whereby one person serves as both the technical anchor as well as the people lead—is best served as a transitionary role. I wasn’t certain that someone should take on both roles, due to the time commitments as well as the intrinsic conflict of interest that comes from both responsibilities.

Now that I have a few more years of observation and experience under my belt, I’m more open to this hybrid role. My shift in thinking is grounded more in practicality than philosophy; I’ve found that it’s uncommon for teams to have quite enough resources—both budget and time—to include both a strong technically-oriented engineer and a people-oriented manager. The most senior engineer takes on people responsibilities as a matter of convenience, not desire.

The bug here is that without strong intrinsic motivation to level up as a manager of people, it’s too easy to settle for a role that places technical leadership at the forefront, with a helping of people stuff on the side. It may look like killing two birds with one stone at the onset, but the lack of attention to detail on the individuals on the team will eventually take a toll, in the form of lack of team cohesion, team and project scalability challenges, or simply lead burnout.

All that said, I’m beginning to piece together a picture of how a TL/M role can work for the long run. Emphasizing right conditions may be sufficient to mitigate some of the aforementioned pitfalls:

  • A major delta in seniority & ability between the TL/M and the rest of their team. This makes elevating someone into a TL position impossible, but the team will respect their manager’s technical intuitions based on merit and not necessarily just authority.
  • A small team. This prevents the TL/M from being overloaded with people responsibilities.
  • A limited project domain. This segues the TL/M’s working knowledge of the project with their reports’ work within it, as opposed to a more matrix-style management structure where the manager has to spend additional time to learn about what their reports are doing.
  • A manager who has the capabilities to lead large teams. That demonstrates their ability to focus on people when needed, and ideally keeps the TL/M’s technical inclinations in check.

Beyond these criteria, an important realization for me is understanding that for some managers, this is where they are most content. Traditional management literature has the line manager as the first step on the management career ladder, with bigger and better positions to reach, but I’ve met enough folks now to appreciate that the abstract nature of higher levels of management pales in comparison to the hands-on nature of a TL/M. It’s a stone’s throw away from those engineers who never want to touch management, who are driven by the need to build.

I can relate to that.