Episode 275 Transcript:

This is episode 275 of The Manager Track Podcast. Today we’re gonna talk about how to successfully move from an engineering role into your first leadership role. But don’t be misled. This is not just for engineers. The things that we talk about here, while specific to engineers, do apply to a large degree, to any other role, any other professional field of expertise, where you moving from an expert role or expert leadership position into a people leadership role.

And with that, I hope you’re intrigued. Let’s dive in.

Here are the two questions. This podcast answers. One, how do you successfully transition into your first official leadership role? And two, how do you keep climbing that leadership ladder and continuously get promoted, 

although the competition and the expectations get bigger. This show with a manager track podcast will provide the answers. I’m your host, Ramona Shaw. 

I’m on a mission to create workplaces where work is seen as a source of contribution, connection and personal fulfillment. And this transition starts with developing a new generation of leaders who know how to lead. So everyone wins and gross. In the show, you’ll learn how to think, communicate and act as a confident and competent leader. 

You know, you can be.

Welcome to The Manager Track podcast.

Today we’re gonna talk about a transition that the vast maturity of you will go through. Now we’re gonna specifically hone in on what it means to transition from a hands-on engineer to someone who leads an engineering team.

But as I said in the introduction, this isn’t just for engineers. So if you are not an engineer. Please continue to listen ’cause you’re going to get a ton out of it. The reason why I wanna talk about engineers specifically is because a lot of participants in the Leadership Accelerator, our 90 day manager readiness program are in the engineering field, but also because engineers tend to be analytical and intelligent and they tend to get promoted because of their technical expertise.

And the combination of these three create some specific aspects for going through the transition into leadership, and I wanna talk about those today. So let’s get into it. Typically as an engineer, you are cranking out code, you are debugging production issues. Maybe you are being the person, or most likely you’re being the person everyone comes to when something breaks.

And then you get called into a meeting room and it’s announced, or you’re being asked to now lead the team. You are excited and obviously people congratulate you. They’re obviously proud of you and maybe you’ve even communicated ahead of time that you wanna get that promotion.

So here it is. And suddenly you got people reporting to you. You are now no longer the one who’s coding, debugging, fixing problems, but you are now in meetings after meetings, and you might start to wonder over time what happened to your actual engineering job that you actually liked and you know you’re really good at.

And if the people leadership aspect doesn’t seem so easy or as easy as you would’ve hoped, and maybe not even as satisfying. Then this can get tricky and if you’re naturally a problem solver, which we know engineers tend to be, then it can feel like you are spinning the wheel, not really able to solve the problems on your team.

While the technical problems seem solvable. So that can be tricky. In addition, you’ve probably analytical and you like clear inputs and outputs, and you like to fix things. But then you find yourself in management stuff and you realize that management things and talking to senior leaders and to non-technical people and trying to create OKRs that fit into the organization’s OKRs, or you’re participating in a project now at a higher level that has to do with influence and authority and office politics,

and it can start to feel a bit messy or at least ambiguous. And for many engineers, a lot of the skills that made them a great engineer, they actually realize that in a leadership role, those specific skills are now working against them as a new leader.

So I want to walk through the four biggest challenges I see engineers face when they make this jump into leadership. Now, as I said earlier, these aren’t just random observations. These are the patterns I see over and over again. The things that trip up, even the smartest, most capable technical people when they step into leadership.

So if you find yourself in this situation or you wanna prepare for moving into a leadership role, know that when something goes wrong, it’s not that you’re not. Cut out to be a leader. It’s not that you’re not good at managing, It simply means you’re going through the learning curve, you’re going through this transition.

And if you don’t have a coach, a leadership program, leadership training, comprehensive leadership. Not a one day workshop or a two hour class. If you are trying to figure this out on your own, it is inevitable that you are going through some trial and error. Hardship, ships and struggle. 99% of new managers.

R. And that is also the reason why 87% of leaders down the road say they wish they had better training, earlier training on leadership skills so that they wouldn’t have to go through these struggles and challenges. So if you are in that learning journey, know that one. It’s part of the process. And two, there would be a better way, which is to get trained.

