When IT Ignores Users: How One Team Turned Office Frustration Into Malicious Compliance Gold
Picture this: your workplace finally upgrades a 25-year-old document management system. You brace for change, but at least security will improve, right? Next thing you know, the new platform rolls out—no warning, no training, no announcement. Surprise! It’s missing half the features you need to actually do your job. Welcome to yet another episode of “Let’s Ignore The People Who Use The Tool.”
When the original poster (OP) tried to help by offering a helpful list of missing features, they got stonewalled by a prickly project manager (PM) more interested in process than solutions. But this is r/MaliciousCompliance, where “doing exactly what you’re told” is a fine art—and sometimes, the only way to get things fixed.
“Tested in Production”—Because What Could Go Wrong?
Let’s rewind. The company decides to upgrade its ancient document platform. No user consultation, no pilot group, no “Hey, what do you guys actually need?” Just a silent switch. When OP’s team discovered the glaring gaps, they tried to help by sending a consolidated list to the PM. The response? A frosty “Use the help link to submit your issues. One email at a time.”
As one commenter, u/vaildin, so perfectly summarized: “Top People.” (If you heard that in the voice of the Indiana Jones government agent, you’re not alone—other commenters caught the reference too.) Another, u/DrHugh, wryly added: “We’ll test it in production,” while u/drifterlady lamented, “Users = Testers, see this often sadly :(.” If your company ever rolled out a new tool and you wondered if anyone actually tried it out first—well, you probably just took part in the user acceptance testing, unpaid.
Malicious Compliance: Death By a Thousand Support Tickets
With the PM’s instructions in hand, OP’s team turned to the sacred art of malicious compliance. Instead of working together to solve the laundry list of issues, they split up the list and dutifully reported one problem per person, per day—five new tickets hitting the PM’s desk daily, each meticulously following the official process. When no answers came, they doubled down: follow-up emails on every open ticket. Ten emails a day. Every day.
As u/PhDTARDIS put it, “You were trying to make the PM’s job easy, but they stonewalled you. Okay, suit yourself—the hard way, a blizzard of tickets is now yours! I love this.” The PM, now buried under an avalanche of support requests, finally snapped and escalated to his boss. (Pro tip: If you don’t want the fire, don’t play with matches.)
OP’s supervisor’s legendary “reply all” laid out the facts: “We tried to give you a list on a call. You told us to email each issue. We did exactly that.” The boss, seeing the forest for the trees, immediately asked for the full list—and, in true poetic justice, the PM was never heard from again.
The Universal Language of “Who Actually Uses This?”
If this saga sounds familiar, you’re not alone. The r/MaliciousCompliance community responded with a chorus of war stories, facepalms, and gallows humor. u/Equivalent-Salary357 shared how teachers at their school were forced onto new gradebook software on the first day of school—no training, no documentation, and the crucial grade calculation module didn’t even exist yet! Elsewhere, u/Thinking80 recounted an engineering disaster: printers “upgraded” without consulting users, resulting in unreadable drawings and wasted paper, all to save a buck.
The consensus? “Ivory tower” decisions are alive and well, with u/RayEd29 declaring, “A team completely removed from the actual end user population designs, builds, and implements a ‘solution’ that solves no problems while creating tons of additional issues.” As u/ceallachdon, a 40-year software veteran, bluntly put it: “Every single time it was upper management.” Whether it’s rushed deadlines, canned requirements, or expensive software bought after a round of golf, the result is the same: chaos for the people who actually have to use the thing.
Lessons Learned (Or Not): Why User Input Isn’t Optional
The real kicker? Every single one of these stories could have been avoided with a little thing called “User Acceptance Testing.” As u/Key_Charity9484 mic-dropped: “That is why UAT is such a huge part of a system roll out.” Yet time and again, basic user input is skipped, sometimes because management “already knows better,” sometimes because they don’t want to hear bad news before a go-live date.
And when things go sideways, who gets the blame? Often, the very people who tried to warn everyone. As OP clarified in the comments, the PM’s boss got a front-row seat to the fallout: “HE included the guy on an email where he was scolding us for asking questions and pointing out things that they missed.” The end result? The boss took over, the team finally got a proper list of fixes, and the PM faded into the mist—hopefully to a quieter project.
Conclusion: Speak Up, Follow Orders (to the Letter), Repeat
If you’ve ever been on the receiving end of a disastrous software rollout, take heart: you’re not alone, and you’re not crazy. The next time someone tells you to submit your complaints “through the proper channels,” remember OP’s story. Sometimes, the only way to be heard is to comply—with gusto.
Have you ever survived a “tested in production” nightmare? Or maybe you’ve been the one forced to fix a system that nobody asked for? Share your best (or worst) IT rollout stories in the comments—we could all use a laugh (and maybe a little catharsis).
Original Reddit Post: Asking the question you told me you wanted