Make changes easy for your team

As managers, our job is to make our part of the organization better. This requires imposing change. Today we’ll discuss how to make changes: how to overcome resistance, skepticism, change fatigue, and people who push back against proposals.

First, always be listening

First of all, you need to be steeped in the problems of your team. You need to understand them better than anybody. This requires a lot of listening and questioning. Use your 1-1s to ask people what’s going on for them:

• What problems do they see?
• What’s frustrating for them?
• What do they love about their team?
• How do they interact with other teammates, or other teams?

The more you understand the team’s problems, the more the team will trust that you’re there to improve things for them. Your proposals and changes will go over better if there is a track record of you listening to them.

Keep a management backlog

This isn’t obligatory, but one thing I’ve found helpful is to maintain a management backlog. I usually keep a prioritized list of Problems I’m seeing. Each problem is something I think will require management work to improve. While I might not tackle everything in the backlog, I do shift the priorities as I hear things from people.

One of the reasons a backlog can be helpful is you can use it to keep notes of patterns you’re seeing. That way, when you do implement a change, you have a lot more history and context into the problem. And it can give you some examples to use to make a case for why the change is necessary. I call these “observations”.

I keep this backlog separate from my management tasks, and treat the problem I’m working on like my current project.

How to make a change: problem, diagnosis, remedy

Once you’ve selected something from the top of your backlog, here’s how you might go about making the change.

1. You start with a problem. The problem is an observation of the issue that’s happening. It may have a swirl of related problems associated with it. For example, the problem might be that “the team velocity is slowing down”. You’re getting complaints about it, and maybe the team is telling you about it. This is the issue you had in your backlog. I sometimes will write it down for clarity. What are people meaning by “velocity”? Is it that the team just seems to not be delivering as much as it used to?
2. Assess how large of an issue this is. If it’s a problem that you understand reasonably well, and the solution won’t face a lot of resistance, you can just do some small improvements as experiments. In that case, you can skip the rest of these steps. And often you can skip socializing it.
3. Next, your goal is to come up with a diagnosis. A diagnosis is the issue that is at the heart of the problem. This is the step most managers skip, and it’s the most important step. You dig in and research it so you understand it better than anyone. You must do this as rapidly as possible. There may be 10 problems in the mix — the diagnosis identifies where to focus. I usually do this by stacking up intensive conversations with the people involved: all within a couple of days. But I might also look at any tools, or any data that can help me understand the situation. If we’re looking at the team velocity, I would stack up 1-1s with the team and ask people individually. It could be a million things that are slowing down the team, or it could be multiple things. When you understand it well, you have a diagnosis. A clear diagnosis is important, because usually the remedy is clear with a good diagnosis. Also note it is fine if the diagnosis is that there are lots of small problems.
4. Finally, you come up with a proposed remedy. This should be something that will make the situation better. It doesn’t have to completely solve the problem, but it should make things a lot better.

I usually recommend writing down these three things in a half-page or page doc. This clarifies your thinking. The sections are Problem, Diagnosis, and Proposed Remedy.

Socialize your plan

After you’re done all this work, you may think you have the best plan in the world. You probably understand the tradeoffs of your solution better than anyone. It might be the best plan in the world. But people resist smart plans all the time.

The best way to get people to get on board with a plan is to give them a chance to internalize it and improve it. As a bonus, they might even improve it!

So the next step is to shop your plan around in a gradually widening set of people. It’s important to really ask each person to try and improve the plan. Don’t just share it with people — ask people to critique it. Ask them to make it better.

You can do this in person, or via tools like Google Docs. My favorite approach is to schedule time where people can read and comment on the doc quietly together. You can have a discussion at the end of the meeting if you like. But you can do this in a discussion, or asynchronously.

As you get feedback from each person, incorporate what seems valuable, so the plan improves. Iterate quickly, and thank people who improve the plan.

Like magic, everyone who participates in the crafting of the plan will be more inclined to support it. And the plan will improve from all of the additional feedback. As it gets to a wider and wider audience, it will go from being a good plan, to a great plan, with widespread support.

The way you broaden the plan is important. If you take too long to broaden the circle, you’ll get rumors and people will feel left out. If you don’t include enough people, you won’t get the support for the plan, and the feedback you need. Usually I like to show it to another person, then show it to a leadership group, and then the team.

Communicate the change

You’ve circulated the plan with leadership, and key people. You may have talked with a few team members about the changes. It’s important to act quickly so that things don’t start being spread by rumor, and the people affected have a chance to weigh in.

