Or as I liked to call it during high school: I don’t need to know all the answers to the test, I only need to know the phone number of the guy who does.
People often get confused by the fact that because a technical leader is supposed to guide and lead a group of technical experts, he or she needs to be the ultimate guru on every technology related to the project they’re working on. The truth of the matter is, achieving that is simply not possible.
Don’t get me wrong, it could happen under the right circumstances: right project, right teammates, the right set of requirements. But honestly, how often does that happen? Think about it, think about every technology you’re an expert on, how many are they? Two? Three? More?
Let’s be honest for a minute here, the usual tech guru is either:
- Really proficient in one technology and fairly good at many others.
- Or really good at many technologies but not really great at any of them (the oh-so-well-known “jack of all trades, master of none”).
And this happens not because I say so, or because there is some strange and unfair rule on the IT industry that prevents you from being a guru on several technologies at the same time in your career; this simply happens because of life. You’ll eventually end up having one, whether you want it or not, and it will take time off from you. You won’t be able to stay up to date on the constantly changing IT scene, there is always going to be a new JS framework to learn, a new JAVA version to read up on, and so on. Simply finding enough time to do so, and at the same time, handle a personal life (say meet with some friends, get married, go out, have kids, and a long list of other social things) can become impossible, unless of course, you find a way to have days that last longer than 24 hours (if you do that, hit me up, we need to chat).
So with that being said, how many different projects do you think you can lead and still remain the most knowledgeable one on it?
And let me ask you a different question as well: how useful would you say you’ll be to the project, being the top performer on a role (be it as a developer, tester, business analyst, or whatever role you think you should be doing) who’s not actually doing that much work? Because trust me, you won’t.
The first thing you’ll want to do if you want to be a successful Tech Lead (or at least a mildly good one at that), is to accept the fact that you’ll be leading people that are more talented than you, period (at least at what they’re paid to do).
In fact, I would take it one step further and say that you want this to happen because this will mean that the people in your team are talented enough to get the job done, instead of depending on you, while you’re doing your job, which is facilitating theirs.
Again, this is not a rule and depending on the size of your team, it might not be the case for all your team members. You might end up with a team of mixed skilled members at the same time (some being more senior than you and others not so much); but just aiming to have at least one or two who are indeed, better than you at the technology at hand, will prove to be beneficial for the entire group. This setup will free you from the task of coding and it will, in turn, give you time to make the team grow. A good leader is one that focuses on the team, helps them grow, tutors them, shows them the right path, instead of being one that does their job for them.
Usually what tends to happen in these types of scenarios, is that the junior team members start raising up to the challenge of keeping up with the more senior ones.
When you’re a tech lead, you need to put your ego aside (something that, let’s be honest, might not be as easy as it sounds) because you’re basically working for others. You’re between a rock and a hard place (as they say) because you need to look out for your project’s well-being and at the same time, you need to look-out for your team’s well-being, which on certain occasions, are not the same thing.
Let me give you an example: what happens when your key dev is starting to burn off due to all the extra hours he’s been putting in and asks for a couple of days of, right when your managers are asking for a demo of his feature? Is the project the important thing here? Or should you eat some sh*t and fight for a new demo date, giving your key player those well-deserved extra days? Think about it…
Especially when the pressure is on, be it because your PO’s or managers are pushing your team, or because your team has a lot of internal drama, or whatever life might throw at you, you’re still in the middle. Back to the point
You’re not the King of the team, you’re just another pawn.
When creating your team, a couple of good pointers (at least things that have worked for me in the past) are:
- You’ll want people who can focus on their tasks (and be the King at them), so you don’t have to do it for them (micromanagement is the worst thing that can happen).
- You’ll need to understand who you’re working with, to know when to push and when to back-up.
- You’ll need to know when to let the pressure from outside leak into your group and when to act as a dam, taking care of all those problems so your team can keep working stress-free.
- But you’ll also have to be honest and take responsibility with management (or whoever is contracting you to lead the project) when things go south. It’s your team, after all, it’s your responsibility. If the project failed, there is a good chance you should’ve seen it coming (there are exceptions, like with any other rule, obviously)
Final thoughts
I’ve written too much already, but these are the most common things I’ve learned (or to be more accurate, I’m still learning) about being a good technical lead. Remember:
- It's not about you.
- You're just a part of the team, with a very specific role to fulfill, and that is not to micromanage everyone all the time.
- You need to learn to trust your team and the knowledge they have.
I hope this shines some light on the role, so you know what you’re going to be getting yourself into if that is what you want. What do you think? Agree? Disagree? Leave a comment below and share your thoughts!