Human Skills 030: Organizational Change
Human Skills 030: Organizational Change
with Elaine May
Elaine May has an incredible varied background in the tech industry. She has worked on hardware teams and software teams, worked as an engineer, manager, director, and VP. She's worked at large international companies and small startups. And currently she is a Senior Engineering Manager at Netlify.
In this conversation we spoke about shifting engineering organizations to be more customer minded, product minded engineers, working with product, and more. But the theme of the conversation was around organizational change. What the process looks like, how to help people change, the importance of respecting the past, and much much more.
How do you bring people out of cynicism to accept change?
I have been cynical. I think that cynics are failed optimists or disappointed optimists. The pattern that I saw with failed changes was a group of engineers would get excited about some new way of doing things.
And in this company at this time, the executives were all from a hardware background. So they did not understand software at all. And so they would just sign off on the change. And then the team would start or the group of people would start using the new tool, the new process, and they'd run into problems. And I'm going to use the analogy of getting married and everything's fine and wonderful during the ceremony and the guy is beautiful and all that kind of thing. And then six months into the marriage, the woman sees the toilet seats up and socks are on the floor and she's like, what have I done?
And I think we all face that kind of thing. We get excited about doing something new, and the reality is always less glorious than the dream, in my experience. And so how do you persevere through those things?
That's where the organizational change aspect comes in, and if you don't have that, what can happen is people just abandon doing the change, whatever that change might be.
And then - engineers, we're good at seeing patterns. And so we see this pattern happen one or two times. And then the third or fourth time that someone comes along and said, I've got a great new way of doing things. We're like, "yeah, I've seen that movie and I didn't care for the ending."
What does it take to get past that "toilet seat up" moment?
I think that whole sequence of events when people see the changes being positive is extremely mysterious to people.
We all know there's changes that come out that we don't like right off the bat. There's a reorganization and I got, now I'm reporting to a boss I don't care for. Okay, that's pretty simple to realize, but when you think that this is a good thing, it's mysterious when it doesn't feel so good in the middle of the change.
And so I think there's four steps to change.
First is realizing the status quo isn't working. Second is, "what are we going to change to?" And then the third and fourth steps, I think are the most important to avoiding this cynicism sort of cycle, if you will.
One is breaking the change down into steps that can be achieved sequentially. Like I said, we're not code. We can't be recompiled. So how do we take ourselves from where we are today to where we want to go That's the stepwise process.
And then the fourth part that is the most important part and the one that I see most often not working well... The fourth part is the most critical and the least understood, especially by executives.
It is support and sponsorship along the way. So the executive sponsor that says "we are going to persevere even though this is hard right now" is absolutely critical to making change in an organization.
And then because change is hard even if you wanted it in the first place, support, of whatever kind of support you want to give people, is also very critical.
But sponsorship, if you don't have sponsorship, most large scale organizational changes are not actually going to occur.
Breaking down changes into steps is hard - What does it take to do it well?
I think you have to think about, okay, here's this thing that I want to see happen in my organization. What is a relatively small, and let's say it's a year-long effort, what is something that could be accomplished within the first few weeks that leads us in this direction of this change that is achievable and not too hard to kind of get things started?
When I was working as this internal consultant, we would produce short, medium, and long-term roadmaps for the organizations we were working with. And the short-term roadmap was three to six months. Maybe nowadays it's one to three months, or perhaps even one to three weeks. But you have this short-term thing that you're trying to do. And then you kind of map out some medium-term things, and then the long-term thing is the final vision.
And just like in Agile development, you start into the process, you realize, okay, I thought this was easy, but it's hard. I thought this was hard, but it's easy. You adjust it as you go. You figure out who in the organization is good at helping provide that support. You work with the sponsor, your sponsor or sponsors to make sure that they're doing what they need to do and so on and so forth.
How do support and sponsorship end up showing up?
I've been an engineering manager, I've been a director, and I've been a vice president of engineering. And at each level, there is some amount of check-in with where is your project at, when is it going to be done. There's some sort of dialogue about that.
That kind of dialogue and attention from the various layers of management in the chain is equally important, if not more so, when it's organizational change.
Because when you're working on a project, you understand, okay, we're in a business, we need to make money, this thing's going to make us money, so it needs to be done, maybe there's customers that you've committed to. There's a lot of external pressure to make this thing happen.
There's not as much external pressure when you're making organizational changes. You're trying to become more efficient. Well, what happens if you don't?
No customer is going to come to you, at least not in my experience, and say, "oh, you didn't implement your new tracking CI-CD tool at the time you thought you were going to. What happened, and what are you going to do about that?"
That never happens. But if you commit, I'm going to provide this feature for you by that date, and you don't deliver, there'll be external pressure.
So this checking in, this it's a balancing act, because as a leader, you have to listen to what people say. It's hard. It doesn't work exactly the way they thought it would. There are problems. And so there's that balance between, I want to hear the problems, I want to solve the problems, and we're going to do this thing that we said we were going to do. We're not going to just abandon it because we've run into a problem here.
On respecting the past while working for change
So one of the things that I think is important in change, and I had not talked about this before, is respecting the past. Sometimes in change, you know, we want to get everyone excited about the new way of doing things, and so we kind of trash the old way.
In this particular case, basically would have meant disparaging people's work for several years, and I didn't wanna do that. what I've come to realize is that there's a reason why things are the way they are. And the organization has been successful up to this point doing things the way they are.
And so respecting that and finding out the difference - What's causing us to want to make this change?
In this particular case, it was pretty straightforward. It was, we need to take this product to a global market, and it's infeasible to send an engineer to every customer site when there's a problem in a global environment.
But when you're making change on some other less obvious level, I think it's still worth thinking about what is the business reason or impetus for this change and what's changed externally that's causing us to want to do this.
It's not that people were stupid, it's not that we just didn't know what we were doing. We were being successful and now we want to be more successful.
What are the different types of conversation that happen during a change process?
I think there's conversations about understanding how we got to where we are. Like, why is this thing happening in the movie, and I think it's important as much as possible to spend time in conversation really listening to what people say about that and trying to figure out how we got to where we are.
Then there's conversations about where we're going. And those are kind of like, a lot of times people will talk about what they don't want. We have too many bugs. I don't want so many bugs.
Trying to help people figure out what is it going to look like when we're successful is painting that picture of success and both for yourself and for - I'm assuming now we're the person I'm talking about the person that's trying to make the change or design this change - figuring out what exactly we want to accomplish and how we know how we'll know we're successful. Those are conversations also that are important.
And then when you're in the middle of the change, the conversation is about how are things going and being open to hearing people say "this isn't working" and being inquisitive about what's not working and trying to figure out how can I solve this situation?
So there are really three different conversations, I think, at three different stages. And then the fourth stage, well, maybe the the fifth stage, because I have four stages, maybe the fifth stage, which honestly I'm not personally as good at, is solidifying the change and celebrating that we actually did this thing. I'm kind of wired to go find new problems to solve. So once the problem is solved, it becomes less interesting. And I sort of forget about that piece.
Does that ever cause problems?
Well, it can. I mean, people like to be recognized for a job well done. And they like their boss to have some amount of recognition. And so I try to mitigate that through various ways.
There's also the risk that people snap back to the old way of doing things if you don't embed it in, again, the human system. If the human system doesn't have this solidified, you can snap back.
One of the things that I saw a lot as a consultant is people jumping to tools without really thinking through the policy changes that need to be in place to make that tool be useful and the process changes. And so I try to design policy and process into the change, but if you don't have that, yeah, you can get people to do things for a period of time and then they go back to their old ways.