You would never recommend someone to start coding an application if they never learned any coding skills, but yet you are expected to lead a team without ever learning anything about leadership skills. That is backwards. Now, of course, we think we have the most proven and most effective leadership development program for new managers with our leadership accelerator, which you can find more information in the show notes, but regardless of what you do, invest in skill training in addition to listen to the podcasts that you’re already doing.

Obviously, otherwise you wouldn’t be hearing me talk about this. Okay. So with that said, let’s talk about these changes and challenges. The first one is the identity crisis. Who am I if I’m not coding? alright. Let’s start with this existential crisis that nobody warns you about.

You’ve spent years, maybe even decades. And a lot of resources building your identity around being the person who solves technical problems. You’re the one who can debug, the trickiest issues, who understands the legacy code base, who can architect elegant solutions to complex problems, and then suddenly you are not doing that anymore.

I remember talking to a new engineering manager who told me she spent her first month feeling like she was pretending to work. She sit in meetings about team capacity and resource planning and sprints, and all she could think about was how her old teammates were pushing out work and code. While she was talking about sprint velocity. This hits engineers particularly hard because you are used to changeable outputs. You’re used to create something or see something or fix something and see the solution, and at the end of the day you could point to the code you wrote or the box you fixed, or the features that you shipped.

Now you’re having conversations about career development, removing blockers, helping other people solve problems. That weren’t actually yours in the first place, and it doesn’t feel like real work,

And while you might start to intellectually understand, okay, that is part of the new role and this is part of leadership and I wanted that and I know I need to lean into it. You might also realize this is particularly true for engineers who work in an environment where things change all the time.

You can never. Just know something and then know it forever. It will always change. And you used to learn new tools and update your skills and, and revise your methodology and unlearn stuff, right? You constantly used to this and you realize that if you are now not spending time on the technical side.

You would lose your technical skills, you wouldn’t be able to keep up. Especially now where like everything is infiltrated by ai and for many engineers, this is a new skill to learn. So you now don’t have the capacity to do, and you now may not spend as much time on the technical things and you realize if you wanna become a technical people leader.

Someone that has expertise and earns respect through their competence in addition to hopefully also other things, but also through competence, then you have to lean into it. So you need to stay sharp enough to be credible with your team to understand the technical trade-offs that they’re discussing to spot when something sounds off in a design review.

But then again, you’re also clear that you need to zoom out and think about business priorities, cross team dependencies, product strategies, team strategies. There’s a reorg coming and the list goes on. So it’s this constant tension between staying in the weeds and rising sort of above them. And most engineers handle this by trying to do both at a hundred percent.

And that can lead to burnout, but also mediocre performance in both areas. So if you try to keep up with the technology, but also try to lead, you basically have two chops at the same time. So the shift you need to make is pretty fundamental here. You chop isn’t to be the best engineer on the team anymore.

Your job is to multiply the effectiveness of your entire team. And that does mean that your technical skills become a tool for better leadership, not the primary way you add value. I’m gonna say that again. They become a tool for better leadership, not the primary way you add value. and that transition can feel uncomfortable, like realizing that your technical skills now become a tool of leadership, no longer the main sort of anchor of your success. And with knowing that, what does that mean? And how you spend your time and how you invest your resources and your capacities.

Okay. In addition, not only can this create sort of a discomfort, but also the transition in itself can be a bit awkward because not only are you going through this, but if you are leading former peers, then you team members are actually transitioning to with you because that relationship is changing.

So maybe you regret grabbing coffee with your teammates and you were complaining about management decisions or leadership or the company at large, but now you are in management and you can no longer do this the same way. You have to understand that you now represent leadership.

So shifting. Into this new role and into this new identity means that you see yourself now as a leader more so than a technical expert. It’s not to say that you can’t be honest about your thoughts and opinions, but you also have to constantly remember that you are now no longer a peer, you’re no longer the buddy.

You are now in management, and some of these relationships will change. And sometimes you have to say like, Hey. I’m gonna put the hat on of a friend of a coworker, and then I’m gonna put the hat on as a manager. And these are two different perspectives. And so your identity and how you see yourself as a leader, as a technical leader versus a people leader, that changes and it’s huge.

