The Support Tech Who Followed the Script Until It Broke

He knew the fix, he writes. Five minutes, a familiar workaround, something he'd handled a dozen times before for this exact bug. The CEO of a major healthcare network was on the line — patient records down, diagnostics blocked, the kind of system failure that puts care at risk — and the solution was not in the script.

So he didn't give it.

The story, posted to a workplace forum, follows a support technician at a healthcare software company through the implementation of his new supervisor's efficiency drive. The supervisor, fresh from a corporate management program, had arrived with a script-only policy: no custom solutions, no additional steps, no thinking outside the box. If the client's issue wasn't in the script, log it, escalate it, wait for a callback. The technician had raised his hand at the announcement, he says, explaining that most clients called precisely because they were dealing with specific, time-sensitive problems. The supervisor didn't budge. Everyone follows the script. No exceptions.

A couple of weeks later, the CEO called.

The pattern this story represents is old enough to predate the term malicious compliance, but it has found new life in the last decade as management fads have collided with technical work. The setup is always the same: someone who does not understand the work imposes a rule designed to make the work legible from a distance. The person who does understand the work points out that the rule will cause a disaster. The rule is imposed anyway. The disaster occurs exactly as predicted, and the person who predicted it is somehow the one holding the smoking gun.

What makes these stories compelling is not the schadenfreude — though there is always schadenfreude — but the decision point. The technician in this case had a choice: break the rule and risk his job, or follow it and risk the client. He followed it. The CEO lost patience as the technician droned through basic troubleshooting steps he clearly didn't need, asked why time was being wasted, and was told the policy: solutions not in the script require escalation and a callback within 24 hours. The CEO went silent, the post says, then asked for escalation. Within an hour, the supervisor had been summoned to an emergency meeting. The CEO had contacted company leadership directly and threatened to take his business elsewhere.

By the end of the day, the script policy had been scrapped. The supervisor was placed under performance review. The story, the technician writes, spread through the office and grew more exaggerated with each telling — some said the CEO threatened to sue, others that he'd hinted at buying out a competitor. Regardless, the supervisor's name became a cautionary tale.

The comments split along predictable lines. The largest camp celebrated the outcome: the best way to fix a stupid process quickly, one commenter argued, is to follow it rigidly until it falls apart. Another praised the technician for hinting to the customer about the source of the problem so they could bring the pain without the technician risking retaliation. A smaller group questioned the premise. Why would a CEO be calling customer support directly? Shouldn't someone in IT have made that call first, with a list of resolution steps already attempted? And wouldn't the company have service-level agreements in place that made a 24-hour callback unacceptable for a system-down scenario?

Those objections point to the story's weakest seam. A CEO calling a support line is not impossible — small healthcare networks exist, and desperation makes people do unusual things — but it is unusual enough that the story requires it to be true for the stakes to work. If the caller had been an IT manager or a CTO, the same script-following would have caused the same failure, but the retaliation would have moved more slowly and the supervisor's fall would have been less cinematic. The CEO is load-bearing.

The other recurring objection was simpler: this reads like fiction. One commenter noted the opening as a tell. Another pointed to the closing paragraph, where the technician reflects on doing his job the way he always has, thinking on his feet, with a little smirk every time he thinks about it. A third called it generated garbage.

Whether the story happened as written is, in one sense, beside the point. The pattern it describes is real. Management fads do get imposed on technical work by people who do not understand it. Experienced workers do get overruled by supervisors who mistake legibility for efficiency. And the workers who follow the bad rule to the letter, knowing it will fail, are making a rational choice: they are creating a failure that can be traced to the rule rather than to their judgment. The alternative is to break the rule, solve the problem, and have no one notice that the rule would have caused a disaster — until the next person follows it and the disaster happens anyway.

The technician's decision was not sabotage. It was documentation. He followed the script, the script failed, and the failure was loud enough that the script got scrapped. The cost was high — a million-dollar client threatened to walk, a system stayed down longer than it had to, and patient care was briefly at risk — but the alternative was a slow accumulation of smaller failures, none loud enough to kill the policy, until something worse broke.

The question the story raises is not whether the technician did the right thing. It is whether a system that requires a technician to choose between his job and his expertise is a system that should exist at all. The script-only policy was not designed to improve service. It was designed to make service measurable, to turn support calls into data points that could be reviewed in a meeting. The supervisor wanted efficiency. What he built was a system that could not tolerate the thing it existed to provide: help.

And when the system broke, it broke in exactly the way the technician said it would. He was just following orders.