Simple sabotage in the software world

Simple sabotage in the software world

At the height of World War II, the CIA produced the stunning book Simple Sabotage. It outlines various ways in which saboteurs can reduce the company’s productivity. Some of this advice doesn’t get old, such as the Common Obstacles to Organizations and Manufacturing section:

  1. Insist that everything is done through “channels”. Do not allow the shortest paths to be chosen to speed up the implementation of decisions.

  2. Make “reports”. Speak as often and as widely as possible. Illustrate your “ideas” with long stories from life and refer to personal experiences. Willingly make “patriotic” comments.

  3. Whenever possible, refer all matters to committees for “deeper study and consideration.” Try to make committees as large as possible, not less than five members.

  4. Raise issues about non-essential issues as often as possible.

  5. Argue about clear wording in communication, protocols, resolutions.

  6. Go back to the topics that were decided at the last meeting and try to reopen the question of the appropriateness of this decision.

  7. Advise to be careful. Be “smart” and encourage other meeting participants to be “smart” so that they avoid rushing things that may cause inconvenience or difficulty in the future.

  8. Be concerned with the correctness of each decision, raise the question of whether the action will be considered within the jurisdiction of the group, or whether it may conflict with the policy of some higher echelon.

I’m always amazed at how well these tips have stood the test of time. I even printed this out and framed it in my office:

Simple sabotage

Your mission

Let’s say you’ve been hired as a back office CTO and you want to reduce productivity as much as possible without getting caught. Of course you can accept the series obviously bad decisions, but you will soon be fired. The real goal here is to gradually drain the company of its productivity while maintaining a facade of plausibility and normality. What can be done for this?


  • When taking office, require a rewrite of the main systems, which should take 6-18 months. Blame the former CTO.

  • Push everyone to use their own language and frameworks.

  • Split systems across arbitrary boundaries: Maximize the number of systems involved in each feature.

  • Encourage a complex structure of the development environment: let it be a network of systems with at least a dozen services.

  • Make the production environment as different as possible from the development environment.

  • Perform deployments as infrequently as possible. Make sure deployments are handled with the utmost care. Use any production problem as a reason to hit the brakes.

  • Introduce highly complex processes for code changes and standard workflows. Justify it with “security” or “compliance”.

  • Make each task tracked in the task tracker; its verification, prioritization and assertion should be done by a group of at least five people.

  • Don’t allow anything that goes beyond the scope of the original task, such as code cleanups and other improvements made along the way.

  • Create internal versions of almost anything not is a core competency. Justify it as “not wanting to depend on a third-party supplier”.

  • Insist on adding layers of abstraction on top of everything. Choose providers that are abstractions and then add new layers of abstractions.

  • Push for technical solutions based on overly optimistic scale expectations. Plan for at least three orders of magnitude more load than now.

  • Encourage collective ownership of systems. Make sure no one feels responsible for supporting them.

  • Insist on centralization almost in the form of a “platform” owned by a “platform team”. Understaff the platform team and prevent other teams from building what the platform can “own”.

  • Have the platform team work iteratively on the API, changing it frequently, and have all other teams refactor the code to the latest version of the API as often as possible.

  • Hire “architects” and require that even small changes undergo “architectural review”.

  • Require even minor changes to be “security-checked.”


  • Ignore useful metrics with a scientific justification (for example, calling them “skew” or “lagging”).

  • Choose vanity metrics that have little or no correlation to business value and are high in noise.

  • Insist that everything is done as the “most serious task” and that everything is ready before deployment.

  • Consider each feature a “required” and critical part of the “zero version” of the product. Do not succumb to persuasion.

  • Develop extremely detailed “strategic” plans.

  • Change the direction of development often.

  • Dismiss obvious improvements as “local optimization”.

  • Use the most popular trends to link resources. Begin to develop a well-articulated “II-Strategy” that seems plausible on the surface. Actively spend on vendors and consultants on this strategy.

  • Encourage product managers to spend the bulk of their time on “strategy” and “planning.”

  • Make it difficult/impossible for engineers and product managers to use the product internally.

  • Refuse to listen to users, calling them “stupid”.


  • Tie salary level to job title and job title to team size to motivate staff growth.

  • Give great talks on strategies, features and technical complexity.

  • Make expensive acquisitions to enter new market areas. Justify it with “synergy”. Stop using the purchased product.

  • Use multiple links in the reporting structure.

  • As much as possible, have employees report to managers in other teams, offices, or other functional responsibilities. Make managers ill-equipped to control these reports.

  • Often transfer those who do not cope well with duties to other teams.

  • Assign the best workers to theoretical research projects with vaguely defined outcome criteria.

  • Always demand that meetings be held on any decision, no matter how trivial it may be.

  • Insist that every “stakeholder” must be present at the meeting.


  • Organize a hiring process that appears objective but is actually subjective.

  • Refuse to hire the best, citing that they “won’t fit in with the team” or some other vague criteria.

  • Hire the weakest, proving it with “potential”, “motivation” and other vague terms.

  • Hire expensive senior managers who have to take on a large number of subordinates.

  • Use high-profile titles and fictitious positions to attract opportunists.

  • Hire “experts” with a high degree of specialization, then create contrived projects to prevent them from leaving.

  • Use specialization as an excuse to hire other, support staff.

Project management

  • Request highly detailed timeline estimates for any project.

  • Motivate the creation of projects involving as many teams as possible, ideally working in different locations.

  • Add new requirements that depend on the work that other teams are doing.

  • Often use the services of expensive agencies. Set ambitious project scopes and hand off raw prototypes to internal teams for refinement.

  • Build complex self-service systems for stakeholders in other teams.

A frame from a 1994 video clip Sabotage by the Beastie Boys. The song’s lyrics are mainly about technology leadership and developer productivity.


This is not an easy task! But if you can land behind enemy lines and get the CTO position, you can do anything.

Note to non-saboteurs: This is apparently a story about getting the most out of your team. Productivity in general is a story of a thousand cuts, and none of these alone will destroy productivity. But productivity accumulates on a logarithmic scale, that is, the listed items are multiplicative. In fact, if you perform 100 actions, each of which reduces productivity by 5%, then the work will slow down by a factor of 131! The only way not to torment the engineers is to say “no” to this hundred small cuts, each of which seems completely believable and decent.

Related posts