This post is a transposition of my Fluent talk Becoming a team lead: a survival guide. It’s been edited to better fit a blog post format. If you prefer to see the original format, you can watch the video (30 minutes + Q&A) or view the slides with speaker notes.

A survival guide is a strange thing to call this post, since survival guides are usually very serious books that prepare you for extreme situations. Building shelter in the wilderness, foraging for food, avoiding being eaten by bears - that sort of thing. I’m never sure when is the right time to read a survival guide, since being lost in the wilderness or being hunted by bears is not something you really plan for. If you read the survival guide too early, you forget most of it. If you read it too late, it’s no use.

Anyway, the reason this is a survival guide is because after spending my entire career as a software engineer, I was thrown into a team lead role without much warning. I had no idea what I was doing and had very little support. This is the survival guide I wish I had. It documents my experiences as an inexperienced team lead –as an engineer transitioning to a team lead– and my learnings & mistakes along the way. Hopefully this can act as a survival guide for you, too.

This is a fairly long guide, so I’ve split it into sections. Feel free to skip sections that aren’t relevant to you.

Introduction: the accidental leader

In 2014 I was lucky enough to be offered a job at the BBC in London. The team I ended up working on was made up of 10 people, 7 of whom were software engineers. We had a fantastic team lead (Hi, Pete!) who kept things running smoothly and –more importantly– kept the team happy. I learned a lot from Pete.

Then, disaster struck. Within the space of only a few months, most of the team leads in our department left. Including Pete. Up until this point, I had naïvely been trying to climb the career ladder and attain more power for myself within the department. So I had essentially already been digging my own grave (okay, I’m being a little dramatic here) and it only made sense that our head of engineering pushed me into it by asking if I would temporarily fill a team lead role.

Despite my desire for more decision-making power, I was apprehensive about taking a team lead role. I liked writing code, I didn’t like responsibility, and I really didn’t want to become a manager. I was assured, however, that my day-to-day work would hardly change, and that I wouldn’t have to do any management.

Looking back on this moment, I feel a bit stupid. Of course I took the role. It sounded perfect: all the power of a team lead with none of the responsibility. It was exactly what I wanted. If only I knew back then that things would not pan out like that at all. In hindsight I would say that the first few months of my new role as team lead were some of the most stressful and challenging months of my career.

This is really common.

Having spoken to many other team leads since then, I’m amazed at just how common this scenario is. Almost all of the team leads that I’ve met in software development sort of “accidentally” fell into their leadership roles despite having no prior experience, and almost all of them found it difficult to get any support after taking the role – regardless of whether they worked for a small startup or a multinational organisation. It seemed like in contrast to their previous career progression, becoming a team lead was vastly more difficult and overwhelming.

I think that in general the team lead role is misunderstood, and it is also oversold. Our industry is really good at pretending that software delivery is all about writing code, but in all of my experiences this is never the case. Some of the hardest problems in software are either people problems, organisational problems, or cultural problems. Yet we continue to push technically brilliant software engineers into leadership roles, with no training in communication or management, and we wonder why they struggle to deliver or why they burn out.

Part I: Before you apply

Understanding the team lead role

The best way to avoid becoming an overwhelmed, burnt-out team lead is to not become a team lead. No, seriously. It’s important to be able to recognise when you’re not ready for a team lead role, or when to say no if you find yourself being pushed into one.

There are a lot of myths about leadership, and one of the biggest is that you gain power simply by becoming a leader. I thought this. A lot of people think this. My reasons for wanting to become a team lead were along the lines of:

I learned pretty quickly that my reasons were all wrong. If you find yourself agreeing with any of them, then I seriously urge you to delay taking on a team lead role because it might not live up to your expectations.

But if those are the wrong reasons to become a team lead, then what are the right reasons? I would sum them up like this:

The good news is that if that sounds like you, then you might find that a team lead role suits you well!

Setting yourself up for the role

Assuming you do want to become a team lead, how do you set yourself up for the role so that you’re prepared well in advance?

You likely already work in a contributor role, which will mean doing this preparation in your own time. If you’re lucky enough, you might be able to prepare in your company’s time. Either way, this time will be a good investment because it will help you to hit the ground running and become a more effective team lead.

Do some research

