Difference between a team lead and an engineering manager and how to transition between these roles
Transitioning from a team lead role to an engineering manager role is tough and you will experience many changes when transitioning between these two roles. What happens when you become an engineering manager?
Firstly, no more coding. If you’re still coding, something is definitely wrong and you’re probably not getting enough time to take care of your people. Team lead is a programmer who does some manager and/or process stuff. Moving to engineering management is a total career change. You’re not a programmer anymore and your “technical involvement” is leading technical conversations and encouraging people to build software well - which means sometimes keeping your opinion on how it should be built to yourself even though you “know” how it should be built. (know is in quotes for a reason here. You’re not close enough to really know a lot of the time)
Engineering teams are becoming more mature in that they are providing ways to grow (in salary and title) on both a technical track and a manager track - but just in case the place you work isn’t the biggest killer to moving into management is folks who do so because they think it’s the only way up the ladder to more money/title/influence, and not because their true interest is in growing people. The feedback loops get longer. As engineers, you might have taken for granted being able to write a test and know pretty much right away that something you implemented would work in the way you intended it to work.
Engineering management is more of a lateral change than a vertical one. A manager’s mission is to foster an environment where people can do their best work. It’s about designing communication & organizational systems vs. engineering systems. 99% of problems are communication problems. The other 1% are also communication problems, but you don’t realize it yet. Empathy is essential to resolve communication problems. Active listening, mirroring, and asking “why?” are key tools to use. You will need to delegate, delegate, and delegate. Delegation is a manager’s superpower. If you’re doing your job well, your team doesn’t need to you be successful. You become a value-add vs. a necessity. Here are some common engineering manager archetypes you might like to check out.
One important question that engineers that are going through the transition into more formal leadership roles have is about recalibrating internal success metrics. A lot of work that has built-in more instant gratification and feeling of accomplishment (e.g. through shipping code, getting things done) vanishes and gets replaced by longer-term work (also gratifying but in different ways). I’ve seen many folks struggle with that, often ending feeling like they didn’t actually “do anything meaningful”, or “get anything done” while working full days because their internal success measuring system hadn’t caught up yet. What many folks have found helpful is being conscious of this dynamic, and working to find ways to deal with it. Setting clear goals and expectations with the people around them (including their own manager, reports, and organization), to help understand what those around them need to be successful, and to develop a new reference system for what success means, and giving the internal success measuring system time to catch up. Recalling why they moved into the new role, and determining which aspects about it matter the most to them and their identity. This can include changing your value system and recalibrating their reward system to new success metrics and emotions and also making space to do some of those fun things.
You might wonder - what changes when your direct reports are no longer directly delivering themselves and what are the best ways I could demonstrate these skills so I can actually be offered the role if/when it becomes available? One of the things that people are continuously pushed on when moving from managing people to managing teams was “building a strong bench”. Basically, do you have a group of leads or managers who you trust to run teams or make decisions on their own without micromanagement from you? Do those folks trust you as much as you trust them? Do you loop each other in on what’s going on and can you work disagreements with each other effectively? As you move up to a manager of managers level, you’ll have less of a role in the day to day, so are going to be much more dependent on being looped in on risks/wins/opportunities/threats by your reports rather than getting from direct experience with the team. So there must be a very effective set of relationships between you and your team of leads, and you have to be comfortable with the distance that puts between you and your teams. Gábor Zöld from CodingSans wrote a very honest article about real stories of burnout, and what approach worked vs what didn’t. The biggest takeaway of that article is that you shouldn’t take all the load on yourself, but build a team around you to help you carry it.
In closing, transitioning from lead to manager is about redefining yourself as someone who leads to create value for the business through the organization versus someone who creates value solely through the team. But beware - part of the reason managers get stuck at a certain level is that they become too inward and downward focused instead of looking for partnerships and opportunities up and across the entire organization.
Looking for an end-to-end incident alerting, on-call scheduling and response orchestration platform?
Sign up for a 14-day free trial of Zenduty. No CC required. Implement modern incident response and SRE best practices within your production operations and provide industry-leading SLAs to your customersSign up on Zenduty Login to Zenduty