Managing Through Reorganizations

I still remember the conversation. It was a Thursday afternoon, after a team onsite, and someone walked up to me: "Hey, is it true that someone new is taking over our team?"

I'd told them. Or at least, I thought I had. A few weeks earlier, I'd mentioned in a team meeting that I was hiring a manager to take over the team—let's call him David—so I could focus on the other groups I was responsible for. I'd framed it as good news: they'd get dedicated attention, someone fully focused on their growth and their projects. I thought the message had landed.

It hadn't. What I'd communicated was that something was happening. What I'd failed to communicate was when, and who, and what it would actually mean for each of them. So now my engineer was sitting at her desk, piecing together fragments of information, wondering if she was about to report to a stranger she'd never met.

She was. But the anxiety she felt wasn't because the change was bad—it was because I'd left too much ambiguity for too long.

The transition itself was fine—necessary, even. I'd been stretched too thin, and the team deserved a manager who could focus on them fully. David was a good hire. What I'd failed to do was communicate with enough specificity and urgency. I'd let weeks pass between "here's what's coming" and "here's exactly what this means for you." In that gap, anxiety filled the vacuum.

The Danger Zone

There's a window between when a reorg is decided and when it's announced. Call it the danger zone. Every day you spend in that window is a day where the wrong person might hear something, where speculation might start spreading, where your best engineer might start updating their resume because they assume the worst.

I've gotten better at this over the years, mostly through making mistakes. The lesson that stuck: once leadership has committed to a change, your job is to communicate it as quickly as possible while still being thoughtful. Speed and thoughtfulness aren't opposites—they require each other. Rushing without preparation leads to confused, inconsistent messaging. Preparing endlessly without urgency leads to rumors and anxiety.

First Conversations, Then Everything Else

The most important principle I've learned: the people most affected hear first, and they hear directly from you, not in a group setting.

This sounds obvious, but I've seen managers get it wrong repeatedly. They'll schedule a team meeting to announce changes, figuring it's more efficient to tell everyone at once. The problem is that the person whose job is changing dramatically is sitting in the same room as the person whose job isn't changing at all, and they're both hearing this information for the first time together. One of them needs space to react. The other is wondering why this meeting is happening.

The sequence matters. The person changing teams hears from you in a one-on-one before anyone else knows. Then, if they're getting a new manager, that new manager needs to be briefed so they can follow up. Then adjacent team members who'll be affected by the change. Then stakeholders. Then the broader org.

This is tedious. It means scheduling a lot of conversations in a compressed window. It means you'll repeat yourself many times. It means some conversations will run long because someone needs to process, and your whole schedule will shift. Do it anyway.

The Narrative Problem

Before any of those conversations happen, you need to be clear on why. Not the org-chart logic of why — you can probably explain that already. The human why. Why this matters for the company. Why it's the right thing for the team. Why the person you're talking to should believe this was a thoughtful decision and not arbitrary reshuffling.

Most managers I've observed, including past versions of myself, underinvest in the narrative. They think the reasoning is self-evident. Isn't it obvious that we need to consolidate these two teams? Isn't it clear that having one person own this area makes more sense than two?

It's not obvious. Not to the person whose world is changing. They're going to have questions you haven't anticipated, and some of those questions will really be asking something else. "Will I still get to work on the mobile app?" might mean "Am I being punished for something?" "Who's my new manager?" might mean "Did my old manager not want me anymore?"

I draft my core message before I start any conversations. Not a script—I'm not reading from a teleprompter—but a clear articulation of the why, the what, and the what's next. I pressure test it with someone I trust, usually my own manager and a trusted peer who's been through similar situations. They'll ask the question I forgot to anticipate. They'll tell me if my "why" sounds like corporate speak instead of a genuine reason.

The Conversations Themselves

When I sit down with someone whose role is changing significantly, I lead with the news. Not with preamble, not with "So, as you know, the company has been going through a lot of changes lately..." Just the information they need to hear.

"I want to let you know that we're making some changes to the team structure. Starting next month, you'll be moving to the Developer Experience team, reporting to Marcus."

Then I pause. Let them react. Sometimes there's relief, sometimes disappointment, sometimes a blank stare while they process. This is their moment, not mine.

After they've had a chance to respond, I explain the why. Not defensively, not with a dozen justifications, but clearly. Why this makes sense for the organization. What I think is good about it for them specifically—and I only say this if I believe it. If I think this change is neutral or even bad for them but necessary for the company, I'll acknowledge that too. People can smell inauthenticity, and pretending a lateral move is a promotion insults their intelligence.

I leave time for questions. Not five minutes at the end of a thirty-minute slot—real time, where they can think out loud and I can respond. Some questions will have clear answers. Some won't. "I don't know yet, but here's when we'll have more clarity" is a valid response. "I'm not sure, but I'll find out" is too, as long as you actually follow up.

At the end, I'm explicit about confidentiality. Can they tell their teammates? When will the broader announcement happen? What should they do if someone asks them directly? Leaving this ambiguous just creates more anxiety.

What Comes After

The announcement isn't the end. It's not even the middle. The weeks following a reorg are when you find out if your communication actually worked.

I schedule follow-up conversations with everyone whose role changed significantly, usually within three to five days of the initial announcement. Not to check if they're "okay with it"—that's a loaded question—but to see how they're settling in, what questions have come up, what isn't working that I couldn't have predicted.

I watch for signals that the message didn't land. Is there confusion about reporting lines? Are people unclear about their new scope? Is someone who seemed fine in our one-on-one now visibly disengaged? These are all signs that I missed something or that the reality of the change is different from how I described it.

I've come to believe that how you communicate a reorg matters almost as much as the reorg itself. A well-designed org structure with terrible communication will breed resentment and attrition. A merely decent org structure with excellent communication will build trust.

People remember how they were treated during transitions. They remember if they heard the news from you or through gossip. They remember if you gave them space to react or rushed through to make your next meeting. They remember if you followed up or forgot about them once the announcement was done.

The transition I mentioned at the beginning—the one where my engineer spent weeks in uncertainty because I'd been vague about the details—turned out fine. Better than fine, actually. Once David started and I had proper one-on-ones with everyone to explain what the change meant for them specifically, things settled. That engineer stayed another two years and became one of the strongest contributors on the team. But I got lucky. The outcome was good despite my communication, not because of it. I think about how easily it could have gone the other way—how a few more weeks of ambiguity, or a slightly less patient person, might have meant losing someone great over something entirely preventable.

I think about her whenever I'm planning org changes now. Not as a guilt trip, but as a reminder: the execution of communication is the execution that matters most.

The org chart is just boxes and lines. The conversations are what's real.