You’ll save yourself many headaches by researching the team lead role in advance. Learn what to expect from the role, and what skills you need to sharpen. The fact that you’re reading this is a great start (there’s a further reading section at the end of this post too). I would recommend investing time in improving your communication skills and learning about different leadership techniques.

I also recommend learning how to identify and deal with mental health issues because they are extremely prevalent in our industry. Being able to identify issues early on in yourself and the people around you can make a huge difference in preventing burnout.

Fix things that cause pain for the team

The aim of this is simple: get used to the idea of being someone who removes roadblocks for the team rather than being a core contributor. Start by volunteering to attend boring meetings, or optimise people’s workflow by making the build faster. Removing pain from the rest of your team will keep them happier and allow them to work with fewer interruptions. I like to think of this part of the role as being a sort of team janitor.

Take every opportunity to mentor

Mentorship is a great way to transfer knowledge and grow your team. It also helps to reduce the team’s reliance on you. You should pair program with junior team members to help them get through their workload, and regularly invite other people to sit with you whenever you are working through a problem.

Being a good mentor is something that I believe really only comes with experience. Getting the experience early on will make you a much better mentor when you move into a lead role.

Focus on the bigger picture

You’ll likely be at least partly responsible for delivery as a team lead. It’s good practice to zoom out and think about the optimal way to get to the end of the project. In particular, think about how to avoid roadblocks in your upcoming work. Sometimes it’s better to have one person work on something totally unrelated to your current sprint so that the rest of the team can work unimpeded in the next sprint.

Be present

Software folk are very good at putting their headphones on and living in their own little bubbles. This reinforces the idea that software development is some sort of mythical or sacred practice that should never be interrupted, and it makes people second guess whether they should ask for help. This isn’t what you want in a team. You want people to be comfortable asking for help – that can be the difference between a successful & productive team who ask for help as soon as they’re stuck, and an unproductive team who struggle with their work in silence.

Part II: You got the job!

So, you’re a new team lead - congratulations! The following sections are your handbook to being an effective team lead in your daily work.

Avoid being overwhelmed

Being a team lead can be overwhelming at times, especially during the first few months while you’re still getting a grasp of everything. If you feel yourself becoming overwhelmed at any point, don’t ignore it. Humans are quite good at picking up on each other’s emotions, and as the team lead you are likely to pass your own stress on to the rest of the team.

Stop writing code

My number one tip for dealing with being overwhelmed is to stop writing code. It’s strange for me to suggest this because for me, coding is quite cathartic - it’s a form of stress relief. But coding takes a lot of your time, and it puts you in a mindset that makes you unavailable to the rest of the team.

If you’re working on something important, see if you can pass it onto a team member. Otherwise just put it to one side for a few days.

Learn to delegate

Learning how to delegate can be difficult, especially for team leads who are transitioning from a full-time contributor role. Often the problem is that the team lead is still considered to be (or considers themselves to be) the de facto owner of certain parts of a codebase. Explicitly passing this ownership on to somebody else can help make it easier to ask other people to work on that code.

Delegation is easier said than done, but doing it correctly can be an extremely effective way of reducing your stress levels. Pick a member of the team you know is capable, make sure they have low stress levels, and (politely!) ask them to complete a task for you.

Say no

This is a personal favourite of mine, and it made a few of my senior stakeholders very unhappy at times. Saying “no” when you or your team is asked to take on more work is a totally valid way of dealing with being overwhelmed. Of course there are more polite ways to say “no”, like “can you ask me again next week” or “is there anybody else available to do that”. However you say it, it’s always better to say no than to disappoint someone by being too busy to fulfil their request.

Saying no has this other benefit which is that it signals to your boss or stakeholders that you or your team have too much to do.

The best case scenario for saying “no” is that your team is given some extra help to deal with the workload. The worst case scenario is that you’re told to do the work anyway, in which case…

Ask for help

We’re not very good at this in the software development industry. It’s as if there’s a bizarre sense of achievement or credibility in struggling through a problem for days when it could have been trivially solved by someone else in minutes. “Help” can come in many forms: someone helping you get through your work, mentorship from your boss or another team lead, or just someone to talk to over lunch. Whatever form it comes in, don’t be afraid to put your hand up and ask for help when you’re feeling the pressure. You’ll thank yourself later.

