Congratulations! You're a Tech Lead. Now What?
You’re a rockstar developer. Or maybe you're an awesome QA. Your organization noticed this and you’ve been promoted to tech lead. Sounds great, right? You’ve always wanted this. For years, you’ve wanted to have bigger say in the team. You know you can make better decisions for the whole lot. After all, many of the great results achieved by the team were borne out of your ideas. Plus, the pay raise can only lead to better things for you.
But then something strange happened. Somehow, some way, the whole team seems less cooperative. You can’t affect the changes you’ve always envisioned even before your promotion. Why aren’t they listening? They all know the value you bring to the team. They’ve all seen your contributions. They all listened to your good ideas that resulted to better outcomes for everyone.
So what happened? Let’s take a step back and analyze the situation.
The Case for a Technician Becoming a Tech Lead
Generally speaking, there are two types of technicians. Each member of a tech team is some combination of the two. In most cases though, one is dominant over the other. And if you're very good in at least one, then you can become a tech lead:
The Collaborator - This is someone able to achieve good outcomes by leveraging on cooperation. He knows by heart that any large development project is collaborative by nature. So he quickly asks for help if needed. He also won’t think twice about helping others. When he notices a blocker, he will immediately raise it to be addressed. He does all of these and more to deliver the best project possible. As a side effect, his skills diffuse across the team and vice versa. In other words, he’s a real team player.
The Independent Contributor - This is someone who achieves good outcomes through sheer technical skills. Learning and applying technologies is in his DNA. As a result he is skilled in multiple languages, frameworks, techniques, tools, processes… you name it. Better yet, he knows when and how to use the appropriate technology for the job at hand. As a result, his works are a technical beauty. He's what you’d call a star player.
Regardless of which is dominant, a technician with an inclination to lead has the desire to take on more responsibility and accountability. His intention to be responsible for the team and/or the projects taken will remain to be seen. As a result, he grows in his abilities either as a collaborator, as an independent contributor, or both. Either way, this benefits the entire team. So the tech part of “tech lead” is already there. The missing piece is usually the ability to lead.
Contrast that to putting in place a great leader with minimal technical domain knowledge. Yes, he will be able to lead and inspire the team. But no, he won’t be able to get clarity on the direction the team needs to be lead to. In other words, the leader will have a difficult time learning the ropes if the tech part is the one missing. It’s like having the best navy admiral lead the air force. It just doesn’t work.
Organizations’ Expectations of Tech Leads
Okay, so maybe it’s obvious that a leader needs to have expertise in the domain his team is tackling. So we need to discuss the only other possibility - a technician growing to be a leader. (Or hiring one who’s already grown, but that’s besides the point.)
In truth, there are actually three distinct roles that technical leaders need to undertake. Unfortunately, most organizations expect tech leads to tackle two of these. The real problem is that this expectation is rarely communicated. In fact, some organizations aren’t even aware of the distinction.
Let’s skip the 3rd role for the purpose of this discussion. It's that of a project leader and is usually a separate position altogether. So here are the two roles expected of a tech lead:
Technology Leader - This is all about leading the technology direction of the team. Whether we’re talking about design patterns, architectural decisions, technical roadmaps, or anything in between, this role is the one responsible for them. It doesn’t mean that he makes all of the technical decisions. He may very well just facilitate over team discussions to arrive at specific decision points. But at the end of the day, he's responsible for the technologies that the team uses or builds. The penultimate position for this leader in an organization is typically the Chief Architect.
People Leader - This is all about leading the team members. This one is actually the common definition of a leader. But to provide distinction with the other two roles, we can say that this one's main objective is the development and growth of the team itself. His tasks include facilitating effective collaboration, ensuring productive individual contributions, capability development, and hiring, among other things. The penultimate position for this leadership role is the VP of Engineering.
An aside: I said penultimate because the ultimate position for both leaders is the CTO. This should underline the fact that CTOs need to be able to handle both roles very well on top of having enough business acumen to work at the executive level.
You will notice that the key differentiator between an individual contributor and any leadership role is that the latter has a multiplier effect. It is no longer about the amount of contribution individually made to the team. It’s all about enabling everyone else to contribute more. After all, the organization invests more on leaders simply because it gets more value from them. And we’re talking about multiple times more value here and not just fractionally more.
This notion is very obvious with the people leader, but may not be as visible for the other two. But if you really think about it - every technology decision, every detail of a project plan (or product backlog), is all about ensuring that team members become a lot more effective... way more effective than say, having them individually make the wrong decisions at their level.
This brings me to…
The Most Common Reason Technicians Rarely Become Good Tech Leads
It may have already become apparent to some of you. But the two kinds of technicians map neatly into the two leadership roles discussed. A technician who’s predominantly a collaborator already has the base skillset needed to grow into a people leader. Whereas someone who’s largely an independent contributor can easily become a technology leader.
Now, I’ve already said that organizations usually expect both roles from a tech lead. And depending on the scenario, there may be a greater need for one and less of the other. For example, if there is a Chief Architect in the organization but no VP of Engineering, then more of people leadership falls on the plate of tech leads.
The point is that the expectation from tech leads is very context dependent. But figuring this out is really just about expectation management. You and your organization need to get clarity on the real expectations for your position. After that, it’s only a matter of closing the skills gap to be effective.
Yes, I know that that’s easier said than done. But not being able to fill that gap will only affect your ability to handle the role opposite your strength. For instance, if you got promoted to tech lead because you were a rockstar developer, then not being able to learn the soft skills needed to be an effective people leader should not impact your ability to be a technology leader.
Now, being able to fulfill only one of the two roles expected of you has much much less negative impact compared to not being able to handle any of the two at all. And let me tell you that the latter is something I’ve seen a lot throughout my career regardless of how good the person in question was prior to promotion. So what is the reason for that?
focusing on individual contribution rather than enabling the team
As a people leader, your impact should be fairly easy to observe. Are all the members of your team able to collaborate with peers effectively? Do they have psychological safety to experiment and innovate? Or simply put, have your abilities been used such that you enable everyone else to be effective?
As a technology leader, your multiplier effect may be less apparent. But it should still be observable. Are your technical skills diffusing to everyone? Is there an avenue that makes the best solution discoverable even if it’s not coming from you? Have you provided a loosely coupled design thereby improving everyone’s development time and reducing maintenance work? Are members able to innovate safely because of guardrails you put in place? In other words, have your technical skills been used such that the technology decisions made enable everyone else to be more effective?
The key point to remember is this… the failure of any team member (or failure of a technical decision made by anyone) is your fault as a leader. This mantra should help avoid your ego from blocking your growth into a great leader.
Conclusion: Growing as a Tech Lead
One thing to note: All of these become nuanced because of pressure from your own higher ups. But as a leader, you should lead downwards and manage upwards. Yes, you still have to manage your team. But your goal should be to become the leader that you wish you had and not the boss that you hated. So again, “lead down, manage up”.
Now finally, we circle back. If you notice that your team is not turning into the power house that you envisioned, maybe it’s time to check your focus. You should stop looking at your individual contributions and start focusing on what you can do to make the whole team much much more effective. Whether you do it with your soft skills or your technical skills should not matter much. Of course, it’s great if you grow both. But the more important thing is that your skills have a multiplier effect on the whole team.