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, him or her 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, 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 on 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 etc) 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 role (be it a developer, tester, business analyst, or whatever role you think you should be doing) who’s actually not 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 it), 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, and will be focused on doing it, while you’re doing your job, which comprises of 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 tutoring and monitoring more junior members, specially during the first few weeks or months of the project.
Usually what tends to happen in these type 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 in certain occasions, are not the same thing.
Let me give you an example: what happens when you’re 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…
Specially 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.
- 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)
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.
I hope this shines some light into the role, so you know what you’re going to be getting into if that is what you want. Or into what your managers have to deal with in the day-to-day of your project :)