TLDR; There is a significant difference between individual contributor and team lead roles. The lead’s focus is on multiplying a compound value delivered by the team, rather than accomplishing something on their own. So the mind shift is necessary to transition into a leadership role successfully.
Have you been thinking about stepping into a leadership role or just get “promoted” to team lead? That’s great, congratulations! The leadership role is great and has lots of fun, challenges, and interesting cases, but it requires a different mindset compared to the engineering role.
Note: further I’ll use the terms engineer, developer, and individual contributor interchangeably. Although it’s debatable and some people prefer one title over the other, however, the difference is not so important in the context of this post.
Promotion or not?
Apparently, the transition from individual contributor to team lead is a big change, but let’s take a look if it is a promotion at all?
It has some elements of promotion. E.g. you’ll have direct reports, some of them even might be your previous peers or you could get a compensation raise (happens pretty often, but not always). Also, there are many talks in the industry stating that team leadership is an obvious next career step for any senior-level developer.
I can’t agree with the last statement because the leadership role implies a significant change in expectations from the candidate, responsibilities, and skills necessary to be good at it. On top of that, I truly believe stepping into a leadership role requires a significant mind shift. This makes the whole change closer to career path switch rather than promotion.
So you can decide for yourself if it’s a promotion or not, but the size of the change remains significant no matter what you decide 🙂
How successful team lead looks like?
When I was considering a team lead role the coach asked me: “How successful team lead looks like in your mind?”. I was absolutely sure how a good developer looks like – they write high-quality code, do great code reviews, decompose complex problems into simple ones, know a bunch of tech tools and fundamentals, mentor more junior peers, are able to drive complex feature development, communicate well with stakeholders, etc. But at the same time, I didn’t have a good answer for the same question about a team lead, only a bunch of random ideas. I was surprised, I thought it must be obvious, but it wasn’t.
After that, I started searching the Internet for possible answers, asked a few people in the company, including my lead, and was very much surprised by the range of answers I got. Some answers were overlapping but the priority of them was different 🤔 At the same time, I noticed the definition of the lead role, its key responsibilities, and even titles were different from post to post. Team leads, tech leads, engineering managers, all had interleaving descriptions and similarities as well as significant differences in their scope. Later I came across this post describing five engineering manager archetypes and that was a very good explanation of the observed answers range.
At the same time, there were common patterns among all the answers. Success was defined at the group level, rather than at the individual level. The leader was considered successful when the team is successful as a group. The leader is focused on multiplying team effect by supporting team members in different ways: setting focus and vision, fostering tech decisions, recruiting the best people, helping each team member to grow, creating a safe environment, establishing and improving processes, supporting team morale and so on. You see there is no mention of working on features, crafting architecture, or learning the latest fancy tech. It’s a completely different role compared to engineering with its own different focus.
What about the code?
What about writing the code then?! I am good at it, does it mean I have to stop and don’t code anymore? Well, the reality is that you shouldn’t write the code anymore. It is not your focus anymore, it’s your team focus. There are a couple of exceptions though – if you’re in a pure tech lead role with somebody else wrangling the remaining responsibilities or if the team you lead is relatively small (up to 4 people) so you might have some time left for working on code. I also know a few leads with full-size teams who are able to book the slot in their calendar for coding work while keep doing all the rest, but the size of the slot is never above 10% and according to their words it’s really hard to fit in.
Does it mean all the experience you got about the code, architecture, patterns, and a ton of other things not needed anymore? Of course not! It’s tremendously helpful for understanding the essence of software development, the process, and the way engineers think.
The shift from writing the code to doing many other things but not code also has a very interesting side effect – it’s harder to sense the feeling of accomplishment. When writing the code it’s obvious – you fixed the bug or shipped PR you got that feeling immediately! With a leadership role it’s different. The impact of your words, actions, and inactions may become noticeable long after you made them or even be left unnoticed (at least without explicit acknowledgment). So as a leader you’d need to adjust your brain to cope with the absence of that immediate accomplishment feeling and find your own ways of validating you’re on the right track, but that’s a topic for another
There are many more differences between leadership and engineering, and I’ve only scratched the surface of that iceberg. However, it should be enough to see that successful transition requires a shift in the mindset. The shift takes time no matter how well you are prepared in theory, so if you’re in the middle of a transition give yourself time to become a better leader for your team and you won’t regret it! If you’re only about to dive into leadership just know, it’s doable and it’s much better to step in being aware of the mind shift.
Good luck and happy leading!