The next step is to communicate the plan to the whole team. At this point, you have already received a lot of feedback, so you’re probably able to anticipate objections or concerns.

The most important thing when communicating the plan is to say it is the plan, and that you’d appreciate any feedback on it if people have ways to improve on the plan.

When you tell people about a change, different people need to hear different things to understand a plan:

1. Goals. What are the goals? What do we want to happen?
2. Process. What is the process we’ll follow?
3. Constraints. What are the constraints and requirements?
4. Roles. Who will be doing what? What will everyone be responsible for?

You need to communicate all of these things when you communicate a change.

This may seem like a dangerous thing to do. But people don’t like to have things imposed on them. And by following the previous steps, you will be better prepared to respond to any feedback. And they might improve the plan! Be open to changes.

Reducing the cost and fear around changes

I see managers get into trouble rolling out changes. Usually this happens because people are nervous about the changes. So here are a few things you can do to make the changes seem less threatening.

First of all, if you communicate the change as an experiment , that’s often less threatening. Use language like, “I’m seeing this problem, and I’d like to propose we try this for three weeks. I suspect the first few weeks will feel awkward and it may even be worse for a while. But I’d like to hear your experience, and I’ll be evaluating whether this is a good change according to these criteria. [insert criteria].” Then after a couple of weeks, you can share what you’ve observed, get feedback from the team, and learn from the experience. A lot of objections will fade when people realize that you’re going to be looking for evidence it isn’t going well, and that you will adapt.

A second element is to communicate whether the change is easily reversible. Some changes are one way doors. Others are two way doors, easy to reverse. Don’t fret over two way doors. But be sure to communicate what type of change you’re implementing.

Finally, you don’t need consensus to move forward. Your role on the team (if you’re responsible for team process) is to adapt and continually improve the way the team works together. You’re a specialist focused on how people work together. Just like the team might have someone that is a specialist in reliability, or the frontend, or the backend, your role is team improvement. It’s okay for you to say, “I’ve heard all your feedback, and we’re going to move ahead with this plan. I’ve heard some concerns from a few of you, and I appreciate hearing them. But I believe we’re making the right tradeoffs right now. I ask that you all try and give this a shot at being successful, and in return I’ll be on the lookout for signs we should reverse course.”

Of course, you have to be careful when you move ahead with substantial objections from the team. Ultimately, you have the power to do it, but you may not want to use it. What I try to look for is whether people are expressing concerns, or whether they are trying to veto the idea. If they’re really trying to kill the idea, it’s often a sign you have more work to do before rolling out the change. You either need to be listening more, or there is some relationship work to do.

How much change can a team absorb?

As a manager, you should assess your team’s ability to absorb change.

Usually, product development occurs within a dynamic and shifting environment. This means that ideally, your team should be continually adapting and evolving.

Don’t underestimate the power of lots of small, incremental improvements. I believe the best performing teams as the result of the compounding interest you accrue from these types of improvements.

However, change can cause stress on your team, and teams that are already under stress can reject change. Ironically, the more under stress a team is, the more change may be necessary.

When you’re in such a quandry, look for disproportionately valuable changes. Things where a small change can result in big improvements. Ideally, the result of a change is more bandwidth on the team to absorb future changes.

Watch your iteration speed

I’ve seen many managers get into a trap where they implement changes too slowly. What matters is how long it takes from when you start working on a problem to when you’re able to turn your attention to the next problem. (Also, it matters when the impact of the change occurs).

When you embark on a change, it’s often better to solve a problem in an incomplete way if it takes less time. As long as the situation improves, that means you will have gone through a complete cycle of improvement. Iteration speed is more important than perfection.

There is a trap on the other side of this, however. Making changes without good information is destructive. The key is to accelerate how quickly you can gain context, and be confident you’re making a good improvement.

You can use the people around you to help make sure you’re making good decisions. Ask them what problems they see with your suggestions. Ask them to improve your plans. This only works with trust, so when trust is lacking, you may need to slow down.

Thank you

I’ve learned about this topic from a lot of people. Alex Kroman taught me the most about having other people improve your thinking. James Shore, more than anyone, showed me how participation in a plan gets people on board with it. Robert Goldmann, my executive coach for many years, taught me the many things you have to pay attention to when communicating changes to people. Marco Rogers showed me the value of deliberation, that going quickly isn’t always the best course of action, and that teams have a capacity for absorbing change.

Image by 0fjd125gk87 from Pixabay