I have learned a ton about leading a team of software engineers over the last year. I kind of slipped into this role, half by accident, half intentionally. Here are some of my learnings in the hopes that they serve you when you are in a similar situation.

  1. Get advice. Listen to other leads, read books, read blogs. Don’t take it as gospel, but there are tons of good ideas out there. Just because an idea doesn’t apply right now does not mean that you won’t come back to it in the future. This also applies to this list: Your mileage may vary and your problems will certainly be different from mine, so don’t expect to use the same solutions. Keep them as inspiration.

  2. You need peers. Your role as a team lead is significantly different from that of an individual contributor. You all of a sudden do not have any peers any more. Get a peer group. Meet with them regularly. Do not discuss product questions but focus on the actual role of leading a team. In my case, I was lucky enough that this infrastructure already existed and I could simply hook into it. A format that has worked incredibly well (for me at least) is this: Team leads from all over the organization meet in groups of 4-5 every two weeks. Everyone brings a problem to the table (“How do I properly assess whether someone should get a raise?” or “How do I support someone with a chronic illness?” or whatever wild problem you have hit). Everyone else gives input on the problem, then you move on to the next person.

  3. Talk to your peers! Besides your team, your team lead peers will be utterly important in helping you sort through the jungle of unexpected problems you will encounter. Get to know your peers and build trust. For me it was very enlightening to learn why other people are team leads, for example. Spoiler: the answer nobody else was running the team is surprisingly common. I also found that investing some time to build relationships with team leads that do something entirely different from what you are working on is a worthwhile investment: They will give you new ideas, new impulses, and they generally do not succumb to the trap of just talking about whatever product you are building instead of talking about the larger problem of leading a team.

  4. Communicate expectations. When you lead a team, you will have to make tough decisions. Who gets a raise? Does this person need performance management? Are they doing a good job? No matter what you think about it, in a large organization you are going to be in a position where you have control. This is scary. You will naturally have biases. The best thing you can do is to write down explicitly what your expectations are for the people in your team. Hand them to your team. I found that in some cultures this might be considered weird, but really: You are going to have expectations and judge people anyway. You can either be fair and tell people what those expectations are, confronting your own biases on the way, or you can keep it to yourself and let them stumble around in the dark. Why you would do the latter is an absolute mystery to me. And yes, your company might already have expectations but I can assure you that they are incomplete because you are not the company.

  5. Your relationships will change. If like me you have worked with the people in your team before you take over a lead role, you have to realize that your relationships to those people will change. Of course a relationship where I get to decide whether you stay with the company or get a raise or can work from home is different. Of course it is different now that you are responsible for their professional development, their career, their well-being at work. Acknowledge that. This does not mean you cannot be friends with them, but certain things like making unpopular decisions will be more difficult. Your 1:1s with the people in the team will likely also change because (besides the casual chatting you are used to) you need to realize that you are now shaping their lives in major ways, so you better know what is going on with them, how they feel, what they care about, where they want to go, what they struggle with.

  6. You do not write your team’s ToDo list. It is not your job to tell the engineers on your team what they have to do (unless they are very junior). The people in your team are (hopefully) functioning adults. Engineers get paid to solve problems and if you hand them a ToDo list you are wasting your time and their skills. Give them a problem to solve instead. Align on the constraints on the problem, be part of the conversation, but do not solve the problem for them. If you find yourself constantly chasing someone to get them to do their job, the solution is not to write their ToDo list: It simply means that they are not doing a good job. The right solution is supporting them and helping them get better at solving problems themselves, and if that doesn’t help after prolonged periods of time you should question whether they are a good developer.

  7. This is not a democracy. As a team lead, you are responsible for the deliveries of your team. Ultimately, that means that you need to make the decisions on many questions, because you will be taking the responsibility. Listen to the people on your team, hear their concerns. Consult them, because they will likely understand the subject matter better than you do (they will simply spend more time with it than you ever could). Ultimately however you were made the team lead with the mandate to bring your expertise to the table. People trust you to make the right call. Ideally you get your entire team rallied behind you, always, but reality is not that kind. Sometimes, you will be wrong. Sometimes, you will be right. Sometimes you have seen the light and the team is still in the dark. But no matter what, nobody will follow you if you cannot set a direction and it is hard to inspire confidence in a team if you are not convinced yourself.

  8. Cultivate your calendar. In my experience, the calendar will fill up very quickly. Take a good look at all your commitments and establish clear rules and enforce them in your calendar. For example, I have set two afternoons set to busy by default to get any kind of programming done. The first 30min of my day are blocked out as Follow Up Time because I bet you there is something to follow up on. I have three one-hour blocks just for organization spread out over the week. I have specifically planned lunch time and short breaks on days with many meetings. I have an out-of-office calendar event after 7pm. I have all my 1:1s in the morning. I have a clear rule for what frequency different people get their 1:1s with, e.g. people on the team get 1h per 2 weeks scheduled, stakeholders 1h per 3 weeks etc. - with the expectation that random meetings come crashing in inbetween.

  9. Learn to plan. Planning your team’s work will either fall on you alone or in cooperation with the team, a producer, or whoever. Plans are not set into stone. They are merely an artifact that we use to measure how fast we are going into what direction, relative to what we thought 3 months ago. For me, a plan must answer the question: Are we on track relative to what we promised? If I am planning for 3 months, I need to have some idea what I expect to have done after 4, 6, 8 weeks or so. This idea will be wrong, but it will give me more information how wrong my estimates for in 3 months are going to be so I can adjust them and tell whoever depends on that work getting done in time. For this kind of planning, you cannot just conjure up random tasks, problems, and estimations from thin air. What has worked for me is this: For everything that you put into a plan, you need to know at the very least (1) what the steps are to make progress, (2) how you know that you are done, (3) who is doing the work, and (4) when you realistically expect it to be done. The limiting resources are usually time and people, so put them at the forefront of your planning process (who is doing what when).

  10. Avoid surprises. One of the keys points of having a plan is to avoid surprises. The same is true for communicating expectations. After all, everybody knows that with software things take longer. Nobody will blame you for it. But if you know that something is delayed and don’t say a word, that’s a problem. This is incidentally also a good expectation for people on your team: Of course things are going to take longer, of course things are going to be delayed - but you can still expect people to tell you. You should not be surprised at the end of a sprint that something did not get done. If you are, someone is not doing their job. All of this applies one level further up as well: If someone is surprised that your team did not deliver, you did not do your job.

I hope some of these points were helpful. I have many more thoughts on the subject but 10 is a nice round number, so let’s keep it at 10.