Reorganizations (reorgs) are necessary pivots in how an organization invests its people and resources. Reorgs are a necessary evil in the world of engineering. They’re tough, messy, and bound to piss people off.

If done right, reorgs keep company priorities and investments aligned. If done wrong, you can end up in a worse state than when you began.

According to a McKinsey survey in Harvard Business Review, over 80% of reorganizations don’t deliver the expected value on time, and 10% cause more harm than good.

I’ve been through my fair share of reorgs, and I’m here to share what works, what doesn’t, and how to come out the other side without losing your mind.

What happens in a standard reorganization? At a high level it means 👇

• Problems are identified that a reorg might fix.
• You justify the reorg by demonstrating how it should fix said problems.
• You plan, communicate, and execute the reorg.
• You land the reorg over time and learn from it.

Making organizational changes shouldn’t be done lightly. They can dramatically impact peoples’ careers, happiness, and work productivity. Executive teams can prevent unnecessary reorgs by asking:

• How do we know this reorg will solve, or assist with the issue at hand? Make sure you have a damn good reason before you reorg. And if you don’t have clear, justifiable reasons for a reorg, don’t even think about it. The disruption you’ll cause isn’t worth it unless there’s a real payoff.
• Are we using this reorg to hide people and/or leadership problems? If your leaders or managers suck, rearranging the org chart won’t magically turn them into rock stars. My advice is to deal with it. If there is a skill, attitude, and/or relationship issue, it should be worked through.
• What is our ability to land this reorg well, and what major risks are there? Reorgs are heavily scrutinized, and are often going to have a negative impact on your people for a time. While some of this friction is inevitable, it at least should be discussed and planned for.
• What happens if we wait? Maybe a reorg does need to happen. But what is the impact of doing it now versus later? Are there any benefits to waiting, like lessening fatigue? Would waiting potentially change our perspective? Could or should this be rolled out with other changes?

Prior to Planning your Reorg

A reorg is like using a sledgehammer to solve a problem. It might be the right tool, but it’s costly if you get it wrong. To mitigate that issue, here’s what you should do before you agree on a reorg.

📌 Identify the problems this reorg should address

Reorganizations aren’t just about shuffling people around. They’re about addressing big issues and realigning your team with strategic goals. That said, here are reasons a reorg can be necessary:

• Aligning investments to company priorities/needs: As company priorities change, so should how your people are spending their time. Does how your people are allocated across work reflect company priorities appropriately? Maybe your organization recently refreshed its company-wide priorities. Or a market change means you need to reorg to capture potential value.
• Addressing structural issues: Maybe there are issues with how you distribute scope across your organization, and people don’t have enough high-scope/impact opportunities. Or you’re having ongoing issues with staffing on call or incident response.
• Layoffs/Downsizing: It is ugly but it happens plenty. Sometimes you need to reorg to redistribute people and responsibilities after a layoff.
• Correcting seniority/grade distribution issues: Over time, your seniority distribution can become off. One team might have almost all Senior+ talent, while other teams need that guidance.

🎯 Justify your Reorg

To avoid unnecessary reorgs, create a process that requires leaders to justify their reorgs. The might involve documenting:

• The problems and how you expect the reorg to address them.
• A high-level proposed new structure that demonstrably aligns with the goals of the reorg.
• What success would look like with this new structure and why that is desirable.
• The major risks of the reorg + new structure, and how you’ll mitigate those risks.

Take that draft and gather feedback from those in the loop, and adapt as needed. Allow for meaningful debate + pivots, especially with the problems to address and the proposed new structure.

​​🙋 Common reorganization challenges

Before you begin planning your reorg, keep in mind common pitfalls:

• Communication that should have been more thorough/clear, coordinated, and/or thoughtful.
• Access issues, automated email mistakes, or other notification issues.
• Friction from people joining new teams, with new expectations, processes/habits, etc.
• Poor people placement and/or fit that could have been mitigated/prevented.

Planning a Reorganization

Once a decision is made to proceed with the reorg, there are a number of steps to take.

👥 Planning + Documenting Your Future State

• Draft a new organizational structure or guidance that supports your goals, including:
  • A list of all the new M1 teams, and their major areas of responsibilities/functions.
  • Each team should have a documented purpose, goal, or something similar.
  • The proposed headcount by team, and why that specific headcount.
  • The proposed manager of each team.
  • Any critical unique (compared to the broader org) skills that team/area needs.
