"I assume this confirms my previous bias. By the way, did you notice how this story provides even more evidence that my bias is correct?"

They can replace you if you are just a coder. If, on the other hand, you work on an important product, acquire domain-specific knowledge, and know the code inside-out, then replacing you with someone else will be a lot harder.

Think, for example, about the folks who work on the Microsof's C/C++ compiler. I doubt any of them need to worry about their job. On the other hand, if all you did is implemented the Shutdown button for the next release of Windows then, sure, you can be easily replaced.

This actually happens a lot at Microsoft; the reason why it's unheard of is they're normally hiring more people than they're RIFing. The Microsoft reorg 30 day job search is a way of life for people in some disciplines and teams there.

Much like high level programming can "waste" large numbers of clock cycles, cutting huge orgs while hiring other ones certainly doesn't seem efficient, and is especially grating given that we're talking about livelihoods, not zeros and ones. Unfortunately I don't think anyone has come up with a paradigm that works a lot better than this, although I'd be curious to hear of any large successes.

After a few years on the payrolls of mega-corp, you get replaced [...] Perhaps it's inevitable with a competitive labor market...

Yeah, it was a feature when many of us were getting in during high-school, but it sucks as an incumbent. I guess the takeaway is to stay hungry.

At a company that size there doesn't actually have to be much more to it than what they say. Project A might have too many developers and not enough QA, project B might be short developers and too much QA. Project A gets dev positions cut and project B gets QA positions cut, but they're still hiring for the open slots in both cases.

At a small company, it's fairly trivial to just move people from A to B etc. But when you're steering a ship with thousands of employees it's not worth it.