The Lure of the Tech Lead Manager and Why You Should Avoid it

There's this never-ending debate on the Software Engineering community on whether Engineering Managers should be heavily involved in technical decisions or not. On the one hand, Engineering Managers need to develop their people, and on every technical decision they make, they steal a development opportunity from their Directs. Hell, in many cases, when we give our opinions in a discussion, we unknowingly tip the scale to our own opinion, something that got a cute acronym: HIPPO. But, on the other hand, Engineering Managers need to be responsible for their team's Technical Excellence. If they're too far from Engineering decisions–or don't come from a technical background–their technical knowledge will fade. Eventually, they'll have no other option but to abdicate their responsibility.

Enters the Tech Lead Manager (TLM), an Engineering Manager who also plays the role of a Tech Lead and the solution to all our problems. But, with a tiny caveat: it might be a trap. Here's how:

1. Relying on TLMs could be a trap to the company: It is arduous finding people who excel both as a Tech Lead and an Engineer Manager. There aren't that many in the market. It's common to hire someone who either fails at managing and developing their people or making good technical leadership. TLM is a tough chair to fill and to sit on.
2. Being a TLM could be a trap to the TLM: Being a TLM is not only very hard, but it's also usually a dead end. The most common paths forward in the career are either Staff Engineer or Group Engineering Manager. In the position of a TLM, it's hard to develop critical skills for both these positions.
3. Having a TLM could be a trap to the team: It's common for Tech Lead managers to rob the team of opportunities to grow. TLMs end up working and making critical technical decisions on projects that would otherwise be great opportunities to level up the engineers in the team. In organizations that rely heavily on TLMs, it's common to see a lack of Senior+ Engineers, and it's not hard to understand why.

You probably noticed that there are a lot of "common," "usually," and "hard" s there. I'm in no way saying that all TLMs are bad for their company's, themselves, and their teams. There are situations, particularly in smaller (3-4 people) teams, where it makes sense and there are TLMs that are brilliant at their craft. There are also people that excel at having this responsibility. I'm saying that:

1. It's tough to scale that role;
2. On a lot of the cases, we should consider making it a temporary position with a later decision on which side of the career (technical or manager) the TLM wants to go on and

Yet, believing this is the easiest way to scale up engineering is widespread in growing companies. After all, no trap is a good trap if it doesn't have a strong lure.

The Lures of the Tech Lead Manager

"My team is made of Junior and inexperienced Engineers. If I don't make the technical decisions, our product will suck." The passive voice in this sentence exposes a lack of ownership for building the team. It shows that, to this person, building a team that's up to the challenges they have is not something we can and should focus on. There's a gap in the team for a Senior Engineer they're trying to fill. If they're focusing on developing these people's careers–doing their job as a manager and a leader–they won't have the time to do it appropriately. So filling that gap, either through training one or more of the engineers or hiring someone, should be the primary mandate, and they won't be able to focus on that if you're playing Senior Software Engineer.

"It's an easy way to start learning as an Engineering Manager." It might be. But beware that the skills needed to be a good Engineering Manager are seldom why people fail to do that job. It's their values and consequently how they apply their time that make them fall short. Being a leader is challenging and implies doing a lot of uncomfortable work. When people feel like they need to be the most senior engineer, they will find excuses to avoid that work and focus on things they already know how to do and that are easier for them. It creates excuses for that Engineering Manager not to grow and do the work that only they will do. So the only conditions in which we can do both very well is when the management workload of the team is light to that specific manager. This usually translates to smaller teams or teams with a relatively simple product context.

Ok, so is the solution to abdicate technical responsibility, then?

Yes and no. Abdicating the responsibility for the technical output of the team is a trap as well. Engineering Management is still a technical role at heart. Engineering Managers need to drive the team to technical excellence. But what they do need to abdicate is the thought that they need to make the decisions to be responsible. An Engineering Manager's primary focus is the team. Preparing and coaching the team is their work. When we have a well-prepared team, the score will take care of itself.

Control, we discovered, only works with a competent workforce that understands the organization's purpose. Hence, as control is divested, both technical competence and organizational clarity need to be strengthened.

–Marquet, L. David. Turn the Ship Around!

Once we divest control, we need to do our job harder. In return, we get stronger and more motivated teams. It's not an easy job, but building the team is any manager's actual job.