Similarly to saying “no”, asking for help sends a clear signal upwards that your team isn’t coping. This doesn’t indicate any failure on your part! If anything, it indicates a failure with your stakeholders or upper management – they’re not managing their people (“resources”) well enough.

Conducting effective one-on-one meetings

It feels strange to have a section in this guide about meetings. If you’ve ever had the (dis)pleasure of working with me, then you might know that I’m not very fond of meetings. I think I wrote too many meetings :( on a post-it note in pretty much every team retrospective I attended.

Unfortunately, this dislike of meetings carried over when I became a team lead. And since I spent the first few months of the role just panicking and stressing about my workload, I had the genius idea of saving time by avoiding one-on-one meetings. I assumed that if anyone needed anything, they would just approach me.

This was a really big mistake. One-on-one meetings are one of the best ways to keep in touch with your team because they offer a private & safe space in which to have open & honest conversations that you would not normally have in front of the rest of the team. They might feel awkward at first, but eventually these meetings should feel as natural and casual as a daily stand-up.

Have them regularly

The first piece of advice I have around one-on-one meetings is to have them, and have them regularly. I only mention this because I know from experience how easy it is to avoid them. It doesn’t matter how tight your deadlines are, or how much fun your current workload is, meeting with your team should be at the top of your priority list.

Having them every 2 weeks is a good place to start. If 2 weeks feels too regular, you can slowly increase the time between meetings until they feel just right. Remember to set up recurring calendar events and treat them like you would any other important meeting. Never skip them!

Use a template

I found it really useful to have a template for my one-on-one meetings. I took Lara Hogan’s Questions for our first 1:1 template and modified it to suit my team.

A template gives your meeting some structure and ensures that you don’t miss out anything important. You can stray from the template and adjust it as you go along - it’s just there as a guide.

Take notes

Take notes of everything that’s discussed, because you’ll want to refer to them later. Get the consent of the person that you’re meeting with first, and reassure them that the notes are completely confidential, and only used for your own reference. I usually start every meeting by showing the other person my notes from last time, to make sure we’re on the same page.

Prepare beforehand

Give yourself 10 minutes before each of your one-on-ones to prepare yourself. Think about what you want to say. Remind yourself what each person has been working on recently. Go over your notes from the last meeting and make sure you’ve done everything you said you would. If you haven’t, well, you’ve got 10 minutes to think of some good excuses.

Ask and listen

Probably the most important bit of advice regarding one-on-one meetings is to remember that your role in these meetings is to listen. After you ask a question, just sit back and listen. Long stretches of silence are okay - they give you both a chance to think.

Don’t just listen, either. Really take in what the other person is saying – regardless of how important you think the matter is, or whether you agree or not. This person is telling you something because they think it’s important, and it’s your job to take everything they say very seriously.

Don’t over-promise

Remember how I said that you should do everything that you said you would in the last meeting? It helps if you don’t put yourself in an awkward position in the first place by promising things that you can’t deliver. It’s fine to promise that you’ll order a new keyboard, or that you’ll raise an issue to your manager’s attention. But don’t ever promise things like promotions or pay rises. Over-promising will only lead to disappointment and dissatisfaction.

Dealing with pressure from stakeholders

Let’s talk about stakeholders. No matter the size of your company, you probably have at least a few. They’re the people who are interested in the outcome of your project, and they probably set the overall direction of your work by coming up with the project requirements and various tweaks along the way.

At some point you will find yourself in a position where your stakeholders are asking your team to do too much, and with too little time. How you handle these situations can have a tremendous impact on the happiness and productivity of your team, so approach them with caution.

Always be honest

Always be honest about how your project is going. Especially if you’re behind schedule. In business-speak, this is called “managing expectations”, and it’s vital that you and your stakeholders have the same expectations.

… Unless you’re ahead of schedule

There is one exception to the “always be honest” rule, which is that you should not tell anyone that you’re ahead of schedule. The only time you’re really ahead of schedule is when you finish the entire project early. Until that point, you’re just one unexpected delay away from being behind schedule.

Compromise early & often

Since you’re going to be telling your stakeholders when you’re behind schedule, it’s useful to learn how to compromise. Compromising can be an awkward and painful process where you basically ask your stakeholders to either cut back features or give you more time. You should try to compromise as soon as you know the deadline is tight, and you should do it as often as you need to. Compromise until the deadline feels truly achievable. Just remember that there is no “us vs. them” – everybody wants the same outcome, which is a high quality product delivered in a timely manner.

Don’t pass the pressure onto your team

There will be times where you truly are behind schedule and there are no compromises to be made. During these times, a good team lead will shield their team from any pressure, and generally protect them from the harsh realities of the world. When the pressure is on, the last thing you want to do is stress the team out. Even teams that work well under pressure will eventually burn out and become unproductive.

Ask for help

A common theme in this guide is to ask for help. A strategy I’ve used successfully in the past when I’ve been really close to a deadline is to borrow some time from another team. Then I can return the favour when that team needs help in the future. This is effective because having somebody else work on little things like bug fixes can really take the pressure off everybody else while they focus on finishing major features.

Grow & support your team

I said before that a core part of the team lead role is growing the people on your team. I think it’s actually the most important part. I’ve heard people say that delivering value to the business is the most important part of your role. I disagree with this. To be fair, growing your team and delivering value are two things that go hand-in-hand. You’ll find that as people grow, they learn new skills, and they become happier & more productive. The more skilled your teams are, the more value they end up delivering (and the more they should be paid).

People grow in different ways, and part of your role is to identify how everyone on your team grows best. Some people like to be mentored, and told what to do. Some like to be given reading material or tutorials to follow. One thing that is common to most people I’ve worked with is that they grow when they’re challenged.

Allow pet projects

Sometimes your team’s day-to-day work isn’t challenging enough to stimulate growth. This is why I’m quite fond of pet projects. You don’t have to set aside dedicated time for pet projects, like Google’s now-defunct 20% time. Instead you can allocate time for pet projects when they’re most appropriate. For example, someone on your team wants to learn about React. Wait until you have some downtime, and then ask them to spend a day or two building a simple clone of something they worked on recently using React. Afterwards, have them report back to you (and the team, if they’re comfortable with that) on the pros and cons.

Encourage pairing

For the times when the day-to-day work is challenging enough, you want to make sure that everyone on the team is actually progressing with their work enough to really learn and grow from it. I was given a tip to help with this:

Nobody is allowed to work on a task by themselves for more than one day.

I think this is a fantastic tip. It ensures that people spend less time being stuck on simple problems, and more time progressing with their work in a way that challenges them and allows them to grow. It also works really well for tasks that you know will take longer than a day, because you end up with more than one person having knowledge about these complex tasks. This reduces your reliance on your more senior team members who would normally take on these complex tasks by themselves.

Run knowledge sharing sessions

Getting together on a regular basis to talk about things you’ve all learned recently can be a good way to keep everybody up-to-date on the whole project. You can even use these sessions as a way to talk about non-work things, like what you’re all planning to do over the weekend. This “not-work” sharing might not be appropriate for every team, but I think it’s a nice way to make the meetings less formal and get everyone to know each other as people.

These sessions are also the perfect opportunity to invite other teams along to encourage cross-pollination of ideas.

Spend time together

I’m not a particularly social person. I used to be the person who would skip team lunches because I’d rather eat by myself. Everybody relaxes and has fun in different ways, which is why it’s so important to enable the team to spend time together in a variety of settings. Have lunch together in a restaurant, or in the office, or in a park. Go to meetups or conferences together. Start a book club. Use techniques like swarming –where you all work together on the same task– to bring everyone together.

Swarming is a particular favourite of mine. Firstly because it’s a great way to trick people into spending time together (they all think they’re doing work but in fact they’re bonding and being social – ha, punk’d!) and also because it’s just a genuinely good way of getting work done. I’ve found that swarming works particularly well for tasks that are big but easy & monotonous – things like testing a single feature on many configurations, or writing documentation.

Remember: you are a team!

Every team is different. As the team lead, your job is to celebrate everyone’s differences and make every effort to ensure that each person on the team has an equal opportunity to grow and achieve their goals. I promise you that focussing on the growth and happiness of your team will not only make you a better team lead, it will make your team happier and proud to work together. It will make your team more productive and more successful. If you’re lucky, it will even inspire members of your team to become great teams leads in the future – just like you.

Further reading

Here are some other resources to help you become a better team lead.