Corporate Realpolitik Explained: The Tech Lead
I think I’m going to start a new series of posts, with this as the first. Leading up to and in my book, I talked a lot about organizational politics. But I haven’t done that as much since. I’d like to start in on that a little again, and I’ll start with the tech lead role.
Why tech lead? Dunno, why not?
So what will I talk about? What’s the aim here? Well, in this post and in any future ones in the series, I want to dive into the organizational underpinnings of roles in the tech world. This isn’t the superficial stuff you’ll see on a job description, but rather the realpolitik take.
- Why does this role (really) exist?
- Should you even want it?
- How does it set you up to succeed? To fail?
That type of thing.
Tech Lead: The Surface Story
First things first. Let’s cover the superficial briefly so that we can get beyond it. If you go out and google “tech lead role” you’ll find stuff like this.
- The tech lead has the ultimate say on technical matters for the team.
- Part of the role involves delegating tasks to other team members as well as mentoring them.
- You’ll obviously need strong technical skills, but also good people skills because it’s not necessarily the strongest tech people that make the best tech leads.
- You also need to be able to communicate effectively with the business.
Got it yet? I’ll assume you’ve never heard me speak. If that’s the case, and you put a voice to what you just read, does that voice sound like the soothing, dulcet tones of someone from HR? It should.
Of course, maybe you want to go the slightly more controversial and philosophical route. Should the tech lead role even exist? Especially on agile teams, don’t we learn that teams are self organizing? Doesn’t Scrum call for only three roles, none of which is tech lead?
Surely we should furrow our brows and discuss this meaningfully. On the one hand, having a communication point-person and decision maker is important. But on the other hand, we’re knowledge workers that respond well to a more democratized approach. So you and your organization should have an earnest and sober conversation weighing all of the pros and cons.
Of course, nobody in a decision making position will listen to this earnest conversation, because there are undercurrents in play well beyond settling arcane technical disputes out in open office plan land.
A Recap of the Corporate Hierarchy
As briefly as possible, I’m going to recap some ground I’ve covered in my book and on this blog in the past. I once defined the corporate hierarchy in detail as having three principle rungs, characterized by what they sacrifice to the organization.
- Pragmatists (line level people) exist at the bottom and cede hope for advancement in order to have work life balance and other interests.
- Idealists (middle management) cede perspective, dramatically over-performing and over-working in exchange for limited career long returns.
- Opportunists cede ethical certainty, recognizing that advancing requires cheating in the context of the rules by which idealists and pragmatists play. (These folks are power brokers and possibly the most interesting, but I’ll talk about them very little today)
This describes the general work force pretty well. But we programmers with our love of stack ranking and gamification have managed to insert a layer between pragmatists and idealists that I call journeyman idealists.
Regular idealists generally land in roles where they have direct reports. Most people enter the workforce as de facto idealists until one form or another of disillusionment pushes them into another bucket. So people enter the company really, truly believing in the company and they over-perform their way into middle management.
Journeyman idealists follow this same model, but they top out lower, never actually acquiring direct reports. They also don’t believe in the corporation as a steward of their careers. Instead, they believe in the illusion of an overarching programmer meritocracy.
Tech Lead as Journeyman Idealist
So let’s start by placing the tech lead on the map. Tech leads are usually journeyman idealists, as you might expect.
The world of software development encourages us to job hop (so do I, by the way). This and the intense demand for our labor causes us to believe more in the general programming industry and craft than in any individual company. Our path to technical advancement then takes us on a journey of joining a team, honing our skills, and eventually becoming king of the hill — best techie on the team.
Doing this often requires some shuffling because when you enter the team as the least skilled, it takes some serious doing to leapfrog people (we think, anyway). So you probably have to make some jumps, bank on some promotions and retirements, and generally pay your dues. But then, sooner or later, at some company or another, you earn they keys to the kingdom.
You are the tech lead.
And, while you have zero direct reports, you sit in the same cubicles as the other developers, you don’t usually get paid any more, and you don’t really even have any discernible, tangible perks, you are the tech lead, damnit. You get to administer whiteboard interviews and decide which ORM to use.
This may be starting to piss you off a little if you’re a tech lead, and that’s fair. I’m also not quite done, but it’ll get better, I promise.
The Opportunities that This Gives You
If this sounds like a sucker’s play that’s because it really kind of is. If you’re taking on more responsibility with nothing to show for it beyond a vanity title, you’re being played for a sucker. But you’re also not alone. The pyramid shaped organization makes such a terrible vessel for knowledge work because it plays everyone who plays by its rules for suckers.
But you can avoid playing by its rules and claiming opportunity for yourself.
First, you have to recognize tech lead for what it is — an opportunity that doesn’t really have all that much to do with merit. I know, you hate me, and it hurts. But breathe. I’m not saying you’re not good at what you do. Instead I’m saying that becoming top dog often has more to do with hanging around and waiting your turn than your knowledge of libraries and sorting algorithms. That’s why expert beginners exist in spades in our line of work.
I’m also not saying that you can’t seize it as an opportunity. Being the best generalist developer earns you what they pay you for it — nothing. But getting a role with “lead” in the title sets you up to interview later for management and other roles with actual organization meaning.
It does also give you nominally more lateral mobility as well. It’s easier to exist at the upper bound of developer pay brackets with a “tech lead” title at a past company, making future salary negotiations easier. But you’re already topping out the pay of an individual contributor, so without a jump to management, you’re approaching the end of the line that is your career.
Why Companies Like This Role
So the main benefit for you of this role is to grease the skids for favorable lateral transitions and to act as a stepping stone into management. Slim pickings, but then again, blasting your way through two layers of idealists to get to the top with the opportunists isn’t for the faint of heart. (In my book, I talk about strategies for just stepping around the idealists altogether.)
So if there’s not a ton value in the role for individuals, why do you see it in companies? Why do companies (opportunists and idealists inside of those companies, really) like it?
At the risk of over-simplifying, here are a few reasons.
- Idealists like having more people and layers below them in the pyramid, and this creates an artificial, “dotted-line” layer.
- Managing idealists are also not keen on wading into (or hearing about) squabbles over technical minutiae. So picking (quasi-randomly/based on seniority) a person and putting that person in charge is expedient. Think of parents going on a date and putting the oldest child in charge.
- Opportunists with budgets recognize the organizational advantage of being able to “pay” technical folks with a vanity title in lieu of money or tangible benefits.
In the broadest terms, creating software engineer I – VI as well as senior, principal, and fellow engineer manufactures a very vertical organization. You can double down on that with things like architect and tech lead. The more of this the company does, the cheaper its collective labor force. Developers argue with each other about who should be tech lead or whatever instead of with management about how they should all make more money.
What’s the Verdict? Do I Want to be Tech Lead?
Pulling back to the surface level from the depressing depths of the corporate pathology, should you do this role? Should you want it? Well, it’s better than nothing.
Being a “good” tech lead means occupying the role without mutinies and without impeding the team progress much. Ideally speaking, someone in this role develops the other team members professionally and makes everyone collectively more productive. They make the team significantly more productive.
But here’s the rub.
A good team member and professional does that anyway. The things that make a person a “good” tech lead on the surface are the same things that make people good team members. The lone exception is the role artifice itself, like task delegation. To think of this another way, ask yourself this question. If the role were truly about team uplift (instead of non-monetary compensation through vanity titles), why wouldn’t the role be team-voted instead of idealist manager appointed?
So should you take this role? Absolutely. Should you use it to try to help people improve? Again, absolutely. But don’t kid yourself about what it is. It’s a tiny bit of leverage that a savvy aspiring opportunist can turn into meaningful leverage. It’s a stepping stone to other things and not a calling.
And, by the way…
If you like the wisdom here, such as it is, you can get a whole lot of that more in my recently released book, Developer Hegemony. If you want a sample of that, you can sign up to download some chapters below.
Want more content like this?
Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)