• Draft a before and after organizational chart.
• Identify if any job descriptions need creating/updating.
• Have a list (via excel, google sheets, etc) of all impacted employees, including manager and title changes. You will need this for drafting reorg comms, as well as (likely) working with HR/IT.

👥 Decide how you will move people

There are several ways to move people, often involving a mix of these methods:

• Directed Moves: Top-down decisions. Quick and dirty. This is when leadership points at someone and says “you are moving here.” This might be because a specific person is needed in an area, or because someone had to be picked and they got the “lucky straw.”
• Team Matching and/or Yellow Sticky exercises: Team members participate in a matching exercise to document + consider preferences. Leaders still direct the moves, but (most) decisions are driven by preferences.
• Stays: Identify the untouchables who stay put due to specific experience or critical needs.

Maximize Yellow Sticky exercises where possible. Empowering people and giving them choices leads to better outcomes. When directed moves or stays are necessary, consider the impact on individuals. Someone might be perceived as critical, but what if that choice pushes them to leave?

When moving people, it is critical to partner well with other departments. This is to make sure a smooth administrative process happens behind the scenes. Usually this looks like working with HR (or People Systems) and your IT department.

What can happen if you don’t work well with those departments?

• Pay and/or compensation issues that can be difficult to unwind.
• Automated notifications can be sent out at the wrong time (and that can mean early).
• It can take a few days for access issues to be resolved, frustrating employees during an already vulnerable time.
• Lots of small embarrassing issues that can make you look unorganized and uncaring.

I’ve generally solved this by making sure one overall person is responsible for coordinating with HR/IT during the reorg, and they farm out work as needed.

🎙️ Create your Communications Plan

Communication is your lifeline in a reorg. Nail it, and you keep the ship steady. Screw it up, and you’re drowning in pissed off people. Here’s how to get it right.

Decide on your communications plan, for example how will you:

• Explain the why: Lay it out. Why are we doing this? Your team needs to know the real reasons behind the reorg. No fluff, just facts. Clear, straightforward, and honest​ while compassionate.
• Land reorg messaging + get feedback: Don’t just talk, listen. Schedule events where employees can ask questions and provide feedback through AMAs, manager/leader round tables, town halls, and surveys.
• Handle sensitive changes compassionately: Big role changes can suck, so handle them with care. Inevitably someone gets a manager, team, AOR, or something they don’t want. Consider how you will handle those, and how to be compassionate while still making the hard/right choices.
• Communicate mistakes + lessons learned: Putting on paper what went right, what went wrong, and how you will learn will help keep an environment of trust with your team. While part of the lessons learned might need to stay confidential, my own experience is that maximizing what you can be transparent with is received well by people.

Consider if + how you should:

• Centralize your communications coordination: Identify the different groups who will need communication and the different messages/information they will need. Make sure people have time to review and refine any drafted comms.
• Update executive leadership post-reorg: What information is leadership expected post-reorg? What is your plan for collecting and getting them that information?
• Notify outside departments/areas: Is there a separate way you need to communicate to outside departments (or external partners/people) about the reorg?

✅ After your reorganization

Pulling off a reorg is one thing. Sticking the landing is another. Here’s how to make sure the changes actually work:

• Refine your success criteria: After the reorg, you’re going to need to re-tune your success metrics based on real-world feedback and on-the-ground learnings. Set realistic expectations that these will change/evolve, and be ready to adjust your plans as you go.
• Lessons learned: Reflect on what went right and what went sideways. Host a post-mortem to capture insights and make sure you don’t repeat the same mistakes next time. Be brutally honest and create practices to document this feedback.
• Determine training needs and resources: Post-reorg, some folks might need new skills or resources. Identify these needs quickly and make sure everyone gets the support they need. This might look like investing in introducing them to their new code base, significant amounts of pair programming initially, etc.
• Invest in team building: When teams shuffle, productivity can take a hit. Even in the best of cases. Help new team members integrate by investing in team-building activities. Plan events, offsites, or even casual get-togethers to help everyone click.
• Seek out opportunities to mediate and/or resolve disputes: Be the glue that holds it all together. Address minor disputes and foster a collaborative atmosphere. It’s about creating a cohesive, productive team in the new structure.
• Identify where white glove communications/service would be impactful: With the impacted individuals consider where additional conversations, skip 1:1s, meetups/lunches, or other types of “white glove communications/service” would be helped.