Stories about Software


The Tech Lead Role: Lessons from Ancient Rome






Scenes like this play out in banal fashion across the corporate landscape with extraordinary regularity. “So this is how liberty dies… with yawns and donuts.” Mid-level managers impose mid-level edicts and small, informal, and cooperative groups are given “unofficial-official” leaders in the form of one of the most coveted corporate consolation prizes in existence: the dotted line reporting relationship. “Linda puts in a lot of hours for us and the numbers are off this year and she won’t be getting much of a COLA, so why don’t we make her a ‘team lead’ to keep her happy and help her grow?” If Linda is a programmer, she becomes “Linda the tech lead.”

Is this a good move? My gosh, it’s hard to say. It probably depends on whether Linda is stabilizing philosopher Marcus Aurelius, ineffectual fiddler Nero, or sadistic lunatic Caligula. As Marcus Aurelius she may stabilize a project that’s slightly off the rails, manage egos, resolve disputes, and get the machine humming more smoothly. As Nero, she might decide it’s time to get really, really serious about coding standards while the team mostly ignores her and gets their work done as before. As Caligula, she imposes weird rules and dress codes while demanding that no code be delivered without her inspection. The team gets fed up and quits or transfers one by one.

Whether giving this nod to Linda makes sense is mainly a function of how the team takes it because of the multiplicative effect of the scale. If Linda is an excellent programmer or an excellent leader and worth keeping, tossing her some superficial organizational power will probably help toward that end. But if Linda is Caligula and makes a team of 5 people quit then it’s clearly not worth doing since, even if she quits, it’s better than 5 people quitting (or taking up swords and revolting behind Cassius). As you work your way up the realpolitik pyramid of organizational power, people’s value becomes increasingly a function of their effect on others and the value of their individual efforts becomes vanishingly small in a hurry.

In the end, Linda’s technical contributions aren’t very important on a decent sized team, and even her “technical vision” for communicating with external stakeholders is relatively muted in terms of impact. What really matters is her value as a coefficient on the X of the team’s productivity. If she’s an inspiring mentor that makes the team better, she’s a 10X. If she’s Nero and running around concerned about documentation and coding standards, her coefficient value is 1 to signify her irrelevance. If she’s Caligula, it’s 0 or negative.

So to consider what makes a good tech lead in the general sense is a pretty tall order, since the team is is the X, and the traits of a good leader for that team will depend on the team. I think this is an evaluation that has to be done post-mortem, like tests for certain neurological diseases. (With the exception of Linda-as-Caligula, whose obvious destruction of the patient is its own calling card). If Linda is an ineffectual leader and you ship her off to another team, nothing much will change during or after her tenure. If Linda is an effective leader, the team’s output will improve during her tenure and hold steady after her departure. If Linda is an outstanding leader, the team’s output will improve under her direction and continue to improve after her departure. But, interestingly enough, if Linda is an ineffective leader but a technical hero (and bottleneck), the team will improve a bit under her direction and then take a sharp nose-dive after she leaves.

And this is why the post-mortem evaluation is essential. The team can show improvement under Linda with her being awesome, decent, or ineffective. It’s what they do after she leaves that is the most telling. But if you really want a quick, informative metric, ship her off somewhere else and see if the team continues to solicit her advice and guidance for handling new situations (this last part is important because it’s not good if they’re soliciting her guidance only because she created some convoluted build process that no one can understand). That will tell you whether your team of intelligent human beings writing software values Linda or not.

And that last part is what really matters. The developers are your Roman Republic, and if they’re getting things done effectively, they probably don’t need a Caesar or Marcus Aurelius (that they don’t need Nero and Caligula is obvious, I would hope). And, if they do need that figure, since they’re intelligent human beings, they will probably find and promote her unofficially from within. If you have a team of web developers that consists of a handful of inexperienced programmers and an accomplished deliverer of production-grade sites, you’re not going to need to codify leadership with solid or dotted lines; your Senate will self-organize. And you should let it.

Newest Most Voted
Inline Feedbacks
View all comments
Andy Bailey
Andy Bailey
5 years ago

Letting the team self-organize is a sensible practice but sometimes your teams don’t do what is right for the company, they do what is right for them and that is not always the “sensible” thing. Example: a team has been left without an effective lead for long enough that the “weeds” have prospered and are choking the “flowers” to the detriment of the project. The team has self-organized like this because there has been no authoritative direction from outside and the “weeds” are stronger than the “flowers”. Suddenly management notice that this team is not even close to being effectively… Read more »

Erik Dietrich
5 years ago
Reply to  Andy Bailey

As I was reading, I thought it sounded like a comment motivated by recent personal experience. 🙂 It may be that sometimes you have an ineffectual senate that needs an emperor, so to speak. If we’re talking about a situation you encountered, I can’t speak to specifics, but that really sounds more like some combination of HR/team-fit issues and perhaps lack of familiarity with a process than a “we need a guy to decide what framework to use or not use” (which is what I typically associate with the non-org-significant role of “tech lead” — my experience is that this… Read more »