I’ve been writing a series of posts on management based on my experiences. If you’re starting with this one, you may want to have a look at: https://www.jlgoodwin.com/words-pictures/2020/9/17/management-the-job-of-a-manager

Introduction

A former colleague suggested that I write a post about “change management,” which is a good suggestion. Like most business euphemisms “change management” as a term doesn’t really convey much about what it really represents. I would say it should be more like: “The company is going to do something profoundly stupid/brilliant/destructive/tedious/pointless to you and your team, and it is going to make many of your best team members upset, and you need to try and keep shit together and damp out the reaction as quickly as possible so it doesn’t fuck over the actual work you need to do to run the fucking business that makes the money.” The profanity comes naturally after the first time you go through one of these events. 

I’ll try and reflect on some of the things that seemed to help me when I had to lead teams through changes. Of course there are all kinds of situations that require change (e.g., gaining and losing large customers, growing out of your current process, merging with another company, etc.) that are perhaps less surprising or counterproductive than upper management whimsy, but my conclusions also apply to those situations.

Honesty is the best policy

My first real experience with poor change management was with the first “large” company (about 15k people worldwide) I worked for, after I’d been in my job for about two weeks. All of the orientation presentations had been about how awesome the culture was, how progressive the company was, and how excellent the people were. I attended my first engineering all hands which seemed pretty normal at first. However, the tone of the business presentation started to turn bleak, with phrases like “rapidly declining market share” entering the presentation. Then the head of the division got up and started their presentation; it was pretty unintelligible and it was unclear if it was positive or negative. The phrase “we’re not considering a layoff” was spoken and you could hear a pin drop. It reminded me of the Zen Koan: “Don’t think of the white horse.” How the fuck can you make that statement without having considered a layoff?

Needless to say, within that quarter, layoffs of ten percent were announced. The layoffs really freaked out the long time employees, who had worked there while it was raining money. People and projects just sorta disappeared without any comment or explanation. It took a toll on other projects that had been teetering near failure as well.

The first thing I would recommend is to share everything about the impending change with your team as completely and as soon as legally possible. Certain things like acquisitions and layoffs can have legal constraints, so do what you can, when you can. Don’t try to spin; tell your team what you know and what you don’t know. Tell them what you have been told about the justification for the change. It will be tempting to critique the change in front of your team, but I wouldn’t recommend that. You have a responsibility to the company to sign up and support the change. If it is really so odious that you can’t bear it, you should quit. 

Talk to the most important members of your team and get their perspective on the change. You should acknowledge their concerns and do your best to correct them if they are extrapolating future events or are attributing intent that they have no evidence for. If you see a trend in the reactions, you should address those in your next team communication. If there are concrete problems that need to be addressed, be open and direct about prioritizing their importance and fixing them.

Limit the blast radius

Work with your managers and/or senior employees to try and figure out a response to the change that minimizes disruption. If you can limit the number of people affected, limit the duration of impact, limit the product scope impacted, or all of the above, then you will help your team get past the change faster. In some cases where the change is really just tedious busy work, you may be able to come up with a pro-forma compliance response and save everyone a lot of time. Resist the urge to immediately restructure the team significantly to address the change. Be tactical at first and then, if the change looks permanent, make more structural changes.

If you have to cut, cut

Later in my career, I was working at a very small company after spending more than a decade at a very, very large multinational company (hundreds of thousands of employees). I was really enjoying having virtually everyone I worked with in the same room and just cranking out code. I came into work one February morning and I immediately knew something was wrong: My boss greeted me at the door. This was very unusual because he never left his crypt before ten or eleven in the morning, and I usually arrived at work somewhere around eight-thirty. And he was definitely not the type to greet you at the door. He summoned me into his office and informed me that they were cutting the company down to just an essential core, and that I was part of that core. I sat there all day watching people arrive, get greeted, taken to the office, and either stay or be walked back out.

In some ways it was fairly well handled; many of the folks that were removed from the engineering side weren’t really the best team members and I was sorta relieved to see them go. On the other hand, immediately after the layoff, on top of what we were already doing, we started working on random projects under the capricious leadership of our CTO. Regular projects started to drag out, the random ones went through a weird escalation of frantic activity followed by abandonment. I finally realized that they were some sort of corporate “forbidden dance'' with potential buyers for the company. It could have been made clearer what the CTO wanted because we weren’t a public company. 

Finally, we were acquired by a large multinational corporation in a deal where they wanted the engineering team but not the product. They sold the product and the rest of the company to a consulting company to help cover some of the acquisition costs. I came full circle through these changes right back to being an engineering manager at a gigantic company, except now my entire team was in another country.

In the case of a cost-based layoff, you should look carefully at your team and think broadly about who the team would be better without. In some cases it might be the very senior member of the team that everyone thinks is untouchable. In many cases these folks are trying to retire on the job and are actually a corrosive force on the team holding back newer, more productive team members. The point is to try and make your team the best possible team at the new size. Sometimes this is just a process of limiting the damage, sometimes it is an opportunity to make a needed change. You should aim to have your team be more balanced, more diverse and inclusive, and still effective after the layoff. If your team is too small to handle all of their projects after the layoff, you should work to kill some projects and reduce scope.

Use the disruption to your advantage

If the change is a large one then you should look at including changes that your team has been planning at the same time. Disrupting the team once is better than a chain of disruptions covering more calendar time. All changes tend to damp out in about the same time so bundling them makes sense.

