· Marc Price · business-process-automation · 11 min read
The Drudgery Paradox: Why Your Team Will Fight to Keep the Work They Hate
You set out to remove the grind everyone complains about, and hit resistance. That's not ingratitude - it's Kahneman, Machiavelli and 2,500 years of philosophy. Here's the fix.
TL;DR
You identified the grind - the re-keying, the reconciliations, the Friday spreadsheet nobody enjoys. You commissioned the automation. Then the people who complained loudest started defending the work. That’s the drudgery paradox, and it is not (simply) ingratitude: dull work quietly provides structure, competence and status, and its removal is a certain loss set against an uncertain gain - which, as (Nobel prize-winner) Daniel Kahneman showed, is a contest the loss almost always wins. The fix is not a better pitch for the future. It’s shrinking the loss: define what the freed time is for, pilot small and reversibly, and let the people who own the process build its replacement.
What is the drudgery paradox?
The team that moans about a task is often the same team that fights to keep it.
The pattern is familiar to anyone who has run an automation project. A manager spots the obvious candidate - the monthly report that takes three people two days, the order data re-keyed from one system into another, the inbox triage that eats every Monday. Staff have complained about it for years. So the manager does the decent thing and commissions the fix.
And then the resistance arrives. Not always loudly. Sometimes it’s a stalled requirements document. Sometimes a pilot that keeps finding edge cases. Sometimes the quiet observation that “the old way did have its advantages”. The people who were meant to be grateful are, instead, wary.
Frustrating, yes… inexplicable, no. A quick glance at the work of some philosophical greats shows us that this follows logically from basic human drives.
Why is habit so hard to argue with?
Because habit isn’t laziness - it’s efficiency, and it has philosophy on its side.
David Hume called custom “the great guide of human life”. We don’t reason our way through the working day; we run on precedent, because precedent is cheaper than thought. And William James put it mechanically: habit is society’s fly-wheel - it stores energy and resists sudden changes of speed. That is exactly what your team’s existing process is doing.
Machiavelli added the political half of the story five centuries ago: change makes certain enemies of everyone who did well under the old way, and only lukewarm friends of those who might do well under the new. The losses are concentrated and immediate. The gains are diffuse and speculative.
What does Kahneman say about why people resist change?
Losses loom larger than gains, and your automation project is being scored as a loss.
Daniel Kahneman and Amos Tversky’s prospect theory is perhaps the single most useful lens here. Their finding, replicated for four decades, is that people feel a loss roughly twice as strongly as an equivalent gain. Look at what sits on each side of the ledger when you remove a dull process:
| What’s lost | What’s gained |
|---|---|
| A known routine, certain and immediate | ”Time for higher-value work”, unspecified |
| Demonstrable competence at the current task | Competence at something not yet defined |
| A visible reason for being busy | A future that has to be justified |
| Ownership of a process | A system someone else built |
The left column is concrete. The right column is a promise. Prospect theory says the left column wins, and it says so without anyone being stupid or ungrateful.
Three related findings pile on. Status quo bias: people disproportionately stick with the default, and the current process is the default. The endowment effect: we overvalue what we already hold, and a process someone has run for six years is, psychologically, theirs. And algorithm aversion - the brutal one for automation projects: people abandon an algorithm faster than a human colleague after seeing it make a single error, even when the algorithm is more accurate overall. The new system gets one mistake before trust collapses. The old process made mistakes for years; nobody was counting.
Why do people defend work they say they hate?
Because the moaning was never a request.
You heard people complain about the task and took the complaint at face value. But complaining about dull work is usually doing something else entirely. It’s social - shared grievance is bonding, and the Monday inbox is a running joke that says we’re in this together. It’s a claim to virtue - “look what I put up with” is a statement about diligence. And it’s structural: the task provides a floor to stand on, a visible answer to what you did this week.
Robert Kegan and Lisa Lahey call the result an immunity to change: resistance is rarely simple obstruction, it’s a hidden competing commitment. “I want less admin” is sincere. But so is “I want to remain the person who knows how this works”. Both are held at once, and the second one wins quietly.
So, when someone defends the spreadsheet, listen for the hidden job it was doing. Structure. Visibility. A reason not to face the harder question of what they’re for now.
Why does automation feel worse than other change?
A tool is invisible until you replace it.
Heidegger observed that a well-functioning tool is “ready-to-hand” - you don’t notice the hammer, you notice the nail. The hammer only becomes an object of attention when it breaks. Then it’s “present-at-hand”: visible, awkward, demanding thought.
Every automation is, for a few weeks, a broken hammer.
The old spreadsheet was ready-to-hand; nobody thought about it, they just did it. The new system is present-at-hand: unfamiliar, noticed, judged. That’s why teams who never had an opinion about the old process suddenly have multiple opinions about the new one. They’re not being difficult. They’re paying attention for the first time, and attention hurts. Add algorithm aversion - one visible error while everyone’s watching - and you have the recipe for a quietly abandoned system.
This is why the “just deploy it and they’ll get used to it” school often fails. Ready-to-hand is earned through use, not decreed. We covered the human-in-the-loop side of this in Empower, Don’t Replace - the goal is not to remove the human, it’s to get the new tool to disappear into their hands as fast as possible.
How do you move a team through resistance to automation?
Don’t sell the gain. Shrink the loss.
Everything above points the same way: the resistance isn’t about the future you’re describing, it’s about the present you’re taking away. Here’s what works, in order.
Treat the moaning as data, not a mandate. Before you automate anything, ask what else the task was doing. Who gets visibility from it? Whose competence does it demonstrate? If you can’t answer, you don’t yet understand the process you’re replacing. (Complaints locate the opportunity, as we argued in The Unsexy Truth About Business Automation - but they don’t tell you what the work was secretly holding up.)
Define what the freed time is for before you free it. “Higher-value work” is a placeholder, and people can hear that it’s a placeholder. Name the actual thing - the account reviews that never happen, the customer calls that keep getting bumped. A concrete gain can compete with the loss. A vague one never will.
Pilot small, and make it reversible. Prospect theory punishes big uncertain bets. A two-week pilot on one sub-process, with the old way still running alongside, takes nothing away - so nobody has to defend anything. It’s also how you build the trust that survives the first error.
Let the people who own the process build its replacement. The endowment effect works in your favour if you point it at the new system. Someone who helped design the automation owns it. Someone who had it done to them resents it. Twenty-five years of B2B delivery says this single move matters more than any amount of communication.
Budget for the broken-hammer weeks. The new system will be present-at-hand for a while. Plan for the noticed errors and the negative opinions, and say out loud that it will feel worse before it feels invisible - then, when it does become invisible, say that too.
Replace the function, not just the task. If the spreadsheet gave someone a Friday ritual and a reason to be seen, give them a different ritual and a different reason. Structure and visibility are not luxuries; they’re what the dull work was quietly paying for.
None of this is soft. It’s the difference between an automation that runs and one that’s technically live and practically ignored - which, as we noted in Why 45% of AI Marketing Tools Fail, is where a good chunk of AI spend actually ends up.
The Bottom Line
Your team is not uniquely resistant. A certain, familiar loss feels more comfortable than an uncertain gain nearly every time, and a habit is a stabilising fly-wheel. The dull work you want to remove was quietly paying for structure, competence and a place in the conversation.
So when pitching the future, think first about protecting the present. Name what the freed time is for. Pilot small and reversibly, where possible. Let the people who own the grind have a hand in building what replaces it. And budget for the weeks when the new tool feels like a broken hammer. Then let it disappear into their hands.
The hardest part of removing boring work was never the development of the new system itself.
If you’ve got a process everyone complains about and a project that’s stalled anyway, book a discovery call. We’ve seen the pattern before, and we know where the hidden job usually is.
Frequently Asked Questions
Why do employees resist automation of tasks they say they hate? Because complaining about a task and wanting it removed are different things. The task is a known quantity that anchors routine, competence and status. What replaces it is unknown. Prospect theory (Kahneman and Tversky) shows people weight a certain loss around twice as heavily as an uncertain gain, so resistance is the rational-feeling default even when the work is genuinely dull.
What is the drudgery paradox? The drudgery paradox is the pattern where a team complains consistently about repetitive, low-value work, and then resists the project that removes it. It happens because the moaning is social and identity-based rather than a request, and because the certain loss of a familiar routine outweighs the vague promise of “higher-value work”.
Which cognitive biases explain resistance to change at work? The main ones are loss aversion (losses are felt roughly twice as strongly as gains), status quo bias (the default wins), the endowment effect (we overvalue processes we already own), and algorithm aversion (people abandon software faster than colleagues after a single error, even when it is more accurate overall).
Is it true that 70% of change programmes fail? No. The 70% figure is folklore. Mark Hughes traced it in the Journal of Change Management (2011) and found no empirical basis - it originated in a 1993 book and has been repeated ever since. Change programmes do fail, but the reasons are usually specific and fixable, not a law of nature.
How do you reduce resistance to automation and AI? Shrink the loss rather than selling the gain. Define concretely what the freed time is for before you remove the task, run small reversible pilots so the new way becomes familiar fast, let the people who own the process help build its replacement, and treat the moaning as data about identity and status rather than a mandate.
Should you automate a process the team defends, even though it is obviously repetitive? Usually yes, but not by force. If people are defending it, the process is doing a job beyond its stated one - structure, competence, visibility, or a claim to being busy. Find that hidden job, provide it another way, then automate. Removing the task without replacing the function is how good automation projects get quietly sabotaged.
References
- Dietvorst, B., Simmons, J. and Massey, C. (2015). “Algorithm aversion: People erroneously avoid algorithms after seeing them err.” Journal of Experimental Psychology: General, 144(1), 114-126.
- Heidegger, M. (1927). Being and Time.
- Hughes, M. (2011). “Do 70 per cent of all organizational change initiatives really fail?” Journal of Change Management, 11(4), 451-464.
- Hume, D. (1748). An Enquiry Concerning Human Understanding, Section V.
- James, W. (1890). The Principles of Psychology, Chapter IV, “Habit”.
- Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
- Kahneman, D., Knetsch, J. and Thaler, R. (1990). “Experimental tests of the endowment effect and the Coase theorem.” Journal of Political Economy, 98(6), 1325-1348.
- Kahneman, D. and Tversky, A. (1979). “Prospect theory: An analysis of decision under risk.” Econometrica, 47(2), 263-291.
- Kegan, R. and Lahey, L. (2009). Immunity to Change. Harvard Business Press.
- Machiavelli, N. (1532). The Prince, Chapter VI.
- Samuelson, W. and Zeckhauser, R. (1988). “Status quo bias in decision making.” Journal of Risk and Uncertainty, 1(1), 7-59.
Marc Price is the founder of Aandai, a B2B automation and AI consultancy helping mid-market businesses achieve more with less. With 25+ years in B2B technology marketing and web development, Marc specialises in connecting legacy systems, eliminating manual processes, and implementing practical AI solutions that deliver measurable ROI. Aandai runs its own agentic stack on OpenClaw to automate parts of its consultancy delivery - including the research that informed this article, and the occasional argument with a philosopher.
