Enterprise Engineering Management 102

How to Approach Change Management

Enterprise Engineering Management 102

Check out a free preview of the full Enterprise Engineering Management 102 course

The "How to Approach Change Management" Lesson is part of the full, Enterprise Engineering Management 102 course featured in this preview video. Here's what you'd learn in this lesson:

Ryan discusses the topic of change management in engineering management, and explains that change management involves transitioning individuals, teams, and organizations from a current state to a desired future state to achieve business goals. He also provides advice on how to approach change management, including the importance of understanding the changes, communicating them clearly to the team, involving the team in the process, and addressing any concerns or questions they may have. Additionally, Ryan addresses a specific scenario where a manager is moved to a different area of the business and may not have as much technical expertise, offering advice on how to handle that situation.


Transcript from the "How to Approach Change Management" Lesson

>> All right, well, this also leads us well into one of our final sections in Practical Engineering Management 102, is dealing with change management. And I think given the scenario that Gemi and I we're talking about too is like, he had kind of alluded that this might be coming from not me, right?

I'm just the manager that has to deliver the message or change some process and get the team doing that. Change man is difficult. I don't think I was ever prepared for it as a leader. I mean, I did also say that I was thrown in as an accidental manager.

But it's something that I've definitely grown to think about more and more, and how can I really help show up for my team? So, let's kinda talk about what is change management. And to me, it's transitioning individuals, teams, organizations from a current state to a desired future state in order to achieve business goals.

And so that could be like reorgs, or processes that make you probably do better. But change is hard. People don't like change. And when it's a drastic change and you don't know why the change is happening, that's tough. And so, it's good for us as leaders to try and help people understand those changes and why they're happening.

So some of those examples, reorg, I mean, tech, we've seen a lot of layoffs. I'm sure there's a lot of managers having to have some really tough conversations and trying to orient the people that aren't laid off to, you're still here, we need to work through the work.

And those are not easy conversations to have. Maybe it's technology changes. We're not investing in this technology anymore, we're moving on to something else. New strategic initiatives. New priorities. We're dropping all of our priorities. This one came in, we gotta drop everything. We gotta move to this. And you have to orient the team around that.

Employment changes, whether it be someone is leaving, maybe it's, you've promoted someone into management. It's not a promotion like Gemini said in Management 101, is like, it's not a promotion, it's in change. But maybe an engineer on the team is now a manager on the team, and so that you know definitely changes things.

So, how do you approach change management? First off, this is an important one, is you need to digest the changes, right? As a manager, if it's something that you're not making the change and it is coming from higher up than you, understand what the changes are. What are the goals?

What's the motivation for it? What's the need for it? Why? And then, how does it impact your team? Maybe it doesn't have much impact on your team, great. Still wanna be able to communicate it and talk about it, answer questions, but maybe it absolutely impacts your team and you wanna make that connection for your team.

And then, take some time to think about how you feel about it. That's important. And then, maybe even reflect on that and go, wait, I'm missing some clarity. And try and gather that clarity. Especially, this is all helpful to get this information hopefully before your team does, so that you can show up well.

I've also been in times where I'm getting the information the exact same time as my team, and it's hard. I'm trying to digest all these things the same amount as they are, and guess who they're looking to for answers? They're looking to me. So, then, hopefully you had that time to digest, you've thought about it, you understand how this affects your team, you have answers yourself from higher up leadership or partner teams, whatever that change may be.

So you wanna talk to your team, you wanna make sure that it's clearly stated, what the change is, that that's clear, and then share the reasons, the goals, the drivers, why the change is happening. And then share really how it's impacting your team. This is how I see it show up.

But also be aware that you may not know all the things that's affected, right. There's gonna be things that surface your teams like, yeah, but what about xy and z? And that's helpful to understand and hear that. And then, it's okay to be transparent about your thoughts. It's kind of like what Gemi and I were talking about there's, you don't have to agree with every change.

I think there is ways in which you can be transparent, show empathy, and say, like, yeah, I'm a little worried about this change. Yeah, let's talk about that. You don't have to be like, nope, it's the right thing, and sell it to your team. That doesn't come across as authentic, but you also have to balance the line.

And then involve the team, right? Allow your team the time to process, they might need space, time to just digest it. You've probably already had that time, hopefully. So you wanna give them that time. Leave room for questions, gather the questions. You may not have answers to everything, and it's okay to say, I don't know that answer.

Let me find out for you. I will get that and circle back with your team. Invite their input, try and address any concerns they have. Hear them out. And if you do have answers, try and address it. And then like I said, If you don't, it's okay to say you don't know, and you'll find out.

And then, that's where you can offer to follow up with, maybe it's the leader above you or partner team, whatever it is, and you try and get that information for them. I also like to think about this in a couple of ways of like, maybe there's follow ups, as I've had conversations with my team, there might be some really valuable feedback for whoever is making the change.

That, maybe there's some things that nobody accounted for but the engineers are starting to surface that it's affecting. And so you wanna surface that feedback, maybe something doesn't need to adjust. And then again, get the answers and questions from your team,. And circle back, circle back with your team, close the loop with them, don't leave things open-ended.

Actually, before I jump into the ask a manager, I also want to say that after some changes happen, like, Jem gave me feedback on something like maybe I implemented OKRs in our team. It's great to revisit those things too, right? What was the goal for doing that? Hopefully the team knows.

But then if it's not working, it's great to kind of revisit that. I hope leadership is doing that, and it's like, how are things going on that, and asking for that input? But you might be doing that with your team and just gathering that feedback and sharing that more broadly.

And I think that's an important thing too, is, things can change. Dustin.
>> You can have change or like reorg scenarios, how would you deal with, if you were maybe moved to a area of the business where you didn't have as much kind of technical expertise, for example.

Transitioning from managing a front-end team to a back-end team and kind of those challenges and uncertainties about not understanding, necessarily, the technology that that you're working with or it being outside of your domain of expertise.
>> That's a good one. There's a lot to unpack there. In some ways, it might be a good thing.

Like is a good challenge as a leader, I think you can absolutely be a really strong front end engineer and have that depth and understanding. I think you can go lead a back-end team, like, I don't think that's impossible. There's a lot of common patterns there. But you might not want to do that too, right?

Like, you might just not be passionate about that, that might be way out of your depth and might actually not be a good situation. So I think it's really situational. And it's a good point to reflect too, is like, can I do this? What are the things I'm worried about?

Can I address those concerns? What's that gonna look like? To me, it's a big reflection point, and it might be, I don't wanna be here. That's okay too, right? Like, the business is throwing you in there and you're like, yeah, I'm not passionate about this. Might be my time to leave or go find another opportunity.

I mean, you might be able to say that to your leader. It's all dependent. Maybe there is still room for you to stay on the existing team or to move to another front-end team. But those are the types of things that would go through my head. I know it's not a perfect answer, but it is very situational.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now