And if you’re not aware that this is going to happen and what kind of ramifications or consequences it has, then. It likely slow you down or it make, create challenges and issues that weren’t necessary and can set you and or your team back.

Okay. I’m gonna move on to the second change. So the second one is communication skills. In essence, it’s not what you say, it’s how you say it. Okay. So something that will mess with your head. Is that as an engineer, being right was usually enough. So if your code worked and was efficient, you were good. If you could point to the root cause of a bug, you were the hero.

But as a manager, being right is kind of just the entry fee. Okay. How you communicate that rightness now determines whether anyone actually listens to you or, and changes their behavior based on what you said. Okay? So there are a different, different sort of subcategories to this, and I’m gonna start with feedback first.

Most engineers default to what I call sort of the debugging mode when giving feedback. So someone’s code reviews are too harsh, so you tell them, Hey, your code reviews are too harsh. Tone it down a bit. It’s direct, it’s clear. It should work, right? Because you saw the problem and you fixed it. You told ’em what to do to fix it, except it doesn’t.

Because people aren’t code. You can’t debug your people like you debug a code. You can’t just identify the bug and then patch it. That person might be giving harsh feedback because they’re insecure about their own skills or because they think that’s what a good senior engineer needs to do, or because no one ever taught them how to give constructive criticism.

So effective feedback requires you to understand the why behind the behavior, not just point out the what. So it means asking questions instead of giving just some advice of like, don’t be so harsh. So for example, why. Again, sort of the reason for your communication is accurate, but how you say it changes or

how you say it matters. So you could rephrase this initial comment about your code reviews. Too hard to say, Hey, I’ve noticed some tension. After your code reviews. What’s your take on how these conversations are going? Let them identify the problem instead of you diagnosing it for them and then telling them how to solve it.

Okay, so this is hard for engineers because it, it’s their instinct. It might be your instinct ’cause you’ve been literally trained and develop this skill to jump straight to the solution. If you see the solution, why have a workaround, why not address it right away? Okay. Let’s talk about another example.

Someone comes to you with a problem and you want to tell them exactly how to fix it. ’cause by the time they said the first two sentences, you already got it. You’re like, okay, okay. And I’m like being polite and I just listen, but I already have to answer in my head. So you nod along and then once they’re done, you tell them what to do.

But good managers learn to coach people to their own solutions because people are way more likely to act on insight that they’ve discovered themselves. Okay? Now instead of giving advice, because you clearly see the problem and the solution, that they’re, they’re not.

You now have to communicate with them in a way where they’re solving things for themselves. They’re becoming resourceful. You are there to facilitate, but you are not there to solve it for them. You are helping them see things more clearly. Identify what the problem is.

Come up with solutions. Test these hypotheses or these ideas, and then support them in the execution. Okay. Two very different ways of communicating one is sort of the debugging mode, and that doesn’t work in the vast maturity of cases.

In our feedback training, we often state this research from DeNisi and Kluger that states that a third of feedback given from managers to employees, does not improve performance at all. Just keeps it flat, nothing changes. A third improves performance, and a third decreases the performance because of de disengagement and de-motivation.

A third, a third, a third. So of all the feedback given really only a third lands and then makes people wanna change for the better. Okay, so knowing this means we have to really learn the skill and how to get feedback so that we do see the change. Okay. A bit of a different angle. Same around this topic of communication, and that is managing up. Imagine you have to explain to the chief revenue officer that migrating the CRM to a new tool, a new CRM may take up to three months and the Chief Revenue Officer, the CRO keeps asking why you can can’t copy the data over, why the tool that they bought says this will be done in 48 hours, so why is it taking us three months?

You can’t just say. Because you don’t understand the databases, you don’t get it or you don’t know the, the, the sort of like exceptions and rules and the patches we’ve made in the past, and that is why it’s three months and not 48 hours or three weeks. Even though they might be true and they may actually not have a clue of how all this stuff works and how this officer is made or patched together in the backend.

