Reorgs happen

In thirteen years at GitHub, I was part of 25 reorgs and reported to 13 different managers. That’s a new org chart roughly every six months and a new boss roughly every year—like clockwork.¹

I know these numbers because I tracked them. What started as a humble spreadsheet eventually metastasized—as my side projects tend to do—into a full statistical forecast model that predicted the date of my next reorg with confidence intervals.² When colleagues asked how I stayed so calm during shake-ups, the honest answer was that I’d seen the data: reorgs are a disruptive fact of life in tech, and they can be a major source of stress and uncertainty. But they don’t have to be.

Why reorgs happen#

Most reorgs aren’t about you. They’re rarely malicious, and honestly, they’re rarely even that strategic. Organizations reorg because priorities shift, leaders change, headcount fluctuates, and Conway’s Law keeps asserting itself—if you want the system to change shape, the org that builds it has to change shape first.

A reorg is just an organization updating its structure to match its current understanding of the problem. Sometimes that understanding is right. Sometimes the same boxes get redrawn eighteen months later. Either way, the org chart is a snapshot of a hypothesis, not a monument. Expecting it to be permanent is the actual mistake.

Why they feel so disruptive#

If reorgs are so routine, why do they hurt? Because the costs are real and they’re personal: you lose context, you lose working relationships you spent months building, and you have to renegotiate trust with a new manager who has no idea what you shipped last quarter. Add uncertainty about priorities—is my project still funded? is my role still valued?—and it’s no wonder a Monday-morning announcement can derail a whole week.

The disruption is real. But it’s also predictable, and predictable disruption is something you can design for.

Treat reorgs as a constant, not an exception#

This is the mindset shift that changed how I experienced reorgs: stop treating them as rare disasters and start treating them as baseline operating conditions. If you’ve been in tech for any length of time, a reorg every six-ish months is the weather. You don’t get angry at rain—you buy a raincoat.

Designing your career for that reality means investing in what survives an org-chart shuffle. Keep your relationships portable—your network shouldn’t be coterminous with your reporting line, because the colleagues two teams over are your future teammates and references once the boxes get redrawn. Document your decisions somewhere durable; context that lives in one person’s head evaporates in a reorg, while context that lives at a URL survives. Working asynchronously and in the open is reorg insurance. And do work that speaks for itself, because when your manager changes every year on average, your reputation can’t hang on any single person having seen your best work. Keep the receipts.

How to navigate a reorg#

When the announcement drops (usually on a Monday—I have the data):

• Let the dust settle. The org chart announced on day one is rarely the org chart that exists a month later. Reorgs are announced at the altitude of VPs and refined at the altitude of teams. Don’t make big career decisions—or send spicy Slack messages—in week one.
• Ask the questions that actually matter. Who do I report to? What does my team own now? What changed for users? Most of the anxious speculation that follows a reorg dissolves once those three are answered. The rest is noise.
• Re-onboard yourself. A new team is a new job, even if your badge and laptop stay the same. Treat it that way: learn the team’s context before prescribing changes, go near, go far, and meet in the middle.
• Reset with your new manager deliberately. Don’t wait for them to figure you out—that’s a six-month project you can compress into one good first one-on-one. Bring your brag doc. Share how you work best, what you’re driving, and what you need from them. Thirteen managers in, I can tell you the relationship you build in the first two weeks is the relationship you’ll have.
• Keep showing your work. In moments of uncertainty, visibility matters even more. Leaders show their work, and reorgs are precisely when everyone—new manager, new skip, new peers—is trying to figure out who does what.

How to make the most of one#

Navigating a reorg is table stakes. The real opportunity is that reorgs are one of the few moments when an organization’s defaults become negotiable:

• Reorgs reset narratives. Pigeonholed into a role you’ve outgrown? Your new manager has no priors. The story of who you are professionally gets re-told every reorg—make sure you’re the one telling it.
• Renegotiate your scope. Team charters get rewritten in the first few weeks after a shuffle, and nature abhors a vacuum. Show up with a proposal for what your role should be, and more often than not, you’ll get it. Clarity is a gift to a leader who’s drowning in ambiguity.
• Shed the legacy cruft. Every team accumulates projects that persist purely through inertia. A reorg is organizational garbage collection—the rare moment you can ask “should we still be doing this?” and have “no” be an acceptable answer.
• Compound your network. Every reorg deals you a new hand of colleagues, stakeholders, and adjacent teams. Thirteen years of shuffles meant I’d worked with—or near—half the company. That network outlasted every org chart that created it.
• Be the calm one. When everyone else is doom-scrolling the new org chart, the person who’s level-headed, generous with context, and helping others find their footing is doing leadership, visibly, at exactly the moment leadership is paying attention.

The long view#

Across 25 reorgs, my manager changed, my team changed, my org changed, and my VP changed—but the things that actually determined my trajectory didn’t live on the org chart at all. My reputation persisted. My relationships persisted. The work—shipped, documented, linkable—persisted.

That’s where I’d tell you to invest—not in any particular box or reporting line, but in the things no reorg can take from you. Get those right, and a reorg stops being a crisis and becomes what it actually is: a Monday.

The model’s parting gift was one final forecast: another reorg by early September, probably announced on a Monday. I have complete faith it will deliver. After all, look at the methodology:

Generated with 10,000 Monte Carlo simulations, bootstrap resampling, Weibull MLE, Kaplan-Meier survival analysis, CUSUM changepoint detection, Shannon entropy, Ljung-Box serial correlation testing, Poisson process goodness-of-fit, and a 6-model forecast ensemble. Because why not.

Reorgs happen. Plan accordingly.

Footnotes#

1. “Like clockwork” is generous. The actual gaps ranged from six weeks to fifteen months, which is exactly why predicting the next one required increasingly heavy statistical machinery. The clock is real—it just has terrible build quality. ↩

2. The project began as a CSV with two columns and ended, several late nights later, as a statistical apparatus wildly disproportionate to the question it answered. Its README footer—reproduced in full at the end of this post, because it deserves to be—is the most honest line of documentation I’ve ever written. ↩