Reorganization Fatigue
A few thoughts on change that never seems to settle
I can’t believe it is June already, and if you’ve spent any real time in software engineering, you probably know the word that tends to surface around this time of year: reorganization. It’s the season when entire groups—sometimes entire organizations—get put through the wringer, shuffling people and teams around in a complete reorganization, as it were, of how they organize themselves, all in order to address some gap that was identified somewhere, by someone, at some point.
Normally, as you’d expect, an explanation as to the why is provided, complete with convincing data showing how this new shift will finally address the issue—you know, the one that was identified as requiring a massive overhaul, right?
What’s curious to me is how many such changes I’ve lived through since 2018. I’m not sure why that was the year I first noticed the shift, but it occurred to me recently that, before then, things were different. Depending on how much you wanted to change—on your career aspirations and ambitions, or even on the opportunities available to you—there was a good chance you’d spend your entire time at a company working with the same team, on the same project, forever and ever.
Since 2018, though, the shifts and reorgs have been too many to count. And they are never gentle, right? They land hardest on the people who weren’t ready to move to another team or another project, or who had invested so much time and effort that they’d come to feel a sense of ownership—somehow married to the idea that this project was their baby. Still, every reorg arrives wrapped in some kind of logic. That’s always how it’s presented to the people it affects.
And here’s the part I keep noticing: once the announcement is made and the proverbial dust settles, everyone slots into new processes and a new routine—and then they forget about it all. It isn’t until the next reorg is announced that people might come to realize something happened at all. Which makes sense, when you think about it. Humans adapt, and in the software industry, adaptability isn’t just useful—it’s a requirement. Get too attached to anything and you won’t fare well in an industry that moves this fast. But it’s striking, isn’t it, how quickly the churn just disappears into routine.
The thought that nags at me—and I mean every single time—is simpler than it sounds: why are we doing this again? Because in my experience, we never seem to take the time to revisit and discuss the last decision. What was the hypothesis behind the last time a reorg was decided? What did they—whoever came up with the idea of shuffling people around—actually expect the previous reorganization to fix? Have they learned anything useful? I keep hoping, perhaps naively, that someone will say they’ve learned a few lessons, and that those lessons are what’s driving this new round. But most of the time, we don’t seem to circle back. We just shuffle again.
I’ve been through more of these than I can count on my fingers. Heck, even throwing in my toes wouldn’t cut it — that’s how many times. And somewhere along the way, I think I picked up a bit of reorganization fatigue. As a manager, I try to build teams that last—teams that can absorb all the curveballs this industry keeps throwing at us, especially now, in the age of AI. Teams with resilience. And that job gets a little harder every time, when there’s so much uncertainty in the air and so little clarity, or even logic, behind the changes people are being asked to undergo.
So every time the cycle comes back around—and it always does—I find myself in the same spot: getting everyone ready for whatever new chapter is opening up, without quite being convinced, myself, why we’re shuffling again. Maybe that’s just the job now. Or maybe, one of these times, we’ll stop to ask whether the last shuffle actually worked before we start the next one.