You’re the Tech Lead, Not the Tech Guru
You’re the Tech Lead, Not the Tech Guru
Being a Tech Lead shouldn't imply that you are the singular expert in the room, but that you are in charge of leading the experts in the room.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
I liked to say 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: the right project, right teammates, and 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 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, 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, especially 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 your key dev is starting to burn out due to all the extra hours he’s been putting in and asks for a couple of days off, 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.
- 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.
That's it for now, let me know what your thoughts are regarding technical project management. Also, if you want more content like this or are looking for Node.js related books, please visit my site at www.fernandodoglio.com
Thanks for reading!
Published at DZone with permission of Fernando Doglio , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.