How to make reorgs less terrible

Changing your organizational or team structure is a tricky thing to do – so much so, that some organizational structures optimize for staying together at all costs.

In the times I’ve restructured teams, it has often gone badly, and very rarely has the change been smooth. A few lessons I’ve learned now live in a notes folder to remind me of all the steps to take to make things less terrible.

Reorganizing your structure shouldn’t be done too often, or thoughtlessly, but it is something well-run businesses evaluate because it’s important to maintain a mapping where your team structure reflects your business needs, your architecture reflects your business needs, and your team structure reflects your architecture (essentially, a three-way Conway mapping). Business needs, technical possibilities, and team makeup are evolving, so most companies will find occasions where they are lacking alignment in these areas and need to rethink team structure.

Reorgs will always be disruptive because there is no way to completely avoid going through Tuckman’s four stages of team formation. Harvard Business Review found that ‘reorgs – and the uncertainty they provoke about the future – can cause greater stress and anxiety than layoffs, leading in about 60% of cases to noticeably reduced productivity’. Productivity also decreases as soon as a reorg is announced because people start to gossip, speculate, and become distracted. TinyPulse found that employee ‘happiness’ scores dropped by 10% after reorgs, and attitudes toward ‘professional growth opportunities’ fell by 12%.If the process is handled badly, teammates become cynical, lose trust in management, and company performance suffers.

This doesn’t have to be the case: giving thought and care to how you approach a reorg can improve outcomes and avoid the most negative consequences.

Reorgs trigger our core needs

People generally don’t like change. Reading Lara Hogan’s classic Desk Moves article was the first time I learned about the surprising ways people react to even the smallest restructure. When viewed through Paloma Medina’s BICEPS framework of human needs, it makes a lot more sense why exactly restructuring is so stressful.This framework outlines six core human needs at work that can be triggered by a reorg.

• Belonging. There is a sense of team, of place, with your group of colleagues. Shuffle this around and you lose that cozy feeling – which is a big deal to our hyper-social species. We have evolved to evaluate social isolation as an existential threat. Our brains require social connection to function properly, so any threat to that tends to trigger a response.
• Improvement/Progress. Many Agile models rely on a consistent team iterating on workflows across a long period of time. 
• Choice. People rarely choose where they land in a reorg. 
• Equality/Fairness. Why me? Why this team? How is this fair? (These are all questions I have been asked during past reorgs.)
• Predictability. Change is inherently unpredictable – doubly so for a surprise reorg.
• Significance. Did you end up on the ‘cool team’? Or something perceived as ‘non-mission-critical’?

Reducing triggers

The BICEPS framework works to understand why reorgs are so awful, but it also helps to reduce the impact of changes on those needs.

Belonging

Since belonging is so deeply affected, I like to start here in two ways. Firstly, as ongoing advice: ensure that being in a work team is not the only way your engineers experience belonging at work. Connect people across the organization with mentor relationships, engineering-only teams, or ‘guilds’ (for example, you might have an interest group for front-end performance, or accessibility). Doing this helps your org become more resilient to changes in general.

Now, changing the core day-to-day teams will still disrupt belonging, so, try to plan for the reorgs to change as few individuals as possible. Instead of blowing up your org chart and starting from scratch, try an iterative approach and keep current teams together where you can. If you can achieve your goals by only moving a few individuals, it will be far less painful and disruptive. This is a big reason many organizations choose to have ongoing groups in the first place, and why so many tech processes are tuned for continuous teams rather than a projectized org structure.

Improvement/Progress

People need to feel that they, and their colleagues, are improving, so appealing to the growth opportunities of the new team can be a good way to get your engineers on side. This works especially well when done on a 1:1 basis, where you can appeal to a colleague to provide the newly-formed team with leadership and guidance. And yes, leadership happens at all levels! Anyone on your team who really cares about improvement might jump at this chance.

Choice

If at all possible, give people a choice. One way to do this is to outline the new teams being formed, and ask people to share their preferences with you – which you can then take into account (and do your best to meet). Another way is to ask people on a more case-by-case basis which option they’d prefer. Be warned: this must be a real choice, not a ‘choice’ you have orchestrated where there is a right and a wrong response. If there really is only one way to structure that meets the goals, then asking people to choose yet ignoring their wishes when they choose ‘wrong’ will add a second trigger onto the first. It could lead to upset at having no choice over the restructure happening, and upset over their choices about how it happened being ignored. So be careful: offer as many options as you genuinely can, and no more.

Equality/Fairness

