The CIA Guide to Sabotaging Your Engineering Team
In 1944, the precursor to the CIA published a highly classified document called the Simple Sabotage Field Manual. Its purpose was to train ordinary citizens in occupied Europe how to quietly disrupt the enemy’s war machine from the inside.
While it contained tips on lighting fires and breaking machinery, its most devastating section focused on “bureaucratic sabotage.” The OSS realized that you don’t need a bomb to destroy a company; you just need to weaponize its own rules. They suggested tactics like:
“Insist on doing everything through channels.”
“Haggle over precise wordings.”
“Refer all matters to committees for further study.”
Sound familiar?
In our quest for predictability, scale, and “best practices,” we’ve created environments where an employee can perfectly follow the rules while entirely destroying product value.
If you wanted to silently sabotage your own engineering team today, you wouldn’t drop production databases or write malicious code. You would just become a rigid, bureaucratic fundamentalist. Here are five ways to do it.
1. Enforce a Strict “Not My Department” Architecture
The Cover: Clear role definitions, or maybe a RACI matrix. To state it once for good: engineers are responsible for the technical delivery; Product Managers are responsible for the business logic and customer outcomes.
The Sabotage: By completely divorcing engineering from business outcomes, you can deliver perfectly functioning code that achieves absolutely nothing.
In the Wild: This is the true story from my experience. Your team is tasked with integrating a new payment gateway via a bank API. The engineer successfully connects the API, the automated tests pass, and the feature is deployed ahead of schedule. However, the transaction rejection rate is skyrocketing. Why? Because the engineer skipped passing several “optional” fields in the payload that the bank uses to verify fraud. When asked about it, the engineer replies, “The connection works perfectly, and the tests are green. Actually, maximizing the acceptance rate was never an engineering concern. No one from the product has ever discussed this with us.”
“How to” References:
2. Weaponize the “Definition of Done” and Requirements
The Cover: Ensuring no work is done without proper alignment, documentation, and explicit business value defined by product owners.
The Sabotage: Using missing edge-cases in requirements as a shield to halt momentum and avoid applying basic engineering common sense.
In the Wild: An engineer is building an internal data table that queries a database of 500 users. By default, the API only returns the first page of 100 entries. Instead of proactively adding pagination, or simply increasing the limit to 1,000 for a quick internal tool, the engineer pushes back: “I need Product to give a business requirement defining the pagination UX, or explicitly state the maximum number of entries to be returned.” The tool is delayed by a week while Product writes a spec for a standard “Next Page” button. (Yes, this is another experience I had…).
“How to” References:
3. Quarantine Reliability as “Tech Debt”
The Cover: Keeping the product roadmap laser-focused on delivering new customer value. Service Level Agreements (SLAs), Objectives (SLOs), and Indicators (SLIs) are strictly technical metrics. They belong in the engineering maintenance backlog so they don’t distract Product from shipping shiny new features.
The Sabotage: Treating stability as an internal engineering chore rather than a core product feature. This guarantees the team will constantly deprioritize reliability, slowly eroding customer trust while technically hitting every roadmap milestone.
In the Wild: The platform is experiencing frequent micro-outages that cause users to be randomly logged out during checkout. When an engineer proposes dedicating the next sprint to fixing the underlying infrastructure to improve their failing SLOs, the saboteur steps in to protect the process: “We can’t halt the roadmap for this. SLA/SLO improvements are tech debt, and our agile policy is to only allocate 15% of sprint capacity to technical chores. Put it in the backlog.” The team successfully hits their deadline for a brand-new feature, flawlessly executing the prioritization framework, while completely ignoring the fact that customers are churning because the core product is unusable.
“How to” References:
4. Practice Agile Ceremony Maximalism
The Cover: Ensuring cross-functional alignment, transparent backlogs, and strict adherence to the Scrum framework for predictable delivery.
The Sabotage: Using the rigid structure of Agile to avoid doing actual work, helping teammates, or making decisions. (This perfectly mirrors the 1944 OSS advice to “refer all matters to committees”).
In the Wild: A junior engineer is stuck and asks a senior engineer a quick architectural question on how to structure a new service. The senior engineer responds: “Let’s not decide this in a vacuum. Put a spike on the backlog. We’ll size it in the next Refinement meeting, and if the Product Owner prioritizes it, we can dedicate Sprint 14 to researching it.” The junior engineer is left blocked on a problem that a five-minute whiteboard sketch could have solved.
“How to” References:
5. Build a High-Speed Factory to Nowhere
The Cover: Becoming an “elite” engineering organization by obsessively optimizing for DORA metrics. Focusing all engineering operations on maximizing deployment frequency and minimizing lead time for changes to prove peak team performance.
The Sabotage: Gamifying the metrics to treat software engineering purely as a throughput problem. You build a blazing-fast feature factory that ships useless code with unprecedented efficiency.
In the Wild: The engineering team celebrates hitting “Elite” DORA status. They have an incredible CI/CD pipeline and deploy to production 20 times a day. To keep deployment frequency high and lead times short, they slice work into tiny, disconnected micro-releases—shipping half-finished buttons hidden behind feature flags and microscopic code refactors. But if you ask any engineer why they are building a feature or what customer problem it solves, they have no idea. The team operates at lightning speed, but product growth is stagnant because the factory is highly efficient at producing things no one asked for.
“How to” References:
The Antidote: Stop Rewarding the Saboteurs
The absolute brilliance of the CIA’s 1944 manual is that successful sabotage doesn’t look like malice. It looks like compliance. It doesn’t wear a ski mask; it wears a company lanyard, points to the Jira board, and quotes the Scrum Guide.
This kind of bureaucratic rot thrives in engineering cultures that value process over progress, and metrics over meaning. When you decouple the engineer from the business outcome, you create the perfect environment for “malicious compliance.”
So, how do you defuse it? You have to change the organizational DNA.
Sociologist Ron Westrum famously categorized organizational cultures into three types: Pathological (power-oriented), Bureaucratic (rule-oriented), and Generative (performance-oriented).
The CIA’s sabotage manual is explicitly designed to exploit a Bureaucratic culture. It relies entirely on narrow responsibilities, rigid silos, and blind rule-following.
To root out silent sabotage, you must actively build a Generative culture.
Here is how you start:
Encourage “Bridging” Over Silos: Saboteurs love silos. They love throwing tickets over the wall and citing “asynchronous communication.” Explicitly reward engineers who bypass the Jira board and jump on a 5-minute call with Product or Sales to actually solve a messy problem.
Enforce Shared Fate: Eliminate the “not my department” excuse. Engineers cannot just own the codebase; they must own the customer outcome. If a feature ships with 100% test coverage but causes user churn, the whole team—Product and Engineering—needs to own that failure.
Shift from “Justice” to “Inquiry”: In bureaucratic teams, when something goes wrong, the goal is to find out who broke the rule (justice). This makes people terrified, so they hide behind process. In a generative culture, the goal is to ask why the system failed (inquiry). When failure is safe, people stop using the “Definition of Done” as a shield.
Take a hard look at your engineering organization tomorrow morning.
Are your “best practices” acting as guardrails, or have they become hiding places? Are you promoting engineers because they deliver real value, or simply because they never break the rules?
Stop rewarding people for perfectly following the process when the process is sinking the ship. True engineering leadership isn’t about building an impenetrable framework of rules and ceremonies. It’s about building a team brave enough to bypass the manual when the product demands it.
If your team’s primary defense for a failed outcome is, “Well, I followed the procedure,” you don’t have an engineering team. You have an infiltrated bureaucracy.