The Reorg Survival Guide for Individual Contributors

Reorganizations are information events. The engineers who come out intact — sometimes ahead — are the ones who treat them that way instead of waiting for politics to settle or gossip to become org chart.

I've been through four reorgs in five years as an IC, then staff, then CTO. This is the playbook I give engineers on my team when the announcement lands.

First 72 hours: gather signal, don't commit narrative

Read the written artifact, not the Slack thread

Official memo, all-hands deck, FAQ if HR published one. Note:

• Reporting lines — who is your manager day one vs day 90 (transitions often phased)
• Mission statements per new group — vague language ("synergize platform capabilities") vs concrete ("own checkout latency SLO")
• Named owners for cross-cutting systems you depend on

If your role isn't mentioned, that's data — not automatically bad, but requires a conversation.

Schedule 30 minutes with your current manager

Questions that matter:

1. "Is my scope expected to change, or only my reporting line?"
2. "Are there headcount actions attached to this reorg?" (If they can't answer, ask when they will know)
3. "Who decides priority conflicts between [team A] and [team B] post-reorg?"

Document answers in your private notes. Memory distorts during uncertainty.

Map your dependency graph

Spreadsheet, three columns:

• System/person you depend on
• System/person that depends on you
• Reorg impact (unknown / same / shifted team)

This becomes your "stakeholder reintroduction list." Reorgs break implicit contracts; explicit ones survive.

What not to do

• Don't pre-announce your departure in public channels unless decided
• Don't lobby loudly for titles in the first week — visibility yes, title negotiation week three
• Don't assume the worst interpretation of every rumor — fatigue drives bad decisions
• Don't stop shipping to "wait for clarity" — delivery is evidence of value during ambiguity

Weeks 2–4: reposition with evidence

Write a one-page scope doc

Not a promotion case — a clarity artifact:

• What you own today (systems, metrics, on-call rotations)
• What was ambiguous before reorg
• Proposed ownership post-reorg (your recommendation)

Share with new manager and one skip-level if appropriate. Templated from staff engineer scope transition notes.

Reintroduce yourself to new stakeholders

Short message: "I maintain X, last quarter shipped Y, on-call for Z. Here's the runbook link." Not a resume — a handshake packet.

Engineers who do this get pulled into planning early. Engineers who wait get scoped by strangers.

Identify the vacuum

Reorgs leave gaps — monitoring nobody owns, docs orphaned, roadmaps with no author. Volunteer for one gap aligned with your strengths, not three. Becoming indispensable without becoming a dumping ground is the balance.

Frame as time-boxed: "I can own RFC process for service X through Q2 transition."

Political vs informational — practical split

Politics exists. You don't ignore it. But information arbitrage beats alliance-building in week one:

• Attend office hours new leadership hosts
• Read every RFC from new sibling teams
• Ask staff engineers in adjacent groups "what's broken that nobody owns?"

Political capital comes from being useful during confusion, not from picking winners early.

When to escalate concern

Green flags: named priorities, retained on-call rotations, manager 1:1 within week one.

Yellow flags: duplicate teams chartered for same mission, "we'll figure out ownership later" on tier-1 services.

Red flags: your manager gone with no replacement named, mandatory "alignment" meetings replacing delivery for 4+ weeks, headcount freeze paired with doubled scope.

Red flags → update resume quietly, talk to trusted mentors outside company, ask direct questions in writing (email creates record).

Technical debt framing helps

Reorgs often trigger "pause refactors." Use technical debt balance sheet language with new leadership: "This service costs $X/month incident load; reorg is good time to fund Y weeks paydown." Ties survival to business outcome, not nostalgia for old team name.

Personal outcomes from last reorg

• Engineer A: same code, new manager, wrote scope doc → became tech lead of merged platform team
• Engineer B: ignored reorg, kept head down → duplicated work with sibling team for two quarters
• Engineer C: assumed layoff, interviewed externally, left before learning scope expanded — regretted timing

Information beats rumor. Documented scope beats implied loyalty.

Manager transition checklist (for ICs)

When your manager changes in a reorg — common — run this in week one:

1. 30-min intro: your scope doc, current commitments, on-call schedule
2. Ask their success metrics for the new org — align or surface mismatch early
3. Share risk register: what you're worried about (tech debt, bus factor, vendor renewal)
4. Don't trash previous leadership — new manager hears everything

If new manager is external hire, they need your institutional knowledge more than you need their approval in week one. Be the guide, not the gatekeeper.

Timeline expectations

Reorgs stabilize in 90–120 days in my experience. First 30 days: noise. Days 30–60: scope fights. Days 60–90: new norms. Planning career moves before day 60 is premature unless red flags are clear.

What I'd tell past-self

1. Reorgs reset trust networks, not necessarily value. Rebuild connections fast.
2. Ask "what decisions can I make without waiting?" and make them.
3. If after 30 days scope is still undefined, that's a manager problem — escalate politely with written summary.

You cannot control the org chart. You can control clarity of what you own, who depends on you, and what evidence you produce while others are still reacting.