I think the flaw with the scenario you described is that your programs are “replacing” these peoples’ “jobs”, when, in reality, we’re building tools that empower them to perform their jobs more effectively.

In the case where we create a self-service option for our customers, such that they no longer need to call in, our ops friends are grateful that we’ve removed a tedious task from their day to day work. From my POV, internal users are as much our customers as external users are.

Of course, there’s a fine line between “empowering” and “replacing”. As our tools become more powerful, we need fewer hours to do a greater number of tasks, so ops’ headcount can scale sub-linearly with the number of tasks they need to complete.

While that gives us a business edge, it also means that we can invest in making our fewer people more generally-skilled, so that we avoid the case you describe (where a person’s job description is encapsulated in a single task, which is eventually automated away). We can also afford to pay them well, and their work is generally more varied and interesting. It’s a clear win for those on the inside.

The only losers are the hypothetical 100 or so unskilled people we’ll never hire or invest in, because our existing 100 are adequately supported. I don’t know a solution to that problem, but it can’t be to hire 200 people and give them terrible tools.