How Employees Can Sabotage a Company

Photo from the USS archive. Source

.

A boy plays spy: imagines working undercover in a foreign country. A man plays spy: takes a job as a CTO at an IT company to sabotage its productivity while maintaining the appearance of zeal and loyalty and remaining undetected. For those who are not saboteurs, this is a story about weeding out incompetents and getting the most out of your team.

In the midst of World War II Office of Strategic Services (USS) The United States has released a document titled “Simple Sabotage Field Manual» (Simple Sabotage. Field Guide, or Field Guide to Simple Sabotage, let the translators correct it). The document was later revised by the CIA. It outlines ways to reduce the productivity of any organization. And not long ago, there was a boom of “whistleblowers” in social networks, who drew analogies between the theses from the document and the reality in modern IT companies.

Simple sabotage

“Simple Sabotage” was published in January 1944. The Normandy landings took place in June of that year, and by the middle of the following year the war was won. The OSS was disbanded in 1945, and the CIA was created two years later.

The document was developed as a guide for citizens. Axis powers. It was assumed that by acting on it, they would quietly sabotage industrial production and reduce the efficiency of bureaucratic systems. Despite its archaic nature, the manual is surprisingly relevant today. Especially in the context of organizational effectiveness and workplace dynamics. It offers a unique perspective on behavior that can inadvertently reduce productivity.

Screenshot of a video from TikTok. Source

.

“Simple sabotage” has recently made a resurgence on social media, particularly in TikTok. Users distributed excerpts of the document in their videos and seemed to hint that their companies were doing a lot according to its precepts. Naturally, the content quickly found a response from the audience, and users recognized their managers in the saboteurs.

General rules from the “Simple Sabotage” guide

• Insist on doing everything through “channels” (here we are talking about formal communication channels within companies). Never allow work processes to be shortened in order to speed up decision-making.
• Give speeches. Talk as often and in as much detail as possible. Accompany your points with long anecdotes and stories from personal experience (“Why did you decide that? Let me tell you this. In 1996, the guys and I went fishing…”).
• Whenever possible, refer all issues to committees for “further study and consideration.” Try to make as many committees as possible – at least five.
• Raise irrelevant issues as often as possible.
• Argue about the exact wording of messages, protocols, resolutions.
• Go back to the issues decided at the last meeting and try to raise the question of the appropriateness of this decision again.
• Be “reasonable” and encourage your conference colleagues to be “reasonable” as well and avoid rushing things that may lead to embarrassment or difficulty later on.
• Be concerned about the legality of any decision – raise the question of whether the proposed action is within the group's jurisdiction or whether it might conflict with some higher-level policy.

General rules. Source

.

Reading the guide gives you a sense of déjà vu because, oddly enough, this is exactly what happens in some companies.

I can't stand it I know you planned it

“Let's create a committee to discuss this! We need all the key people, so we will invite all developers and QA specialists… about 60 people… for an hour-long discussion… What? You think the meeting will be unnecessary? Well, you're the only one who thinks so… It seems you are not a team player… Let's meet with HR tomorrow.”

Optimize

To damage an organization, you need to promote incompetent but loyal people to leadership positions and force them to optimize something plausible but unprofitable. And the phrase “

What if we optimize this process to make a profit?

” By the way, if you say it at a meeting with the maximum number of participants, the probability of successful sabotage may increase.

Being destructive isn't that hard: just don't do anything special, weed out competent people below you, and develop a culture of shifting blame down the corporate hierarchy. Just make sure that nothing that's broken gets fixed. That will almost certainly require causing the knowledge that came before you to be mysteriously lost. That may take years, but no one said it was a 20-minute adventure.

Prioritize

What if you prioritize tasks so that the most important ones go to the least effective employees? Imagine a situation where your team has developed a new feature for an application. It needs to be slightly adjusted, tested, and rolled out to production.

Ideally, the specialist (let's say his name is Vasily) should fix all the flaws and hand the task over to the testers. Vasily sees a problem that needs to be fixed. But if there is no piece of code, there is no problem, right? Besides, the task is urgent, so why waste time? Vasily simply cuts out the feature.

An equally lazy tester (say, Petya), although he sees that there should have been a feature here, decides that it's not his business – we test what we brought. Who knows what they came up with in development, the main thing is that everything is fine in the test. The application is launched into production in the form in which it always was, and six months of development are thrown into the drawer. As a saboteur manager, you are doing a great job!

What about the rest of the team? You've occupied experienced and responsible specialists with the most trivial tasks. Naturally, they'll see the “result” of the work and be demoralized, but that's only better. Besides, all secondary tasks are now completed perfectly.

Moreover, striving for perfection in trivial areas can create a culture of fear and indecision. This causes team members to become overly cautious. This can slow progress, hinder creativity, lead to burnout, and wasteful effort on non-critical tasks.

Formalize

Insist on maximum formalization of any actions. Anything said over a cup of coffee should have no right to exist unless it has been recorded in an electronic document management system. Or better yet, a paper one, but that's a whole other level.

This can seriously reduce the productivity of the team. This approach often leads to bureaucratic red tape, slowing down the decision-making process and stifling innovation. For example, if every code change or bug fix must go through several layers of approval before being implemented, this can significantly delay the development cycle. Moreover, it can prevent team members from coming up with innovative solutions or taking initiative, as they may perceive the process as too cumbersome or time-consuming.

In development, where flexibility, quick decision-making and innovation are key to success, such rigid adherence to formality can be detrimental to both team morale and overall productivity.

Increase the number of procedures and permissions. Require multiple approvals when one would suffice (just in case, you never know). This will dramatically reduce the team’s productivity. For example, if a simple code change requires approval from three different people, the process becomes labor-intensive and inefficient. This can lead to bottlenecks, especially if one or more approvers are unavailable or slow to respond. Moreover, this practice can demotivate team members because it makes them feel that their expertise and decision-making abilities are not trusted.

“Never attribute to malice that which can be easily explained by stupidity.”

The eight rules outlined at the beginning of this article are followed to the letter, almost word for word, in many workplaces. Not by irony, not for reasons of sabotage, but legally, as “best practice.” It is a miracle that such companies somehow continue to operate.

These days, this has become so normal that many of the items on the list are revered as best practices. Besides, calling these things “sabotage” is wrong, even as a metaphor. Incompetent employees sometimes cause harm not because they are paid to do so, but because they do not see the whole picture. Moreover, they sincerely believe that they are helping. This is seen in large corporations as well as 20-person startups.

But it's also worth noting that organizations typically have rules in place to deal with these things. For example, if there's too much discussion, you can call for a closure and move on.

CIA refinement of OSS sabotage rules. Source

.

“Simple sabotage” from the 1940s offers an apt reflection of practices seen in many companies today. The tactics outlined in the manual, originally designed to be disruptive, bear striking similarities to behaviors that inadvertently reduce productivity in today’s environments. From over-bureaucratizing every process to obsessively perfecting minor aspects of a product, these practices can create delays, demoralization, and a culture of inefficiency.