At some point in every leadership career, the need for a reorganization arises. Whether it’s due to a growing (or shrinking) business, communication breakdowns being reflected in the system (Conway’s Law), or a misalignment in responsibilities as roles evolve in the team, the gears of your group are no longer cleanly meshing. Changing the organizational structure is inherently risky, and executing it well requires planning and preparation.

Evolution or dynamite

When it’s time for change, I always ask: can our teams evolve naturally, or do I need to set off the proverbial dynamite? Ideally, we’re in the first camp, but every now and then, a more drastic approach is necessary.

Examples of evolutionary change would be a team that’s gotten a little too large and then split into two separate teams, or two small adjacent teams combining. Maybe one team is being dissolved, with its responsibilities and people becoming distributed across the rest of the organization. Whatever the specifics, most of the ownership lines stay the same, keeping people connected to their existing roles. In these cases, you can most likely move forward with confidence. Though there will be some concerns and challenges, people will most likely understand or even anticipate these changes. 

But sometimes, you need a bigger shake-up. As disruptive as any reorganization can be, these are the ones that scare people. Maybe you’re combining five teams into three or changing the technology stack (or product ownership). Though some may expect these changes, they may also surprise others, especially if the shift takes place quickly.

Brainstorming new structures

Once you’ve identified the type of change you’re dealing with, you can move on to the next step of the process: identifying the new structural boundaries. I’ve found that the easiest way to do this is to group the existing systems together based on either product or engineering relevance. 

This isn’t a project for you alone but rather one for you and your first team. From a product perspective, think about all the features your area of the product contains, the user flows, the different applications, and so on. Pull those things into groups that make logical sense from the product perspective; perhaps they’re all part of the same user journey, or perhaps they all help drive the same KPI. Regardless of the specifics, you should end up with a small number of (mostly) coherent sections of your group’s ownership.

The next step is repeating this process, but from an engineering viewpoint. Here, the important things to think about are data stores, services, APIs, and other technical considerations. Again, pull these into groups that make logical sense from the engineering perspective. In this case, it’s likely based on technical stacks, on-call duties, the ability for autonomy, and such. At the end of this process, you should again end up with a small number of (mostly) coherent sections of your group’s ownership.

Ideally, these engineering groups would align perfectly with product boundaries – the way different features or components of the product are managed. However, perfect alignment is rare. This is where the reconciliation begins as you try to adjust the engineering boundaries to more closely match the product boundaries and vice versa. There are going to have to be compromises, and it’s important not to get too caught up in bikeshedding. For example, maybe an API gets split across two teams to facilitate product ownership, or maybe one product area has a few extra KPIs because it allows for a more sustainable on-call rotation. Sometimes these decisions have to be arbitrary, and the most important thing is to disagree and commit where necessary. This is where a reorganization is properly set up for success or failure. It creates a framework that you’ll apply to your staffing. 

A list of names

Decades ago, the boxer Mike Tyson said, “Everyone has a plan 'til they get punched in the mouth.” If your theoretical framework for a reorg revealed that you need to build a team from scratch, the hiring process is likely going to be that first metaphorical punch in the mouth. You may strike gold by finding the perfect people on the first try. But that’s not how a reorg generally works.

Instead, you’ll encounter people with their own expertise, opinions, insights, and baggage. Your job is to place them where they can best contribute while staying happy personally and professionally. Success hinges on this element – the most perfect structure on paper isn’t worth the ink to print it if it causes everyone to quit in the next six months.

You need to identify ideal roles for everybody. Figure out who is going to be excited, who is going to be skeptical, and who is going to be against the assignment. You won’t get it perfect, which is why you need backup plans as changes will cascade; if Alice decides she isn’t happy with the team she’s been assigned, that triggers a change that requires Hassan and Ailani to shuffle as well. Identifying the staffing decisions that will have knock-on efforts, and getting signoff from those who are affected first helps facilitate a much smoother transition.

But when it comes to getting them settled, everyone is different, so you need to approach people specifically based on their needs and expectations. Some folks are perfectly happy being told that they’re moving to a specific team, whereas others are likely to quit if they don’t have a say in what team they end up moving to. Figuring out who to talk to, how to talk to them, and when to talk to them is absolutely key to ensuring that as many people as possible come out the other side of this change feeling good about it.

Planning the transition

Create a clear timeline for the reorganization. No matter how much work you put into getting people assigned to the right teams, if word reaches them via some backchannel, it’s going to make everyone’s lives much harder. What’s more, announcing the change without giving a clear schedule adds to the anxiety. To avoid this, establish an information schedule. Who finds out when and why will shape the rest of the process.

Once everyone is in the loop, you can start to work through the next steps. Despite best efforts, there are always corners of ownership that are less clear-cut. With everyone in the loop, the hard work of figuring out the specific details can begin. Here, you’ll need to supply an expected timeline for the transition is important to frame how much time and effort can be spent on diving deep into those fuzzier areas of ownership. This is also when broader communications to peer teams or stakeholders should be planned.

The last piece of the plan is considering the reorg’s duration. For a small, evolutionary change, hopefully, all the dust settles in a few weeks. If you’re restructuring a 200-person organization, it could take a year or more. Knowing this helps you set realistic expectations and communicate them to the right internal/external groups. It also helps you keep an eye on the long tail of cleanup so that it doesn’t languish in perpetuity.

Final thoughts

Now that you have a new structure in mind, the right people pegged to the right teams, and a strong plan on how to both communicate about and execute on the plan, it’s time to put those wheels in motion. There are a thousand things that can still go sideways at this point, but putting in all this work upfront makes it far less likely that those issues will arise. And on the off chance that they do, you’ll be prepared for it.