In the years at the European financial technology firm, the engineering organisation went through three significant restructuring events: a change in engineering leadership, a shift from functional to product-aligned teams, and a consolidation of two separate engineering groups. Each one produced the same kind of disruption and the same kind of opportunities.
Org change is uncomfortable. It’s also underanalysed. Most engineers treat it as something happening to them, not something to navigate actively.
What Actually Changes in a Reorg
The first instinct is to focus on reporting lines and team names. These matter less than engineers assume.
What usually stays the same: the actual work (the code doesn’t know there was a reorg), the technical problems that need solving, the informal relationships that were productive.
What actually changes: decision authority (who can approve what), information flows (who knows what first), career path (who evaluates your performance), and priority setting (whose opinion shapes what gets worked on).
Understanding what changed in these four dimensions is more useful than understanding the org chart. The org chart is a proxy for these things, but a lossy one.
After the shift from functional to product-aligned teams at the firm, my reporting line moved. But more importantly: I now had direct input into product prioritisation, whereas before I’d been downstream of product decisions made by another team. That change in decision authority was significant. The reporting line change was incidental.
The First 30 Days After a Reorg
The 30 days immediately after an organisational change are unusually high-leverage. People are in a state of heightened attention. New norms are being established. Informal networks are being rewired. Decisions made in this window tend to stick.
What to do in the first 30 days:
Understand the new decision structure. Who approves headcount? Who sets technical direction? Who decides what gets prioritised? These aren’t always obvious from the org chart. Ask directly, or observe carefully.
Find the new information flows. Which meetings matter now? Who gets CC’d on what? Where are decisions being made? This is important especially if you were previously in the information flow and might have been moved out of it.
Establish relationships with new stakeholders. If you now have a new manager, a new product counterpart, or a new peer team, invest early in those relationships. The defaults established now will persist.
Be careful about your public response. Engineers who signal strong opposition to the change early tend to be marginalised regardless of whether their opposition is correct. This isn’t about supressing legitimate concerns — it’s about channel selection. Quiet, specific, direct feedback to new leadership is far more effective than public skepticism in all-hands Q&A.
The Technical Work Doesn’t Wait
The most common mistake I’ve seen engineers make during reorgs: stop doing good technical work while they wait for the situation to clarify.
Reorgs create ambiguity about priorities, but the core technical work rarely disappears entirely. The service still needs to be reliable. The bugs still need to be fixed. The architecture still needs to evolve.
Engineers who keep shipping during the disruption tend to come out of reorgs in better positions than engineers who waited for clarity. The work becomes evidence of value at a time when it’s being re-evaluated.
The corollary: don’t over-invest in political positioning at the expense of the work. Some political navigation is necessary, but it’s a second-order effect compared to being someone who reliably does good work.
When the Change Is Bad
Sometimes the organisational change is genuinely bad — it disrupts productive collaborations, removes engineering agency, or signals a strategic direction you disagree with.
The useful question is not “is this bad?” (you’ve already decided it is) but “is this reversibly bad or irreversibly bad?”
Reversibly bad: the new team structure is awkward but the technical work is still interesting and the overall direction is sound. Typical advice: stay, provide feedback, give it 6 months to settle. Reorgs often look worse at the beginning than they end up.
Irreversibly bad: the change reflects a fundamental shift in what the company values — from engineering-led to sales-led, from technical quality to feature velocity at any cost. This is harder to wait out. If the new direction represents something you genuinely can’t work within, the honest answer is to start looking.
The tell that distinguishes the two: how leadership responds to direct, private feedback. A leadership team that listens, acknowledges tradeoffs, and explains the reasoning (even if you disagree with it) is navigable. A leadership team that responds defensively to legitimate concerns, or that wasn’t considering the engineering impact at all, is a worse signal.
What I’d Do Differently
In the first major reorg I navigated, I made two mistakes: I waited too long to establish a direct relationship with the new engineering leader, and I was too public about concerns that would have been better raised privately.
The first mistake cost me several months of ambiguity about priorities that a direct conversation would have resolved quickly. The new engineering leader didn’t know my opinions on the technical direction; I didn’t know theirs. The information gap persisted until someone arranged an intro.
The second mistake wasn’t costly, but it was wasteful. My concerns were legitimate, and the public forum where I raised them wasn’t the place where the decision would be made. The time and political capital spent would have been better used differently.
The underlying lesson: organisational navigation is communication. The same skills that make for good technical communication — clarity, specificity, choosing the right audience, listening more than talking — make for good organisational navigation.
Reorgs are unsettling because they change the context in which you work without changing the fundamental nature of the work. The engineers who navigate them well don’t do so by being unusually political or unusually passive. They stay oriented to the actual work, invest quickly in new relationships, and channel feedback effectively. That’s it.