It is not the stages of grieving

The first time I had to substantially change and reorganize a team was at a large multinational corporation, where I had just signed up to be the director of half of a large engineering team. The team was a little bizarre because it was made up of what looked to me like three duplicate product acquisitions of various sizes. We were still operating all of those acquisitions’ services, even though none of them was profitable or cost effective. So, I thought to myself, “Well I guess I’ll understand the business sense of this at some point, let’s use this to learn how to be a director…”

A few weeks after I started that job, I got a call while I was out of the office from my boss’ boss. They informed me that they needed to cut the division by more than half and refocus on just one product. They wanted me to lead it and lead the restructuring. I of course didn’t mention at that moment that I had never restructured a team that large, that I didn’t know any of the people, or for that matter, any of the products; sometimes you just gotta go with it. The total cut was from about 150 or so folks down to 33. After I finished freaking out about this mission, I began to figure out a strategy.

I connected with the couple of folks that I knew on the existing team, and asked their opinion on who was the most productive member of the engineering team. As usual, this wasn’t the technical leader or the most senior member of the team. I brought that person onto my restructuring team and we collaborated on selecting who we would need to stay in order to build and manage the new product. 

As soon as the reduction in force was announced, I gathered the remaining team together and we immediately started planning our short term actions and our first release. I did a lot of the planning with most of the team in the room, which a lot of folks thought was crazy and would never work. Well, in three months we consolidated and shut down all of the existing services. In one case, we discovered a whole data-center that had never been used since its acquisition, but was costing tens of thousands of dollars a month to generate heat. We launched a new platform on flexible technology that could be hosted in the cloud and the first version of our new product. The cost savings just from the shutdown of the redundant platforms and the shift of hosting covered all of our engineering costs for a year.

The team coalesced quickly because we had immediately established a release cadence, new leaders on the team had to step up and learn quickly, the challenges focused everyone, and there was very little wallowing in the massive change they had just experienced. Everyone was on the inside of all of our plans and requirements so they knew what had to be done. Most critically, they felt like they owned the plan and the goals.

Not every one of our choices for team members worked out, but in this intense release cadence it was easy for managers to see who wasn’t contributing. We made additional changes and hired new people to the team to fill gaps.

You’ll see advice that says there are stages to change management and the stages they quote are based on the apocryphal stages of grieving: “shock, bargaining, etc.” There are no stages. Every person will have their own reaction to the changes and will need their own amount of time to deal with it and in some cases, they won’t come to terms with it. Don’t buy into those platitudes. Your job as a manager is to move forward, be consistent, be positive, and establish new goals and focus your team on them. If people leave your team, you should support them and replace them promptly. 

A key point in explaining the actions of any company to a team: Do NOT personalize it. Even though the impact is personal, causing changes to their career plans, their job, their role, or even their compensation, the company isn’t doing it to them. The company isn’t their friend or family; the company is a machine that is trying to reconfigure itself to make more money. The perceived damage to the employee is an unfortunate side effect of this reconfiguration. And the company has factored this damage into its consideration of the cost of the change. This message can be complicated by flawed corporate culture that proclaims “we’re family” or ”we support you” or ”we value you as an individual.” These things may be true when individual humans say them, but they are never true when a corporation says them.

Don’t mistake team formation for trouble

After any significant change there will be friction and conflict as people negotiate new roles and new tasks. Don’t overreact; it’s best to let these things play out. It can be disconcerting to see people who you thought were reliable and settled seem to transform into problem team members, but that is just what happens when a human hierarchy is tossed about.

Return to steady state

In general when you’re communicating with your team, you should prepare them for change. Don’t create the presumption that things will stay the same for more than a quarter, perhaps less, in an early-stage company. Don’t make overly long detailed road maps with specific commitments going out for years. The Soviets proved that five year plans don’t work. Have high level goals that set a direction and that can be addressed by multiple responses over time. Make short road maps that fit into the planning cycle of the company. Reinforce the notion that these plans might change because the company is dynamic and may need to focus differently or these ideas might fail in the market. 

Within the planning cycle of the company, try to have a cadence and return to that cadence with a new set of tasks and with new goals and priorities after each change. With any luck, you’ll be able to carry forward important goals that you still own from before the change. For example, if your company likes to do quarterly plans, it would be good to make a new roadmap for one or two quarters (maximum) and to plan a couple of releases in the next quarter. The new roadmap might be related to your pre-reorg roadmap or it might be brand new, depending on what changed with your team. The fresh roadmapping process will help your team understand their new mission and begin to focus on it.

Part of the return to normal operations is updating your roles and processes if they’ve changed. Sometimes folks will have new responsibilities and new processes that they are now required to perform. You should as quickly as possible make sure they understand and accept these changes and that you document them and communicate them to the rest of the team. It is a good idea to have a “new organization” kickoff meeting to talk through the whole org and its goals and responsibilities so everyone hears it at least once. Reiterating these changes at future team all-hands meetings is also a good idea; people take some time to really internalize the details.

Summary

You should try to include as much of your team as possible in planning for changes, large or small. People in different roles often bring up key issues that you might not immediately consider in making the change go smoothly. If I had to summarize my approach it would be to communicate clearly, listen to feedback, follow through quickly on changes, and get everyone back to work as quickly as possible. Make sure to always be talking about the job ahead and not about what used to be. Getting your team oriented toward the future will have the best impact on morale and productivity post-change.