5 Steps to Successful Organizational Change

“Every minute you save introducing a change you will have to pay back (at least) twice later.” ~ Juergen Allgayer

Leaders in high-growth environments are constantly managing change as the team scales. Some changes are trivial, others are important, with wide-ranging effects. Too often, leaders are so busy that they fool themselves into implementing important changes too quickly: “I can’t spare the time to fully research the alternatives, so let’s just make the change and see what happens.”

What usually happens next? Employees feel left out or disrespected, and you end up spending way more time communicating your reasons for the shift than you’d hoped. Then people start complaining that the culture has changed, and attrition rises.

Here, I present a five-step approach to introducing a change. To illustrate these ideas, I also tell the story along the way of how one company implemented peer feedback.

The five-step process below is designed for major organizational changes. The story we are using is a good example since the feedback process affects everybody on the team.

Step 1: Choose an appropriate organizational change

I’ve noticed a pattern. Someone reads a blog post or talks to someone from a company five times the size of their own about an organizational change and becomes convinced they need to introduce the same change. As they soon find out, however, a change that solves a problem in one situation does not always solve a problem in another. It can, to the contrary, create problems.

This happens, for example, when a company integrates mobile teams into feature teams too early. It makes sense to do this after the team’s size reaches a certain scale, but until then, it makes more sense to keep mobile teams separate. If you make this shift too early, things can get ugly pretty fast. Mobile engineers end up switching teams on a weekly basis, which makes them unhappy, and feature maintenance becomes nearly impossible. Rather than eliminating problems, this kind of change creates chaos.

“Don’t make a change just because it worked well for Google or Facebook. Do what’s right for your company.” (Christine Tsai)

The change needs to fit the company. Talk to the relevant stakeholders to make sure that an intended change will really help deal with a problem you are having right now.

If a change can’t solve a problem you’re having right now, don’t introduce it.

Revising the Feedback Process, Part 1: Understand the problem

(Here is a case study that illustrates how peer feedback was introduced at a particular company. We can’t tell you the name of the company, but we can tell you how they approached the change. Each section contains another piece of the story.)

The engineering team was growing quickly. The engineering lead had more than 20 engineers reporting to him, which meant a lot was getting done, but that giving meaningful feedback to each engineer had become nearly impossible. The manager decided that because this was a problem the organization was actually having right now, it should be considered and solved.

The manager decided to see if peer feedback would help.

Step 2: Plan the organizational change

Next, work on the change in a group that includes or represents all the relevant stakeholders.

Start by announcing that you see a specific problem in the organization and that you are thinking about making a change, and that you are looking for people to help plan it. Besides pulling stakeholders together, this creates a general awareness that a change may happen soon, which helps prepare the rest of the company.

Try not to invite more than six or seven people, but make sure the group includes stakeholders who will be affected by the change and, if applicable, any departments that must be included (e.g., Human Resources, for changes related to people management). Also, try to find one or two employees who have experienced that new approach in a previous company or have even previously introduced it at another company.

Before the meeting read about many possible approaches. Come prepared! Form an opinion, but don’t force it on the group. Remember, the point here is to include everybody.

Research approaches that other companies have taken (reach out to your network, for example) or that members of your planning group have experienced and discuss whether or not one of these could be the basis for your change. Consider which of these approaches fits the culture of your company. When you’ve found one, don’t be afraid to change it wherever needed. Again, a change that worked for someone else may not work for you, but you can certainly modify it so that it does.

Be very conscious about how sophisticated you make the first approach. The concept of an MVP applies to organizational changes just as it does to products; find something lightweight that solves the biggest problem, and then continue to iterate on it.

In some cases, a change may be a “no-brainer” — something so obvious that following this five-step approach seems too heavyweight. If all the members of this group agree that the change is straightforward and everybody will be happy with it, you can skip the next few steps and just introduce it.

Otherwise, once you have a proposal everyone in the group agrees on, continue to the next step.

Revising the Feedback Process, Part 2: Build a new team to assess the solution

To form a meaningful group, the manager chose representatives from both Human Resources and Engineering, and included the engineering manager. In total, the team included six people, two of which had previously worked in companies that used peer feedback.

After aligning on a very basic approach, they split it into two groups. Both groups worked in parallel on the details of the change strategy. When both teams were finished, they compared the two approaches. The two approaches overlapped in many ways.

The two people who had worked with peer feedback in the past proposed some changes, which then became the basis for the proposed solution.

Step 3: Test the organizational change

Most people leave this out, but it’s a pretty important step:

Test the change with a small group. When the change involves feature teams, for example, choose a team to test the new setup.

When the change involves job levels or peer feedback, you know that some team members will be critical. This is good — to a degree. Let’s call them the “opinion leaders.” To make sure they are good with the change, test it with them first. Not only will they feel included, their feedback comes early enough that it can be integrated easily. And once you get them on board, they often become advocates for the rest of the team, which can only help you long-term.

Revising the Feedback Process, Part 3: Gather feedback from a test group

Next, the team chose three people to do a round of feedback. One of them was involved in the group that designed the feedback approach. The other two were not.

When finished, they gathered input from all three people, as well as input from the people who’d received feedback during the peer feedback experiment. This information was used to make a few small changes to the planned implementation.

Because the changes were quite small, the team was able to finish things up in one round of testing.

Step 4: Share the organizational change

Next, post the results of your work, request comments (RFC), and invite everyone who will be affected by the change to comment on it.

Google Docs is a great way to facilitate discussion within one document because it enables everyone to read and comment, and you’ll have feedback on a change before it goes live.

If you’ve planned the change well enough and have already earned the buy-in of your most resistant team members, no major changes will show up but in rare cases. Everyone will feel included, and everyone will be able to ask questions.

Revising the Feedback Process, Part 4: Gather feedback from the core team

The team sent out the RFC. Most of the questions that came up were about how the peer feedback would influence salary decisions. Once the management team clarified the answer to those questions, there were no other concerns.

Step 5: Implement the first version of the organizational change

Finally, it’s time to implement the change.

Depending on how big of a change it actually is, consider announcing the rollout of a new process or idea during an all-hands meeting. Since everyone should have already read the RFC by the time you hold the meeting, a simple announcement should be enough.

Just remember: most likely, you are not done yet. A lot of problems appear only after you’ve implemented a change. Now is the time to start tracking the outcomes and making adjustments.

Revising the Feedback Process, Part 5: Roll out new process, iterate

A short announcement was made at an engineering all-hands meeting. The first peer feedback cycle would start soon and as expected, there were no concerns. Everyone had already been told about the upcoming change and had participated in the process.

However, when the first round of peer feedback happened, a few problems were discovered.

• Some people received so many feedback requests that their work was severely affected. As a consequence, the engineering lead enabled employees to reject feedback requests.
• Some feedback was meaningless or vague, so training sessions were organized about how to give better and more meaningful feedback.

Conclusion

As you can see, implementing an organizational change is much like implementing any kind of strategy: Identify a need, decide on a possible solution, plan it, test it, and roll it out. Stick to this approach and you’ll be moving through much smoother transitions from now on.

This post includes material from the upcoming book “Scaling Teams” by myself and David Loftesness, which will be published by O’Reilly in 2016. In this book, we will explain in detail the various scaling challenges of software startups.

Alex (@klangberater)

Want to learn more about Scaling Teams, receive updates, and read previews and related work? Follow the Scaling Teams publication, or follow @scalingteams on Twitter.