Implementing organizational change part 2: getting buy-in

In my last post I discussed the role of policies and culture in implementing organizational change. In this post, I’ll discuss a bit about getting buy-in. There are lots of ways to get buy-in for a change, but I’ll discuss two techniques I’ve found especially useful: setting up a committee and handling skepticism.

Having a successful committee

If you’ve had a job in the last century, you’ve probably been a part of a poorly run committee, so if you are skeptical that a committee can be used to solve a real problem, I understand. However, I encourage you to consider the value of committees when they are run well. They can help not just in getting the details right, but also getting team buy-in. Committees can get stuck, get lost, or lose focus, but it’s the leader’s job to keep the scope and purpose clear, set a timeline, and expect actionable results.

I was once at a company that was having issues with changes to system architecture. Architecture decisions were not always taking into account the full impact of changes across all teams. The solution was clear: we needed a process to ensure everyone was informed and had the opportunity to give feedback. The question was how to come up with the best process and how to get buy-in so that people would actually use the process we came up with.

We put together a committee of engineers, being sure to include representation from all teams, and held three meetings. In the first meeting, we presented the problem, noted that other companies had solutions, often called “RFCs”, where they presented proposed changes and gave time to hash out any potential issues. The committee talked about it, agreed that the problem was worth tackling, and agreed to the general shape of the solution. The next meeting we considered a few alternatives, selected one and selected a project to use as a test run. After the test run, we met a final time to retro and make some minor tweaks. Each meeting had a clear goal that took us to the next step.

In addition to helping come up with the right solution and get buy-in, these kinds of committees are also a good time to give your best people the opportunity to help you make informed decisions – be sure to include those voices in your committee meetings. It’s also a nice check on your own plans – if you can’t quickly convince others in a committee of people you selected, maybe it’s not the right time for the change.

If you think people might not be on board with solving the problem from the get-go, but are yourself convinced of its importance, a good strategy is to discuss the situation with them one-on-one before putting the committee together. It’s easier to convince people of your point of view in a one-on-one, and it’s also easier to understand objections. This setting can also put people in a more open mindset because they know the decision is being made with their input. I always like to start by sharing candidly how I arrived at my thinking as well, so people understand my point of view.

Handling skepticism and pushback

At another company I worked at, I implemented a new title ladder. When I announced we would be working on this as a group, some engineers balked at the idea of changing their titles. The objections were understandable: some liked their current (and, in some cases, very inflated) titles. Others were nervous about having to prove themselves based on a rubric, or had a bad experience with title ladders at precious companies.

There’s no one-size-fits-all solution to facing objections, but I encourage you to listen deeply to the anyone who has one – not only is it good to hear everyone out, there’s usually at least a some truth in every objection. When redoing the title ladder, I made sure to talk to every engineer at the company, and ensure I understood their concerns.

But don’t just listen: ask how you can take their concerns into account. Sometimes you can, and sometimes you can’t, but just thinking this through will at least make you a better listener, and most people appreciate being heard out.

If you can’t change the process to address their concern, try to make your argument simple and clear. In the title ladder example, a lot of folks understood when I pointed out how the new ladder would help make things fairer, especially as the organization grew. One person told me he was still uncomfortable with the change, but he hadn’t thought about it from the perspective of fairness and was now willing to give it a try.

Another strategy to dealing with objections is to have a trial period. People are much more willing to give things a shot if they know they can go back to the way things were. Be sure to only use this strategy when you mean it, though. You don’t want someone coming to you asking to undo a change when you had no real intention of doing so. Offering a trial period for the title ladder would not have worked because it was not something we were going to reverse. In other cases, like moving an engineer from one team to another, it can go much smoother if you do it as a trial because it significantly reduces risks that come with any change, and it gives people the confidence to know if it doesn’t work they have an out.

There are lots of other things you can do to help get buy-in, and I’m sure I’ll write more, but one last tip I’ll give is to always make sure to solicit feedback after a change is implemented, and make actual changes if someone points out a concern that can be resolved. This helps build trust in you which makes next time that much easier.