This is part of a short series on being a tech
lead, and about some of the tensions inherent in the role.
In the introductory post, I wrote that:
…the tech lead role is one which frequently involves tensions between
different ways of working: writing code vs. not writing code, making all the
decisions vs. making none of the decisions, and so on. In the posts that
follow this one, I’ll examine some of these and try and explain why I think
good tech leads spend a lot of their time somewhere in between the two
extremes, adjusting the balance as circumstances demand.
The two extremes, in this case, are:
Keep your hands dirty: spend all of your time working directly alongside
your team with the code.
vs.
White gloves: never write or review code. Focus instead on higher-level
design, architecture issues, or business-facing work.
A lead who spends all of their time working just like their team is not
performing a meaningfully distinct role. In a team of very experienced engineers
this may not be a problem: they may all be capable of holding the long-term
business and technical goals in their heads even as they work on details. Or
perhaps they are mature enough that they can effectively divide their time
between these activities. This is rare.
Even in very experienced teams, having a designated lead (perhaps as a rotating
role) can help reduce the coordination costs needed to get several people’s
input on architectural and design questions.
If you are more experienced than your team, your goal should usually be to share
that experience by guiding and supporting your team rather than using your
experience directly in execution. It will be tempting to take the more
challenging work for yourself: you’ll do a better job, faster. But if you never
let the team learn how to handle this more challenging work, then they will
never develop the skills they need to do it without you. This will create
difficult problems for you as the business grows and you are inevitably unable
to take on every challenge yourself.
The other extreme – a lead who takes an “ivory tower architect” approach – can
erode trust within the team. While as a lead you will not and should not make
every decision (see the next post in this series), you will need to make some.
The confidence your team has in those decisions depends on the respect they have
for you and your decision-making abilities. It is more difficult for the team to
believe that you have made a good decision if they don’t see you facing the same
problems that they do on a day-to-day basis.
Perception is as important as reality here. Perhaps you don’t need to be
immersed in the gritty details of the code to make good decisions. It is likely,
however, that at least some of your team feel that you do. If those people see
you acting as facilitator and arbiter without a first-hand understanding of
their experience, they will conclude that your decisions are arbitrary.
If you have feedback on this post, please contact me on
Twitter.