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.
vs.
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.