But in order for you to be effective and work well with that CRO, you need to translate the technical complexity into business language. So you could say, if we rush this migration, we’re looking at potential data corruption that then could take us for a loop.

Or we might lose really valuable information that we’ve tracked from key prospects or key clients that we’ve been tracking for years. So the three months timeline includes the safeguards that protect our our customer data, and our leads.

So your team and it, and your team’s ability to close deals isn’t impacted by. Unreliable or missing information in the CRM. Okay. So the same information sort of, but framed in terms of what they care about.

Okay. That was communication around managing up. And then the last thing that I wanna say here, when it comes to communication and how to say it, is learning to say no likely as an individual contributor. As an engineer, you might have had to sort of push back on a few things because you had too many people coming to you and you needed to prioritize.

But it’s a whole other thing to do that as a team lead who not only has to say no for themselves, and by the way, also no to all the people who are still coming to you, if you know they’ve known you as the go-to person in the past, they may not go to the person who replaced you in your old role.

They may still come to you ’cause they trust you. They feel like they have a relationship with you and that you could just sort of like snap the finger and it being done so suddenly you have all these incoming requests that you just need to say no to. But on top of that, you have a whole team that relies on you to advocate on their behalf, to protect their time, to make sure that they’re focusing.

On the fire drills that actually need to be put out, not the it bitty little sparks that are going on, that they’re actually focused on the strategic objectives, not on stuff where scope creep takes over or irrelevant urchin, but not important things. Now, while we wish we could be super direct and say, look, no, we don’t have capacity, and that be the end of the conversation.

We actually need to help stakeholders understand the trade-offs and then if they have authority over us, if they’re sort of senior leaders. Maybe it’s your CTO or your vp. Then let them make informed decisions about priorities, and that requires a different way of communicating and something that many new managers have to learn.

They have to figure out, how do I say that without being rude, without challenging the authority, so to speak too much, but also not just give in and say yes to everything, right? Because that then actually diminishes your leadership and your effectiveness.

Okay, so that was around communication. Now I’m gonna move on to change number three, and that is to delegate without losing your mind.

Now, this one might be the hardest for the analytical, perfectionist engineers or just those who with really high standards. If that is you, you know exactly how you would approach a problem. You can see the solution in your head. And you know, the pitfalls to avoid and the optimizations that you need to make, but now you have to watch someone else solve it.

Not in your way, but in their way, and you have to be crave at that. That can be so hard to do, especially if you see it’s not going well. They’re going down the wrong direction. They’re flailing and it’s not working, and you are just standing there like, Hmm, I should have told them, or I told them and they didn’t listen.

I was working with an engineering manager who was struggling with this exact issue. He assigned a performance optimization task to one of his senior developers, and when he saw the approach that they took. He couldn’t help himself. He jumped in and he rewrote a significant portion of it. Now, overall, his reasoning was solid, right?

His approach was more efficient, cleaner, and also it would be easier to maintain. And so with that, he was probably right. I’m not an engineer, so who, I’m not an engineer, but based on my understanding of the situation.

He had from a technical perspective. He had good reasons to share his opinion, but he completely undermined his developer’s confidence and missed an opportunity for them to learn and grow because he stepped in and took over part of the ownership of the project or the task that he delegated to that developer.

And how do we feel when we’re being assigned something? We come up with a solution that we think is good, and then someone else just sweeps in without asking us and just re-do it or does it differently. I had that happen to me before and it’s frustrating. It’s like, okay, whatever. Then you do it. Then why do I even bother?

Is often sort of the reaction. This is when we start to demotivate our employees. We also, as just mentioned, we remove them from the opportunity to grow. We take that away and so we have to bear in mind that yet maybe your approach is more elegant. But maybe also their approach has some benefits. Maybe it’s easy for the rest of the team to understand and maintain what they have planned to do. Yes. Maybe your solution is more performant, but their solution ships faster and performance isn’t the bottleneck right now.

So their on one hand different perspectives to take. And on the other hand, it’s to realize the cost, the side effects of chomping in. So learning to delegate effectively means accepting that good enough often is good enough. It means setting clear expectations about outcomes without micromanaging the process.

