My experience transitioning from individual contributor to team lead

I’m about 7 months into my role as lead software engineer. I had been pursuing a move into management for a couple of years — but, despite talking to other people who did the role and trying to read up on it — the reality was quite different to what I expected. In writing this article, I thought I’d share my experience in case it helps others who are making the transition or considering doing so.

(For the record, at my company, the title of Team Lead or Lead Software Engineer is a management role. In Big Tech, the equivalent title might be Engineering Manager.)

At some point, every manager was a hapless and new, promoted (probably) because they were good at something else. It’s a strange point in anyone’s career, because you’re not considered junior, but you’re also doing a lot of things for very the first time. And, most likely, you’re going to be bad at some of them. This concept has a name, the Peter Principle, and it’s the idea that people in a hierarchy tend to rise to a “level of respective incompetence”: in other words, people eventually get promoted out of a job they’re good at and into one they’re bad at, and then they get stuck.

This is not, however, an article about getting stuck! I’m working hard to avoid falling into the Peter Principle trap, by being very purposeful about trying to grow into my role and putting particular effort into the new set of skills that it requires.

So far, everything we’ve discussed more-or-less applies to everyone going into a management role for the first time. But there are some factors that make software engineering a particularly strange transition. That’s because working as an individual software engineer is a lot about you and the computer, solving tricky technical problems, and — ideally — having a lot of uninterrupted time to think. It’s more about hard skills and less about people stuff. If you’re that way inclined, it can be pretty fun.

Managing — as in, people management and product management — is very different. It’s people-y, with lots of conversations needed with lots of different people to make things happen. And with more conversations comes more “fluffy” stuff, like trying to keep people happy and motivated, or trying to help people who are struggling to up their game. Managing software engineers is hard because the average engineering type is, in my experience, on the quieter and more introverted side. 1–1s can feel a bit one-sided, and it’s better if they’re not. I sometimes end the day with a sore throat.

But managing can also be fun. It’s just got a different set of goals and your big wins won’t always come from what’s in the codebase. In my company, the lead engineer role typically involves managing somewhere between two and six engineers. The expectations are that you continue coding roughly 50% of the time, but your priority is no longer your individual output and the type of coding tasks you should focus on shift to: either unblocking other team members or doing “staff engineer-level” tasks like setting up new code patterns for the team to follow.

For me, one of the biggest initial challenges was shifting my relationship with people who were previously your peers, which felt more difficult for those who were at a similar or even a higher technical level. You want to win trust gradually, so that when you need to deliver critical feedback or make decisions, people are willing to listen. For someone like me, who has spent a lot of time trying to be as agreeable as possible, having difficult conversations has been a challenge.

I have had to come to terms with the fact that I output less code than before, I have less uninterrupted thinking time, and I sometimes have to give up interesting work because either I don’t have the time or it’d be a good learning opportunity for somebody else.

Sometimes my big wins of the day are now “people manoeuvres” — things like convincing our scrum master to change our Jira board, convincing the principle engineer that we should prioritise work differently, or convincing the product lead that a feature needs to be significantly different because of technical constraints. The amount of conversation needed to make some of these things happen can be surprising, and sometimes frustrating, but it’s also pretty much inevitable working in anything beyond a very small team.

My priority is now the productivity, output and quality of the team as a whole — and my instinct, in crunch time, to up the output of my own code isn’t usually the best way to achieve those goals. (Though it is sometimes also necessary, when, by crazy coincidence, three-out-of-six engineers go on parental leave at the same time!)

In particular, I have come to understand my success in terms of shipping features successfully and managing expectations well around shipping those features. To do that, I need to communicate early and often, and to be highly available for my team — so nobody spends too long waiting for an answer. A great individual contributor may be able to solve well-defined technical problems, but it’s the lead’s job to ensure all the pieces are in place to actually take a feature to “go live” and ensure that feature toggles, the launch itself, and any post-launch issues are under control — which requires a mixture of technical and non-technical skills.

I hope this has given a useful flavour of engineering management to those either new to the role or considering taking it on. I’m finding it challenging but rewarding. I do miss certain aspects of being an individual contributor, and I understand why some people try management and then return to individual roles. Though management roles are one of the main ways to climb in an organisation, we are fortunate that — in tech — experienced engineers can also go far via a separate “individual contributor” track, pursuing titles like staff and principle engineers. I also know of many people who have bounced between those two tracks, bringing valuable experience from each side. I’d love to hear about others’ experiences in the comments.