This part six of a larger series, get started with the introduction. Read the table of contents to see all the posts so far.
The tension is quite literally in the name. Are you a technical authority? Or are you a leader? You can be either without the other, yet to be a tech lead you must excel at and be both. As a full time individual contributor you almost certainly have a natural strength. If it’s pure technical expertise it is often fairly obvious. Your strength is designing and implementing systems. If it’s tending towards leadership, it’s somewhat harder to identify without being in a leadership position. Your strength is probably glue work, naturally facilitating, caring about the people in your team and more. Remember, this doesn’t mean you can’t be strong at the other before you’re a tech lead, but I think it’s helpful to at least mentally place yourself on this spectrum. This is the first step, because it will help you pick and choose your next steps.
The big open question is, if you need to be good at both to be an effective tech lead, where do you start? In my mind the answer is the title of this post - technical confidence first. We’ll dive into more detail in a moment, but at a high level I say this because in my experience - once you become a tech lead for the first time you’ll have significantly more chances to upskill in leadership than in your technical competence. This is because you’ve likely not been in this kind of leadership role before, so everything will be new and hence a learning opportunity. Leadership is the responsibility you’re adding, relatively speaking your technical work is simply evolving*, and yes, you’ll do less of it - especially in the beginning (it’s not the moment you unlock that next big technical challenge, that’s much later). Similarly, each squad only has one tech lead, so everyone will be looking towards you from day one, so you’ll naturally be upskilling here first.
I’ve now used both “technical confidence” and “technical competence” as phrases. Re-read the last paragraph if you didn’t notice.The two are similar, but the nuance is important. I intentionally chose “technical confidence” as the thing you should focus on because confidence naturally implies a level of “technical competence,” because without that it would be “technical over-confidence.” This doesn’t mean being competent in all the technologies your team will be using, so also shouldn’t be the aim. Focus on both your discipline and on the foundational, principle-based things. You may be wondering how you lead outside your discipline, this is a post for another time, but you’d be surprised how well the foundational, principled stuff I just mentioned translates across. To give a sneak peak, as a backend engineer I can still have constructive conversations with an iOS engineer about one of my favorite principles - designing for extensibility over flexibility or strategies to keep PRs small. Again, all this is why the aim is not competence but confidence. Confidence is the goal and competence a tool to get there.
Now to get back to what I actually mean with technical confidence first. What I’m really saying is - be intentional about when you decide to accept the tech lead hat. You’re likely better off spending more time honing your technical skills over jumping into leadership too early. This isn’t a reason to postpone forever, you’ll never be fully ready, but this is one place I’d over index your focus. This technical expertise forms the foundation for the confidence you will fall back on when things get tough or stressful. The last thing you want is a team of people looking up to you, where you straight up don’t have the technical confidence to guide them forward.
I’m not implying you won’t have imposter syndrome or saying you need to be the most technically savvy in the room, or even that you need to make all the technical decisions. You absolutely don’t, but you need to believe in your own modal ability to solve problems and deal with ambiguity. Especially technical ambiguity. Inevitably you will have moments where you don’t feel confident and feel totally out of your depth, and that’s fine. This is exactly why you should intentionally move into this role knowing that technical confidence is something important, and worth investing in up front. By all measures, this should be a strength before you entertain becoming a tech lead.
The best way to build your confidence is time, a personal track record of solving technical problems you weren’t sure you could solve successfully. These are the things you will look back on in times of doubt to remind yourself you can do it (or others can help point them out too). Luckily amassing these examples is literally your job already.
Reading all this you might be thinking “So I have to be the most senior engineer in my team to be the tech lead?” This is categorically not the case. I refer back to my distinction between “technical confidence” and “technical competence.” You need to trust in your ability to solve technically ambiguous problems, in your technical decision making process and your foundation - not know that you’re the most experienced person in the room. True technical confidence is not relative to the people around you, it’s there irrespective of who you’re working with. Believe it or not, I’ve rarely been the most experienced engineer in a team I’ve been leading, and even if so, only by a tiny margin!
So when in doubt, invest in “tech” before the “lead,” it will pay dividends from the get go.
*Don’t confuse this with eventually building your confidence as a technical leader itself, which comes much later in the journey. Designing complex technical systems at a leader level of abstraction is a whole different technical competence out of scope for this post.
< Personal anti-patterns - If you’re not writing code… >