Especially not re in a reactive way where suddenly you see something or you hear something and then you get nervous and then you jump in. If you are micromanaging and you set as a tool because it needs more hands-on approach or an hands-on involvement by you, then you have to set this up proactively.

There’s ways to do this that isn’t annoying or disempowering to employees. Okay now to zoom back out, the biggest message here is to be comfortable with approaches that are different from yours.

Again, you’re not abdicating all responsibility for quality. You still need to set standards. You still need to do code reviews, or provide guidance, but you need to resist the urge to optimize everything to impose your preferred solutions on problems and to jump in without you first talking to them, and ideally, they would ask for your help before you jump in. Just to highlight this one more time. The goal of delegation isn’t to get exactly the result you would have produced. The goal is to get a good result while developing your team’s capabilities. And sometimes that means watching someone take a path you wouldn’t have taken.

And learning to trust their judgment and also let them have that opportunity to learn and grow through the challenge. Most of us learn the most. In times of hardships, like in times something is rough or we failed and we’re like, oh man. If I go back and look at my biggest moments of learning in my career, it was always when I was in trouble.

It was always when I did something that. It wasn’t good. I didn’t show up well in a meeting. I didn’t communicate something I should have communicated. I chose the wrong approach in a project implementation.

Those are all the moments they were so rich in lessons learned that of course I wanted to make sure my manager a, has my back and two would prevent me from doing something that was causing damage, like financial damage, reputational damage, or would impact our customers.

But within sort of that realm of tolerance where we can learn and grow. That is part of the process and you’ve gone through it and your employees they should be going through this as well.

So after talking about delegating, let’s not talk about imposter syndrome, and this is sort of the question, do I actually deserve to lead these people? It’s a bit of the elephant in the room often. So when you are sitting in your first team meeting, ask the new engineering manager, you look around at your team and you can’t shake the feeling that you are sort of pretending you are performing a role.

And you wonder why, why you, and you also look maybe at people who have really strong expertise. They’re really good at what they do, or they may have a job or a role. And in in a field that you have no clue what they’re doing. If your background is in software engineering and suddenly someone comes in with a data science background, they know things that you don’t know, and now they’re on your team and you’re managing them.

And that may make you feel uncomfortable. So someone might have more expertise, someone, so someone might have more expertise in a field. Someone else might have more experience than you. Someone else might be older than you. Someone else maybe just completed a really cool project, has architected a really elegant solution.

And everyone across the company is praising them. And now you are supposed to be their boss. So the imposter syndrome, this idea that you don’t belong or you don’t deserve, or you’re pretending to be there, you, you feel a bit like an imposter.

Here hits engineers particularly hard because they’re used to being evaluated on technical merit. And if you were the best debugger or the fastest coder, or the one with the deepest system knowledge, the hierarchy all made sense. But management isn’t about that. It’s not based on technical skills and you can’t sort of quantify leadership skills and influence as well as you quantify or assess technical skills.

And that can mess with your head. So I’ve seen new engineering managers try to prove themselves by being the most technical person in every conversation. They’ll dive deep into implementation details during planning meetings, or they insist on reviewing every architectural decision, or they jump into debugging sessions to show they still got it.

But this is ego-driven. All these behaviors of overdoing it are coming from that ego, that place of like needing to prove yourself, but also needing to prove your value to others. But the thing is, your value as a manager isn’t proving you’re the smartest engineer in the room.

It’s creating conditions where your team can do their best work. And sometimes that means to admit you don’t know the answer to a question. Sometimes it means asking your senior developers to lead technical discussions while your focus is on removing their blockers. Right. And by the way, imposter syndrome often shows up worse when we’re managing former peers, especially once who might have been candidates for the same role. And then you got it. And they’re kind of eyeing it and, and they might be giving you a bit of an attitude or you just wonder what they’re thinking.

