The Reorg Nobody Told Your Team About

People on your team found out they were moving to a different reporting line because the org chart changed. Not because someone told them. Not because they were asked. The hierarchy shifted, and they discovered it the way you discover a calendar invite you weren’t consulted about: it was just there.

If this sounds extreme, it shouldn’t. In every large engineering organization I’ve worked in, I’ve seen some version of this. People reassigned between teams without being asked if they wanted to move. Priority shifts decided in leadership meetings and handed down as settled decisions. Budget cuts that the team learns about when the contractor seats disappear. The consistent thread: decisions that directly affect the team’s work and careers are made in rooms the team has no access to.

What information hoarding actually costs

The instinct is to frame this as a communication problem. “We need to be more transparent.” But that framing misses what’s actually happening. When teams are repeatedly excluded from decisions that affect them, they learn a specific lesson: my effort can be redirected at any time by forces I can’t see or influence. The rational response is to reduce investment. Why go deep on a technical approach if the project might get deprioritized next week without warning? Why mentor a junior engineer if they might get moved to another team tomorrow?

The cost shows up in ways that don’t look like a trust problem on the surface. Sprint velocity stays stable but innovation disappears. Estimates get padded because people are hedging against invisible risk. Nobody proposes ambitious technical approaches because ambitious approaches require stability to execute, and stability is something the team doesn’t believe they have.

This is the sneaky thing about information asymmetry. The team doesn’t revolt. They adapt. They become “professional” in a way that looks like maturity but is actually self-protection.

Why the standard fix fails

Most new managers, when they diagnose this pattern, respond with a promise: “I’ll share everything I know.” This fails for two reasons.

First, it’s usually not true. You can’t share board-level discussions or unfinalized reorg plans or your own performance review conversations. Making a sweeping transparency promise and then hitting the first exception destroys more trust than the original hoarding did, because now you’ve replicated the exact pattern: a promise that didn’t hold.

Second, the team doesn’t actually need all information. They need the information that affects their work and their careers, delivered before decisions are finalized rather than after. The distinction between “transparency” and “timely relevant information” matters. Transparency is a value. Timely relevant information is a practice.

The repair

Week 1: Map how information flows. Before you change anything, understand how decisions move through your org. Who knows about reorgs first? When do priority shifts get communicated to team leads versus individual contributors? How far in advance does the team hear about project changes versus learning about them through side effects? You can figure this out by asking two questions in your 1:1s: “When was the last time a decision surprised you?” and “How did you find out about it?”

Week 2: Define the team’s “need to know” boundary. Based on what you learned, create an explicit list of decision categories and when the team will hear about them. For example: “Reorgs affecting this team: you’ll hear from me before the org chart changes, even if I can only say ‘something is being discussed and I’ll share details as soon as I can.’ Priority shifts: you’ll hear about them in our team sync before I commit scope to product. Headcount changes: I’ll tell you when a conversation starts, not when a decision lands.”

This is more conservative than “I’ll share everything” and more credible. You’re defining a specific commitment about specific categories of information, which means the team can hold you to it.

Weeks 3-4: Demonstrate the commitment by sharing something uncomfortable. The only way to prove you mean it is to share something you’d rather not, early enough that it matters. Maybe it’s: “Leadership is discussing a potential reorg. I don’t have details yet and I don’t know if it will affect us, but I wanted you to know the conversation is happening.” Maybe it’s: “I pushed back on a priority change that came down from product. Here’s what they wanted, here’s why I disagreed, and here’s the compromise we landed on.”

The content matters less than the timing. If the team learns about something from you before they learn about it from the org chart, from Slack rumors, or from their cross-functional partners, you’ve demonstrated the change. Once is a gesture. Twice is a pattern. Three times is the new operating model.

The structural fix: decision logs

One mechanism I’d strongly consider implementing is a lightweight decision log shared with the team. Not a formal ADR process. Just a running document that captures: what was decided, when, by whom, and why. Include decisions you disagreed with and lost.

This serves two purposes. It gives the team a window into the decision flow they’ve been excluded from. And it creates accountability for you, because if a decision is made that affects the team and it’s not in the log, they’ll notice. The log makes information sharing a system, not a personality trait. When you eventually move on to your next role, the system persists even if your successor has different instincts about transparency.

This framework assumes information hoarding is organizational habit, not deliberate gatekeeping. In regulated industries, there are legitimate compliance reasons why certain information can’t be shared early. The additional responsibility in those environments: teach the team which information boundaries are policy versus which are laziness. Conflating the two is how legitimate constraints become cover for avoidable opacity.

This is Part 3 of a series on trust repair for engineering managers. Part 4 covers the third pattern: when the people doing the work aren’t the ones getting the credit. Do you distinguish between “transparency” and “timely relevant information” in how you communicate with your team, or do you treat them as the same thing?