Be prepared to explain how decisions were made and outline the process. If you didn’t make these decisions yourself, work with your manager on talking points, and be prepared to speak to the ‘why’ and ‘how’ of the restructure. It’s possible that people will simply feel the change is unfair, and so be prepared to acknowledge and hold space for those feelings. It can be tempting to argue someone into agreeing with you, especially if you personally feel that the system is fair, but emotions don’t always respond to argument, and fairness is in the eye of the beholder. If the changes are perceived as unfair, getting frustrated and arguing back is the worst thing you can do. Apologize, accept the penalty, and help your team to move on by focusing on the task at hand and the goal of the reorg.

I’ve noticed that complaints of unfairness can be especially hard to handle for managers whose own BICEPS core need is equality/fairness. If this is you (or your manager report), you’ll need to do extra work on processing your own emotions separately to your team, and be aware of getting sucked into a toxic venting session as a participant. Holding space means hearing, acknowledging, and then setting boundaries like, ‘I don’t think discussing this further is going to be productive’, or, ‘I’m sorry you feel that way. I can’t change what has happened, so we need to find a way to move on’.

Predictability

Reorgs cut to the heart of this need, too. The best way to reduce this trigger is to give people plenty of warning. As much as you can, avoid surprises. You’ll need to cover the following:

• The fact a restructure is happening; 
• What the goals, strategy, and direction of this decision are meant to achieve;
• When it will happen;
• What challenges teams will need to face. For example, talk about the stages of team formation, and how they will happen.

When people have a good sense of what’s happening and why ahead of time, the whole process feels much more predictable. This can be somewhat at odds with ‘choice’ if you’re wanting to give people options around what team they can choose to be a part of, but it is possible to explain much of the process and timing in great detail while still leaving some options open.

Significance 

This need will be triggered when someone moves from a role they feel is important, strategic, highly visible, or otherwise increasing in status, to something less important, strategic, or visible. This is a relative, subjective experience in many cases. For example, a product engineer moving to a payments team may feel that they are now not as visible or highly profitable as they are no longer a builder of the big splashy launches. A payments team engineer moving to a product team might feel they have gone from being entrusted with core functionality that’s critical to the business, to tinkering with trivial features that don’t matter as much. In this ‘swap’ scenario, both people feel that their old job was of a higher status.

A good way around this is to understand the significance of every team and opportunity, and share why they are equally high-profile, important, and critical. Having goals in place before teams form can help to feel that the new team ‘matters’ and has something tangible to achieve.

Reorgs: a how-to guide and timeline

There’s a lot to communicate and navigate to ensure you’re meeting as many core BICEPS needs as possible. As a handy ‘cheat sheet’, here’s a reorg timeline with suggestions of what to do at each stage, and what corresponding need is being met. If you’re looking to address a specific need (choice, predictability, etc.), this can be used as a reference too.

Is there a way to avoid reorgs totally?

Yes, there is a way to avoid changing your team structure, by matching up continually changing objectives and business needs to consistent, unchanging groups of people. However, this has its own tradeoffs.

For example, you have a team called the ‘Squirrels’ and a team called the ‘Badgers’ and you could assign new objectives and goals each planning cycle to these groups. The ‘Squirrels’ and the ‘Badgers’ stay together throughout and tackle whatever comes up – maybe it’s payments this time, onboarding next time, then feature work, and so on.

This structure meets the criteria of keeping teams of people together, and it maintains the mapping between team structure and business needs. However, the tradeoff is that it continuously violates the third mapping: team structure matching technical architecture, or areas of code ownership.

The short-term impact is that teams are often working on unfamiliar code, so they work slower as they gain context. The long-term impact is that without a deeper understanding of how to maintain and evolve architecture, the incentive is for small hacks or workarounds to pile up, and for even the cleanest code to become directionless. Technical debt, by which I mean the cost of adding a new feature to an existing product, rises over time.

Since these teams map only to business needs and are often less productive in both the short and long-term, it’s well worth learning to do your (inevitable) reorgs well.

Conclusion

Reorgs are notoriously disruptive because changes to the social structures at work cut deep into the mammalian brain and trigger core emotional needs. Regardless of how well thought out and rational the new org structure is, urgent and turbulent emotions disrupt and hijack even the best-laid plans. Thoughtful leaders can avoid this amygdalas-run-amok situation by providing for the needs of belonging, improvement, choice, equality, predictability, and significance, by following these communication and rollout suggestions. In doing so, reorgs can be made so much less terrible.