They may also know your technical weaknesses. They remember that time you introduced that bug that took down production. They might be wondering why you got promoted. Instead of them, they think that they know better or they could do better, and so the biggest thing here is that you can’t fake your way through this. You can’t pretend to know things you don’t know. You can’t rely on technical superiority to establish your authority. That will take you for a spin and likely make you feel exhausted and it isn’t gonna feel good to the team either.

When you’re overly involved just to prove something, they all, by the way, pick up that it’s your ego who’s running the show. What you can do is to be transparent about your learning curve, to focus on the value you are adding as a manager, as that special role, and to lean into the skills that actually matter in leadership.

Okay? So your job isn’t to be the best engineer on the team. Your job is to help your team be the best engineering team they can be, and. Ironically, accepting that you don’t need to be the technical expert in every situation actually makes you a better leader. Okay, so this really important. The engineers who struggle most with this transition are the ones who try to maintain their identity as a top technical contributor while also being the manager.

We’re like closing the loop now to what we’ve talked about in the very beginning. The ones who succeed are the ones who embrace the new role and find fulfillment in their team’s technical achievements instead of their own. Okay. Now let’s wrap this up. I am not going to sugarcoat this, the transition.

Into leadership and in in this context from being an engineer to being an engineering manager. It’s hard sometimes actually really hard, depending on the conditions, depending on how strong your team is, the challenges that you’re facing, you are essentially learning a completely new chop while everyone expects you to be good at it immediately because you were good at your old job and you are smart and capable and technically skilled.

The four challenges and changes that we talked about today, the identity crisis of letting go of your hands on technical role, developing communication skills that go way beyond the technical correctness.

Learning to delegate without losing your mind and dealing with imposter syndrome. These are the big ones that trip up. Most engineering managers. Okay. Now here’s the thing. If you are aware of these challenges, if you expect them and you prepare for them, you are already ahead of the game. Most people and new managers stumble through these transitions without even realizing what’s happening.

The engineers who successfully make the transition are the ones who embrace the ambiguity, who get comfortable with measuring their success through their team’s achievements, and who invest in developing the soft skills that then compliment their technical expertise.

So if you are in the middle of this transition right now, or you’re anticipating it, be patient with yourself. It’s normal to feel like you’re not good at this yet. It’s normal to miss the clarity and maybe even the satisfaction and reward that you got from being feeling really productive, solving problems, right, fixing issues.

It’s normal to question whether or not you made the right choice, and it’s normal to ask yourself, how do I stay technically sharp in a time with rapid technical change while also developing leadership skills? It means to be really wise and smart and how you invest in both. How much time a week? Do you spend on developing your technical skills and

how much time a week do you invest in building your leadership skills? In our leadership accelerator for 90 days, we ask for two hours a week for the 12 weeks. Two hours out of your 40 hour work week.

That is not a lot to build a new skill just like you learned how to code or how to be an engineer. And remember, your technical background is actually an asset in your leadership. Your analytical thinking, your systematic approach to problem solving, your attention to detail, these things serve you well as a manager.

You just need to apply them in new ways, and you need to recognize what are the things that make me really good as an engineering manager, but don’t serve me well in a leadership role. The key really is in recognizing that leadership is a different skillset or requires a different skillset than what you used to do.

It’s not better, it’s not worse, it’s just different. so you are expanding your skillset, and I hope you’re excited about it.

If you are eager to learn and grow, you want to be a good leader, not just for your and your career sake, but also because you want to, for the sake of your team, you want to have your team. Look at you and respect you as a manager and learn from and through you for a team to feel like a team to be engaged, to enjoy coming to work and being part of what you and your company are trying to build.

If that is you, then the Leadership Accelerator program might be a great fit. So check out the show notes if you’re interested. And with that, this is a wrap for today.

I wish you a great week. Thanks so much and I’ll see you next week. Another episode of The Manager Track podcast bye for now.

If you enjoy this episode, then check out two other awesome resources to help you become a leader. People love to work with. This includes a free master class on how to successfully lead as a new manager. Check it at archova.org/masterclass. 

The second resource is my best-selling book, the confident and competent new manager, how to quickly rise to success in your first leadership role. Check it out at archova.org/books or head on over to Amazon and grab your copy there.