|
 |
The word “reorg” makes people flinch. It smells like bureaucracy, PowerPoint slides, and nowadays sometimes raises the idea of layoffs (which are downright scary). But the best teams I’ve worked on have treated reorgs not as a theoretical “moving boxes in an org chart” exercise, but as a way to set up a team for success.
A good org setup makes it clear what problems we need to tackle and sets people up to own important problems. Like anything that affects people’s work, reorgs are sensitive. If they’re done carelessly, they create confusion and fear. But if they’re done well, they can help teams respond to changes in the market, let people on a team grow faster, and set a team up to build long-term. And they’re a normal part of work today, so it’s helped to have a system to think about them.
Here’s what I’ve learned from my share of reorgs.
Decide which problem we’re solving (and therefore which ones we’ll compromise on). Every reorg can only optimize for a handful of constraints, like:
customer: carving out a slice of the full stack (front-end, back-end, ops) to focus specifically on enterprise customers.
technology: combining all front-end teams to move faster on a single tech stack.
product: unifying all the teams needed to make a videoconferencing product take off.
leader: expanding scope for a high-trajectory leader who’s ready to take on bigger challenges
When we optimize for one of these axes, we’re probably going to compromise on the others. If I’m prioritizing a specific product like videoconferencing, it’ll be harder to build the complete solutions enterprise customers need. And a vertical-first org focused on enterprise customers might slow down overall tech platform investments, which will limit us long-term. So we need to make sure up front that the cost of the reorg — the churn of people getting used to their new structure, the change management work to get it done, and the ongoing risk of the compromises — is worth it.
Provide clear direction. It can feel generous to ask people to “choose” their next team — after all, who doesn’t love a choice? But when I’m asking people to change roles, I want them to know I've thought carefully about why this works for them and the broader team. If they disagree, we’ll talk about why — but they should know the full picture and their best place in it, and should be assured that we’re not making changes casually.
Sequence matters. How and when people find out affects how they feel. People should hear either 1:1 from their manager or in a broader team setting, in order of who’s the most impacted.
First, the small # of people who have choices between different roles (often managers of the new teams). Their decisions will inform other parts of the reorg.
Then the people whose manager or scope is changing should hear 1:1 from their manager. If someone’s manager is changing, they should then talk with the new manager immediately.
Finally, everyone else — people whose job and manager stay the same, cross-functional teams, or the broader company. Each team can hear the updates together in a large meeting or email. That way everyone knows that they all have complete information.
Redraft messaging with fresh eyes before communicating it broadly. Inside a reorg, decision-making can get messy. But all my team will see is the final structure and how it will serve them. I need to let go of any baggage from the process and focus on the outcome — how this new structure helps them win.
Speed matters. If we’ve decided as a leadership team to pursue a reorg, we need to prioritize it and get it done. The longer it drags on, the higher the chance it’ll leak. Rumors don’t help anyone.
Manage a reorg like a product launch. Reorgs have a real impact on how we’re going to ship for our customers, so we need to give them the same rigor and respect. My reorg docs look like product launch docs, and generally include:
Goal of the reorg, including known compromises / tradeoffs
Outline of the org chart & updated charter of each team
Any structure or leadership choices that still need to be made
Timeline and plan for communicating with team members, including {person, new role, who’s talking with them}
Action items: people who have concerns who should talk with leadership that day or new feedback to address
Ongoing list of people who need to know, checking off when someone has been informed
Draft of announcement to be shared about the full reorg
For a large reorg, I hold a daily standup with key leaders to check in on progress, and have a daily block on managers’ calendars so they can address any concerns with their teams immediately.
Listen and iterate. The job isn’t done when the reorg announcement goes out. We need to keep checking in with people and hear how they’re feeling, and if there’s any immediate finessing or information-sharing that needs to happen. What we work on and who we work are so core that there are always hiccups while everyone figures it out.
Reorgs will never be fun. They require people to change their routines, their relationships, and can even impact their sense of belonging. But if they’re done respectfully, they can also clear away noise and help teams focus on building the products our customers need for the future.
Like this post from The Hard Parts of Growth? Feel free to share!
|