As software developers, “technical lead” sounds like a role we’re supposed to want. How can we decide whether we should want it? What exactly is a tech lead, and what does it take to be good at it?
What isn’t a tech lead?
We know by Schmonz’s Theorem that there necessarily exist other roles similar to, yet different from, “tech lead”. By inspection, some such similar roles appear to be:
- Senior developer
- System administrator
- Line manager
Line manager?!? Sort of. Both line managers and tech leads are better positioned to make certain types of decisions.
Sysadmin? Sort of. Sysadmins and tech leads are better positioned to understand the costs of technology decisions.
Developer? For sure. A tech lead who hasn’t been a developer faces an uphill climb to credibility, even if they somehow manage to make good decisions.
Senior developer? Depending on the context-specific meaning of the title, it could be nearly identical with my conception of a tech lead, or quite some distance away. In my experience, usually the latter.
Architect? Again, depends on the architect and the situation, but in my experience, it’s difficult for architects to do what tech leads can do.
What do tech leads do?
They help technical decisions get made.
What do good tech leads do?
They help good technical decisions get made by the team, consistently, at every level of the decision tree.
How do good tech leads do it?
Their knowledge is wide, such that given any technical problem, they know enough to guess well about potential solutions. Their knowledge is a bit deeper in the codebases they live near, so they don’t have to guess as often. And their desire to see teammates make informed decisions is wide and deep, such that they can await the delayed gratification of someone else making the “right” decision, or even tolerate the discomfort of someone making the “wrong” decision when it’s not too irreversibly wrong, if that’s what it takes for them to make a better decision next time.
What makes a great tech lead?
A great tech lead has impeccable judgment with which to make every last technical decision — and instead seeks, above all else, to share that power with teammates. A great tech lead is one who doesn’t think of themselves as “leading”, won’t be seen doing any such thing, and might appear harmless to remove from their team. Don’t go removing them! But if you do, and it turns out to be harmless, that might be because they’ve just finished doing a terrific job.
When is being “technical lead” a good decision?
When you could be an architect, but are afraid to drift from your team and your code; when you could be a senior developer, but are afraid you won’t get to share everything you’ve learned; when you could be a manager, but are afraid folks won’t get to manage themselves; when you’ve got the chops to be “technical lead”, but don’t want anyone thinking of you that way.
It’s a tough job. If you do it well, then (just like a sysadmin) you might not hear appreciation for your work until years later. Until that day comes, for what it’s worth, you’ve got mine.