Someone once said to me “you’re good at change management” and I was like, what?
I sat with the idea for a couple of weeks and eventually realized: Oh! That is what I do! I take teams that are struggling and help them focus, align, and start delivering at their potential, i.e. change management.
The thing about change management is that it involves a lot of invisible work that’s hard to follow from the outside. The two things that people see in change management are the change (toward the end, if they are paying attention) and when it goes (sometimes horribly) wrong. Here are some lessons I’ve learned from the change-management trenches, whether as the manager or the changee.
When I was working at a failing startup, a new CEO came in and gave an hour-long presentation about himself (save me from people who think they are that interesting) and handed out a book to everyone about some heroic individual bringing about company transformation.
There was definitely change. Within six months, I had to fire half my team and oversee shutting down the product while my boss was, quite sensibly, at a job interview. Shortly after, I left, too, and not long after that the entire company shut down. For me it was a learning experience. My teammates were very capable—all of us have gone on to do awesome things—but I doubt the CEO and the people he recruited right before it all came crashing down felt the same way.
Within companies, the best effort is team effort, and that is never more true than in times of transformation. Executives who breeze in during troubled times extolling their qualifications and claiming some kind of “visionary” status never seem to work out. When someone claims to be a hero, what people hear is that they don’t need—or want—others on their side. People won’t buy into your ideas just because you tell them to; they have to believe in you. And that requires a lot more work up front and listening rather than bragging.
This one took me some time to grok. Of course low performers struggle—they are (understandably!) afraid of what change means for them. However, high performers seemed to struggle even more, and eventually I realized why: High performers have found a way to succeed in the system as is, so they tend to see the problem as other people needing to get it together and be effective. As a result, change seems like unnecessary overhead that is liable to get in the way of their actual work.
Essentially, low performers need to know the “what”—what the expectations are in the new order of things—while high performers need the “why” of the change explained.
But before you try to introduce any kind of “performance management” to a team, the first step is always to bring in standards, support, and accountability. Once you have that, you can clearly communicate where people need to develop, give low performers the help they need, set them up to be successful, and if it still doesn’t work out … let them go. This is not an easy process, but it is a relatively straightforward and well-documented one.
High performers struggling with change are much more challenging for managers to handle—one, because you may feel like you need them more than they need to stay, which makes it scarier to push back, and two, because high performers tend to have a lot more social capital in the team, and if they are skeptical, others will be too.
So the person who everyone on your team loves and learns from, who you worry the team couldn’t function without, who turns up to your 1:1 and tells you everything that is going wrong? This is the person who you need to get buy-in from. It will be hard, but it will be extremely effective, so take the time. Hone your explanations on them, hear them out, and work to earn their trust. Show them that you will bring them (and others!) with you. Just accept that for this person during this process, it may feel like everything you do is too little and too late. However, eventually, when you’ve succeeded together, their feedback and validation will be the thing that tells you you’ve finally made it out the other side.
Sometimes people look at teams and diagnose problems as an absence of process rather than an absence of values, or cohesion, or delivery. They enact some kind of process—a weekly standup meeting, for example—and then wonder why people aren’t buying into it, and why it wasn’t the miracle they hoped.
Lack of process is rarely the actual problem, but rather a symptom of an underlying problem—which is what you need to address. You may still create the same process, but you should ensure that the process is a contextual answer to a contextual problem in service of an outcome.
When I joined the mobile team at Automattic, there were no standups. But this wasn’t the problem. The problem was that some people didn’t talk to each other, surface problems, and help each other. Others did, and so for those people a stand-up seemed like a worthless addition of process. But getting everyone to a place where they would do those things was really important.
Retrospectives are another process that change managers will be tempted to impose on teams that don’t already do them. But while retrospectives are a worthy goal, they are rarely the place to start. When teams struggle to do retrospectives, often the problem isn’t the lack of retrospective, but the lack of psychological safety that a productive retrospective requires. That might be due to lack of trust or cohesion on the team, or other problems that have not been addressed. You need to address those things first, otherwise the retrospectives will not be productive, and the process will be for naught.
Standups and retrospectives are great examples because you can’t force them on people; the majority of people have to show up and participate. It might feel like you spend a ridiculous amount of time getting people onboard with something that is very standard, but sometimes that is the point. If you expend that energy on one process, and people see the improvement that results, they will be more open to—and hopefully start suggesting themselves—what comes next.
The biggest mistake I made as a change manager was in 2017, when I re-org’d my team twice in four months. First we aligned ourselves by department and by time zone, rather than by project. We made that choice later than we should have done, stalling out of fear and things we hadn’t fully dealt with, and immediately following that we hired faster than anticipated—and our chosen structure clearly was not the right one for the amount of onboarding we had to do, necessitating the second reorg.
Of course that wasn’t my only mistake, but you don’t need a complete list of them here.
I owned up to the team, explained the constraints and the reasoning, and I apologized. While it was disruptive to them, they were understanding and supportive. Their forgiveness helped me forgive myself.
There are certain practices and principles of leadership, but it is an art rather than a science, and this is even more true in the work of team transformation. If we’re not sociopaths (and I do hope none of you are sociopathic leaders), we allow people on our teams space for their mistakes, and part of that is acknowledging that despite our best intentions we will also have ours. We need to honestly and openly admit them and apologize for disruptions we have caused. To not do this is a form of gaslighting that undermines everything else we might accomplish.
There’s no way around the mistakes—only through. So learn as much as you can from them, and admit them to as many people as you can. You’ll do better next time; and your team will be that much more ready to believe that, too.
Cate Huston is an engineering manager at Automattic, where she has led the mobile and Jetpack teams.