How to kill a project
Techniques for organizational sabotage in the modern era
I lied a little with the title. This piece is about some of the ways projects can get killed, and is meant to show you techniques so that you can defend against them. But, it’s more fun to write from the perspective of some corporate supervillain who’s using wrestling moves on our poor, innocent protagonist.
As they grow, companies naturally develop immune systems as a part of their risk management and risk reduction practices. Most of your opposition isn’t malicious… it’s just emergent behavior from a system designed to restrict the rank and file to legible, approved sets of activities and thinking. There’s a reason why “internal startups” fail.
Most of this comes from my experience at a public “tech” company working on projects with the c-suite, product, strategy, corp dev, engineering, compliance, infosec, finance, fraud, a call center, and two different risk teams.
— if this is feeling too much like an online recipe you can skip this section —
Congratulations! You’ve been selected as part of a secret internal committee whose goal is simple: prevent anything from changing at The Company. We like things just the way they were when we joined. All the music on the radio today is bad.
To be the most effective, you have to remain undetected. Block too many projects in a very public way, and people will know to go around you, or avoid you. You need to preserve your role in the hierarchy; a silent killer.
Despite your limited range of action, there are still many weapons at your disposal. Be warned: these techniques are like dimensional strikes. They eventually salt the earth so that nothing can grow here. But that’s ok. I’ve already vested and cashed out.
Framework
This piece will focus on a specific subcategory of project-killing: Strangling In The Crib. At this stage, when there are few resources committed, it’s more effective to sow Fear, Uncertainty and Doubt (“FUD”) to slow projects down and kill momentum. Eventually a few things will happen:
The leads will give up, submit, move on, or leave
The organization will develop a natural immunity. “We’ve been talking about this for forever. If it was a good idea, wouldn’t we have already done it?”
Advanced readers looking for techniques like Accelerate Into The Wall or Going In Another Direction (for projects that already have momentum) will need to wait for Volume 2, should it ever be published.
The Analytic Paralyzer:
This technique is most effective on absentee and/or anxious executive teams. This can prevent projects from being approved. As the name suggests, this merely involves driving the project deeper and deeper into the weeds until it dies of old age or its sponsors leave. There are endless dimensions that you can paralyze around, but here are a few of my favorites:
“How does this affect [insert other project]?”
Reduce your enemy’s agility with endless Gantt charts, increased complexity and sync meetings.
“Is Project X on strategy?”
If there are >2 former management consultants in the room, this is an insta-kill
“What is our strategy, anyways?”
“We shouldn’t commit to any projects like this until we figure out what our strategy is, otherwise Project X might be off strategy. We can’t afford any more whiplash, morale is low enough as is.”
“What are our competitors doing?”
There’s usually just enough public information to feel like more could be known with some more digging.
But there is usually very little definitive evidence. Plus, execs always care about the competition.
Played correctly, this can suck 1-2 months from a project with zero change to any decisions made
Follow the Instructions
“Normally, if given the choice between doing something and nothing, I’d choose to do nothing. But I will do something if it helps someone else do nothing. I’d work all night, if it meant nothing got done.” - Ron Swanson, Parks and Rec
This is best used to destroy the lead’s will to live, while maintaining plausible deniability. It’s a form of malicious compliance indistinguishable from zealously “protecting the company”, which is why it’s quite useful. This is a known technique for strikers.
If you work in compliance, legal, or infosec, you probably don’t need me to tell you how to destroy someone’s will to live. If you work in a different department, but still want to destroy someone’s desire to live, all you need to do is draw a pentagram on the whiteboard, speak the invocation. “We need compliance’s approval to move foward on this.”
Pro tips:
Your naïve victims may assume there’s a rational basis for the rules you’re rigidly following. Subtly indulge that assumption so that they try a bit before you shut them down, ideally in front of leadership. Try not to show the schadenfreude.
To be most effectively ineffective, soft block projects by highlighting risks without providing any help mitigating them. It’s the business’s decision, of course! But it’s not your job to help make it…
Author’s note: despite the stereotypes about these extremely important functions, I’ve had the pleasure of working with some wonderful people who do their jobs conscientiously with a view toward achieving our shared goals. I’ve found that people in these functions are generally not set up to succeed, and/or are given the wrong KPIs, and they’re just acting according to their incentives.
Compliance/Legal:
“We’re at [size stage larger than in the past] now, we need to start requiring [DNA samples from everyone who works at a vendor].”
“The law isn’t really clear so we’re going to need to wait for [case in state with <1% of your customers] to resolve itself before we can give a recommendation”
"Based on [Law], we could be liable for up to $2 trillion in damages. You, the CEO, and the CEO’s family two generations above and below could be flogged and executed.”
InfoSec:
There’s basically two flavors of infosec people. The first flavor is the ex/white hat hackers. They’re paranoid and have an anime Slack avatar “as social engineering defense” but will solve problems. The second flavor is actually a bad Compliance person, used to work at Ernst and Young, and cargo cults what the first flavor says without understanding the principles behind it. Your goal as a Change Preventer is to be like the second flavor.
“What if we get hacked?”
If unchecked, this question can create an endless list of requirements that effectively kills a project from its sheer weight.
Bonus points for mentioning PII, HIPPA, and Social Security numbers even though companies that leak this data largely go unpunished
“Let’s go with the [vastly inferior] solution from Dell / EMC / Oracle, they have all the certificates.”
This is a signal that you don’t actually care about security and actually care about a proxy for ass coverage.
Congratulations, you’ve successfully continued the tradition of “[I won’t] get fired for buying IBM”
“What if quantum computing breaks the current encryption paradigm, and all our security becomes useless?” (This is how my manager would joke about this category of question)
The Goalpost Switch / Scope Creeper
Why fix what ain’t broken? Things are going so well / the wheels are barely staying on. Sure, we love innovation here at BigCo. Just fill out these 7 forms and you can use Bob’s old airgapped ThinkPad to try this project out.
“What if [group of customers] commits [bad action like fraud]?”
This works because of the insidious human tendency to attribute any negative impacts to the change, rather than the baseline.
The question works well if 1) [bad action] is a scary word and 2) the answer is unknowable.
Pro gamer move here:
Imagine [fraud] is currently 1%, and [fraud] with Project X is correctly estimated to be 0.6-1%.
Focus the discussion on that 0.6-1% and how it could be reduced, and ignore that there’s an expectation that [fraud] actually decreases
“Why can’t this also solve [tangentially related problem]?”
Ideally you rope in an under-resourced, slow-moving team that can complicate requirements.
This synergizes very strongly with the Analytic Paralyzer
“Why isn’t everything automated? This won’t scale.”
This is, of course, just a different flavor of scope creep - we can’t do this unless it’s perfect.
“We need to limit the size of the pilot" AKA “No oxygen for you!”
As an innocent young analyst, I once led a machine learning project where compliance and infosec limited the sample data to 50 documents.
Amusingly the startup I was working with (at the time, 3 people) found product-market fit through this project, and is now valued at 2x my former employer.
You can also try to limit the project through unreasonable restrictions on risk.
Kill the A/B test the moment conversion changes, but before they can figure out why
Restrict the rules engine to be as strict as possible (e.g., levenshtein distance of zero for name matching) Remember. What if [group] commits [fraud]?
The Classic Sabotage
Back in World War II, the OSS (predecessor to the CIA) created a document called the Simple Sabotage Field Manual for ordinary citizens in occupied territory. The first half focuses on physical sabotage, like putting sand in the gears at a factory. The second, in my opinion, is more interesting.
“A second type of simple sabotage requires no destructive tools whatsoever… It is based on universal opportunities to make faulty decisions, to adopt a non-cooperative attitude, and to induce others to follow suit.
Simple Sabotage Field Manual
Further reading:
Be Slightly Evil by Venkatesh Rao
If you liked this, please share. If you’re looking for more I also tweet at @chiefofstuffs
This content is provided for informational purposes only, and should not be relied upon to make legal, business, investment, tax, strategic, or career decisions. You should consult your own advisers as to those matters. While adapted from sources believed to be reliable, Chief of Stuff has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.