I work on the building side of automation — leading ML research means I spend my time making systems more capable of doing things that used to require a person, and I think that vantage point gives me a slightly different read on this topic than a purely outside observer would have. The capability side of automation is usually the easy part. The genuinely hard part, and the part that gets the least serious attention inside most companies deploying it, is what happens to the people whose work the new capability replaces.
McKinsey Global Institute's research on workforce transitions estimates that 75 million to 375 million workers worldwide — a genuinely wide range, 3 to 14 percent of the global workforce — may need to switch occupational categories by 2030 as automation reshapes work. That range is wide because it depends heavily on assumptions about the pace of adoption that nobody can pin down precisely, but even the low end of it represents a very large number of real career disruptions, concentrated unevenly across industries and geographies rather than spread evenly across the economy.
The Choices Hiding Inside "We Had to Automate"
The framing I'd push back on hardest is the idea that once automation is technically possible, everything that follows is inevitable. It isn't. A company automating a function makes a series of genuinely separate choices: how much advance notice to give affected workers, whether severance reflects years of service or is set at a bare legal minimum, whether retraining is a real, funded program connected to actual open roles or a box-checking exercise that quietly ends the moment the press release goes out, and whether the efficiency gains get shared at all with the people whose displacement made them possible. None of these are forced by the technology itself. They're decisions about values, made by people who could have decided differently, and it's worth being honest about that rather than hiding behind "the market demanded it."
Two Illustrative Patterns, Not Real Companies
To make this concrete, picture two hypothetical, composite versions of the same basic situation — a company automating a function that previously employed several hundred people — because the contrast is genuinely instructive even without pointing at a specific real company.
In the first version, the company gives well over a year of advance notice, partners with a local institution on genuine retraining rather than a generic course nobody uses, and creates real adjacent roles — maintenance, oversight, quality specialization — for at least some of the affected workers to move into. It treats the transition cost as a real line item in the automation's actual return on investment, not an externality someone else absorbs. The result, in this idealized version, is that most displaced workers land somewhere comparable, and the company keeps its reputation and its access to skilled local labor intact for the next time it needs to hire.
In the second, more common version, the company announces layoffs abruptly, offers the legal minimum severance and nothing more, provides no meaningful retraining, and treats the transition as purely the workers' problem to solve on their own time and dime. The short-term savings are real and immediate. The longer-term costs — a damaged local reputation, harder future hiring, and often real community backlash — tend to show up later, discounted by decision-makers who've moved on to the next quarter's numbers by the time the bill comes due.
Neither of these is a specific documented case — they're composites meant to illustrate a real, recurring pattern, not an accusation against any named company. But the pattern itself is genuinely common, and the difference between the two versions isn't really about how much automation technology a company can afford. It's about whether workforce transition costs get treated as a real cost of the automation decision, or as someone else's problem entirely.
What Actually Constitutes Doing This Responsibly
A few concrete practices separate the responsible version from the extractive one, and none of them require exotic policy — they require treating the transition as seriously as the technical rollout. Building workforce transition costs into the actual ROI calculation for an automation project, rather than measuring only the efficiency gain, changes the apparent economics of a project meaningfully — a project that looks like a 40% margin improvement on paper can look much less attractive once genuine transition costs are honestly included, which is precisely why companies often don't include them. Staging implementation gradually, rather than flipping a switch, gives affected workers real time to find something else rather than a shock departure. And creating genuinely new adjacent roles — someone has to maintain, monitor, and improve whatever system replaced the manual process — is a real source of jobs that a lot of companies underinvest in relative to how much they invested in the automation itself.
The Question I'd Actually Ask
The question worth asking isn't whether a given task can be automated — for a large and growing share of work, the answer is yes, and no amount of hand-wringing changes that. The question is whether the value created gets shared at all with the people whose displacement made it possible, or whether it flows entirely to shareholders while the transition cost lands entirely on workers who had no say in the decision. That's not a technology question. It's a distribution question, and companies answer it every time they automate something, whether they think of it that way or not. The ones that answer it generously tend to keep better access to skilled labor and community trust the next time they need either. The ones that don't tend to discover, eventually, that the discount rate on a damaged reputation is higher than it looked in the initial ROI spreadsheet.