Notes to a new tech lead

This is a handful of short notes about leadership philosophy aimed at my younger self. I spent a couple of years leading an applied machine learning research team, after having been a member of the same team. In the course of a career, that’s not such a long time, and — like everyone else — I gained my experience in a particular context. My views may not generalise to other people, or even to myself in other contexts. If you’re new to leadership (perhaps a tech lead, manager, Staff or Principal engineer), I hope they’ll be of some use to you.

1. Tech lead as interface
2. Tech lead as empath
3. Tech lead as spirit leader
4. Tech lead as lore keeper
5. Tech lead as broken record
6. Tech lead as super fan
7. Tech lead as martyr

Interface

Becoming a lead creates a distance between you and the team you are leading. It does not put you at the centre of the team. It puts you at the interface of the team with the rest of the organisation.

In becoming a lead, you will spend less time with the team, and more time representing the team outwards. As more of your time is spent with the wider organisation, your concerns will change to match, and you’ll find yourself also representing the organisation inwards, to your team.

You will no longer be living through the same experience as your team, and you will no longer have the same priorities. It will still be your home, but you will be othered from it. It can be an isolating experience.

Empath

When you lead a team, you take some responsibility for their experience of work. This is humbling. It gives you the power to improve that experience, but it can also leave you feeling responsible for all aspects of work, even those that are not in your control.

When everyone is happy, you are happy. When anyone is unhappy, you are unhappy.

Large organisations can be indiscriminate. One cannot write an email that addresses the concerns and contexts of thousands of folks. To lead a team is to assume some duty of care over how your team’s interactions with “the org” go. A lead can act as the buffer between organisational bumps and the individuals in the team.

It’s hard to control these feelings, even when they help no-one. Sometimes you must allow folks to be unhappy about something, and sometimes you yourself will have to do something that makes people unhappy. Becoming a lead may necessitate some emotional growth.

Spirit leader

I categorise much of the responsibility of leadership as “spirit” work. I can’t write down a list of specific tasks (definitionally!), but spirit work encompasses recognising elephants in the room, initiating necessary — sometimes difficult — conversations, and tending to morale. This is distinct from operational duties, like preparing program updates, running meetings, and being the point of contact when a service goes down, or whatever.

Spirit work can be largely invisible. Its absence will not register as an uncompleted item on a Kanban board. There will not be a JIRA ticket to talk about the circumstances surrounding a team member’s departure, or to celebrate a release. Failing at spirit work is more likely to manifest as interpersonal problems, disengagement, and folks leaving (though see It’s ok for people to leave).

Perhaps another way of looking at this is: it’s the work nobody tells you to do.

Lore keeper

One thing I did as a tech lead is act as informal lore keeper for the team. Examples of lore:

• what we’ve tried (and the result)
• people who used to work here
• who we spoke to about subject X
• what organisation Y think of us

This is certainly valuable, in a gluey sense (see Being Glue): it glues some things together, it greases other wheels, it is a mental map that prevents us wandering in circles.

I don’t really know of a good means of preservation for the knowledge, a physical map. This stuff lived in my head, and in the collective wisdom and oral history of the team. The answer isn’t “meeting notes” or “Notion” or whatever tool du jour. Those are things that might facilitate some parts of lore keeping, but they aren’t the thing itself.

Certainly, keep a written record of, say, experiments you’ve tried, and former employees, and whatever else — we should all be writing more things down — but I’m unconvinced of the value of trying to store all institutional knowledge. You will inevitably fail, and there will still be lore in people’s heads. Maybe better to accept that.

Broken record

You will have to repeat yourself. A lot. If you have an important thing to make known, say it in email, on Slack, in several meetings, and write it in the meeting notes.

This isn’t because your team are stupid or inattentive, but because all communication is lossy. Knowledge workers have many demands on their time and attention, and yeah, sometimes they’re a little checked out in video calls. It’s very likely you aren’t doing a perfect job of communicating exactly how important something is, especially relative to all the other important things. Also, you aren’t infallible. Your team have to balance how important you say something is with their own judgement. Repeating things is a signal that you really mean them.

So, say the really important things many times, else not everyone will know that they are important and true.

Super fan

You should be your team’s biggest fan. You’ll need to be, because there’ll be times when someone else loudly isn’t, or, worse, when they themselves aren’t.

You can’t really give someone else a sense of meaning in their work. You can make the importance of the work clear, and place it the context of the organisation, industry, or world at large, but you can’t change whether someone finds that meaningful. Your job here is to be honest and forthright. If someone fundamentally does not find their work satisfying, help them to new work they do find meaningful, which might mean leaving the organisation.

If you need to correct some behaviour or attitude of an individual, or even a whole team, you should do this from the perspective of a fan. It is not cool for a lead to not like their team, their team’s work, or how their team operates. Such a lead is doing a bad job, because all three of those things are at least partly under the control of the anyone being called “lead”. If they are not, the lead is insufficiently empowered. That might be changeable, but if it isn’t, seek to be a lead elsewhere.

Martyr

In peacetime, be a servant leader. Your job is to articulate priorities and expectations clearly, and provide your team with the things they need to succeed.

Be wary of allowing yourself to slip from servant to martyr. In this context, martyrdom means sacrificing one’s own preferences, perhaps declining opportunities, in favour of promoting “team stuff”. It’s a balance. A tech lead could use their increased organisational exposure to promote themselves in preference to their team. An excessive awareness of the privilege of this exposure might lead you to lean too far towards self-sacrifice. You are a person too.

You might refer to this as putting on your own oxygen mask first. In plainer terms: definitely don’t hoard the fun work for yourself, but don’t be afraid to do some fun work.

---

If you’ve encountered these notes while agonising (as I did) over a decision about whether to take a tech lead role, then know that none of the above are a reason not to do so. However, it is important that you recognise that your role will change, not merely escalate. It is a different job.