Tech lead: decide everything ⟷ decide nothing

This is part of a short series on being a tech lead, and about some of the tensions inherent in the role.

Continuing the theme of the last post (about writing code or not writing code), this one is about another tension inherent in the tech lead role.

This time, the two extreme behaviours are:

Tyranny: involve yourself in every major technical decision, and many minor ones. Nothing significant ever changes without your input. You expect to review everyone’s code.


Tyranny of structurelessness: you believe that the best team is one that is empowered to make its own decisions. You don’t intervene even in times of stagnation or conflict, because you think your smart, capable team will be able to work their way to a resolution.

I suspect most people will have experience of at least one of these extremes, usually as an individual contributor living in one or other form of tyranny. As a lead, however, finding a balance can be hard: both ends of the spectrum are traps that are easy to fall into for entirely understandable reasons.

A tyrant or micromanager is often attempting to manage risk, whether by preventing their team from making mistakes, or by seeking total visibility into the team’s work so that they can intervene if needed. This cannot possibly continue to function as the team grows: there will come a time when you simply cannot keep on top of everything. When that time comes, you will find yourself leading a team which must now make its own decisions, but which has precisely no experience of doing so. More importantly, the team will probably be uncertain and fearful of the consequences of making a mistake. Until now the burden of preventing mistakes has fallen solely on your shoulders.

Slightly more enlightened tech leads may know that micromanagement is the road to hell, and so seek an entirely consensus-based approach to decision-making in the team. With an experienced team that has high levels of trust and psychological safety this may be close to achievable, but even in these teams there will be some decisions on which the team cannot come to agreement. In these circumstances it will be your job to understand the disagreements, perhaps correct some miscommunications about context (maybe one team member is objecting to a “short-term fix” without understanding that it is part of a longer-term strategy to address a bigger problem), and ensure that, where appropriate, decisions are being based on available data. Occasionally, you may need to be a casting vote.

Failure to exercise this responsibility to facilitate and, if needed, make decisions that are holding up the team will result in these decisions being made by the people on your team who shout loudest, or have the highest tolerance for disagreement. These are not qualities that correlate with competence.

If you have feedback on this post, please contact me on Twitter.