271 points by adammiribyan 9 days ago | 33 comments
roenxi 9 days ago
The major thing that springs to mind here is I've never seen a compelling reason to believe that the original CIA suggestions actually worked. In my experience workers like that exist naturally and organisations are great at just sidelining them. I think in that section the CIA was just writing a listicle that sounded good [0].

The way to cripple a company is to get bad people promoted into management and have them optimise something plausible but not profitable. Like what happened in a lot of slow-fail engineering companies - insist on maximising the profit metric to the point where the actual product becomes compromised. That strategy can be intiated from almost anywhere in management too because a constant "what if we optimise for profit" [1] usually does well at meetings.

Being a destructive CTO is almost too easy. Just don't do anything much, weed out any competent people in the level below you and develop a culture of pushing blame aaaaalllllllll the way down the org chart, ideally out of the technical part of the tree, so that nothing broken gets fixed. When people catch on, allow blame to move 1 level up the org chart and do a big shakeup to clear out any institutional knowledge that might have built up in spite of you. That game can go on for years.

[0] I've seen people where "do things through official channels" and "demand written orders" would have made them more productive. We are our own worst enemies.

[1] Yes, the irony here is that naive optimising for profit is typically not profitable.

krisoft 9 days ago
> I've never seen a compelling reason to believe that the original CIA suggestions actually worked.

Let’s set asside the fact that the document wasn’t written by the CIA.

The purported goal of this document was to provide practicaly applicable advice to the regular citizen who found themselves under enemy occupation. Most concretely to be given to the French people who did not like the German occupation.

You are talking about the strategy “working” or “not working” as if these are binary things. The goal here was not that these simple steps will bring Germany to their knees but to increase the cost of the occupation. To cause enough deniable friction which bogs down the resources and make everything just a bit more inefficient.

> In my experience workers like that exist naturally

They do. And that is the point. That is what makes these strategies deniable.

> and organisations are great at just sidelining them

If that is your experience I would love to work where you worked. In my experience when someone is following this strategy sidelining only happens slowly and at great costs. One of the many costs is people comitting avoidable blunders when they dismiss real and well reasoned objections in their haste to cut through a sea of useless ones.

> to get bad people promoted into management

Sure. But that takes time. You are thinking on a different time scale than the authors of this document were thinking about. The document was published in Jan 1944. The Normandy landings happened in June the same year and by the end of the next year the war was won. You don’t have time to slowly promote bad people into management. If a dude who read your booklet bumbles about a bit and delays the repair of a train line by days that is a win in this context. Nobody expected that Germany is going to collapse on their own just because enough people sabotage meetings and plug up toilets. (That is by the way also a suggestion from the manual 5.1.b.2. Somewhat less often cited than the points applicable to office work.)

_djo_ 9 days ago
> Let’s set asside the fact that the document wasn’t written by the CIA.

What do you mean? The CIA has publicly stated that the document was written by the OSS, its wartime predecessor. [0]

[0] https://www.cia.gov/stories/story/the-art-of-simple-sabotage...

krisoft 9 days ago
That is what I mean exactly. Your second sentence answers your question. My dad is not me. The OSS is not the CIA. It is a predecessor of it.
smcin 9 days ago
Feels too hairsplitting. It was the same type of people doing largely the same activities with the same objectives, even if on paper there was a 2-year hiatus between OSS being dissolved and CIA created. People would understand if you wrote "OSS/CIA did X" when describing the 1940s/50s/60s.

Similar to how a branch of the US Public Health Service [0] originally tasked with malaria prevention became Communicable Disease Center (CDC) in 1946-67, subsequently renamed to "Center for Disease Control" and "Centers for Disease Control" (1980), "Centers for Disease Control and Prevention". It hasn't actually been called the "Center for Disease Control" since 1980, although many people (incl. journalists) still call it that.

Also, most countries' Department of Defense/Ministry of Defence were called Ministry of War or Department of War during WWII (and some only controlled the army, not all branches of military). [1] And the White House War Room was renamed the Situation Room in 1961. (RIP George Carlin.)

[0]: https://en.wikipedia.org/wiki/Centers_for_Disease_Control_an...

[1]: https://en.wikipedia.org/wiki/Ministry_of_defence

walterbell 9 days ago
https://warontherocks.com/2015/09/how-the-oss-shaped-the-cia...

  Wild Bill Donovan’s admirers and critics still argue over his legacy, but on one point they agree: His World War II Office of Strategic Service (OSS) became the Petri dish for the spies who later ran the CIA as well as the special operators who conduct some of the most daring raids the world has ever seen.

   Four CIA directors — Allen Dulles, Richard Helms, William Colby and William Casey — learned the craft of clandestine warfare as operatives for Donovan’s OSS. Indeed, the daring, the risk-taking, the unconventional thinking, and the élan and esprit de corps of the OSS permeated the new agency.

   So would the OSS’s failings: the delusions that covert operations, like magic bullets, could produce spectacular results, or that legal or ethical corners could be cut for a higher cause.
majewsky 9 days ago
So we are all in agreement. :)
fuzzfactor 9 days ago
>>workers like that exist naturally

Ones whose only significant effort (if any) is to be a mainstream employee in all other ways since nothing will ever make them productive or capable of efficient operation.

>> and organisations are great at just sidelining them

>If that is your experience I would love to work where you worked.

Me too. That does seem like uncommon good fortune. Too often these are the ones that get promoted into higher levels of mangement, it is so widespread among different companies it goes undetected in the way the CIA intended. Plausibility beats productivity.

roenxi 9 days ago
> You are talking about the strategy “working” or “not working” as if these are binary things.

WWII was before all this, but we have decades of management experience about how to take ordinary people and make them productive in an industrial setting.

The CIA list isn't the inverse of that. They didn't have Dilbert then either, but it looks like the equivalent of mailing over some Dilbert comics. Maybe it is better than nothing and I don't fault them for trying everything but I've never seen evidence that these are actually effective hints at sabotaging an organisation. The office-work stuff, not the physical ideas which I assume are quite effective.

Now that the discipline exists it'd be interesting to get a group of great operations researchers together and have them come up with their own list of ideas then see what the overlap is. It might be quite small. Is it more damaging to have a great worker who gets one or two key thing wrong or a grumpy guts who does poorly at everything? I suspect the former, the sabotage handbook the latter.

multjoy 8 days ago
It isn't aimed at one or two individuals, it is aimed at the workforce of an occupied country who are required to keep working and directly/indirectly supporting the occupying power.

This is for the people who, for whatever reason, can't be partisans but can do their part to ensure that they're not collaborating.

oldgradstudent 9 days ago
You can do far far worse than naive optimizing for profit. Optimizing for *REPORTED* profit.

People learn very quickly to manipulate the reporting, modeling, and accounting.

Just less than two decades ago we had the entire financial system lending massive amounts of money to the worst possible borrowers and REPORTING massive profits.

jt2190 9 days ago
Refer to the section “(11)(b) Managers and Supervisors” https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...
thih9 9 days ago
> naive optimising for profit is typically not profitable

Naive optimizing for anything, while consuming that metric as fuel, has that effect.

A.k.a. “We will continue having meetings until we figure out why productivity is dropping”.

hobs 9 days ago
Oh yeah, this one really is fun. We used to joke that the CTO of one of the companies I worked for made a killing as his second job was for our competitors.

Turns out the dude has been doing that for about 15 years between various places and now is about to retire, blameless in the eyes of everyone who doesn't understand what happened.

andrei_says_ 9 days ago
Doing what? Getting paid by a competitor to destroy his current company?
hobs 9 days ago
No, being incompetent to the point where if you squinted he might as well be.
walterbell 9 days ago
If those were public companies, one could backtest put option signals timed by his career moves.
stavros 9 days ago
They do work, we had a director who did all that in a previous company (probably unintentionally), and things ground to a halt and productivity fell to zero.
mattacular 9 days ago
> [1] Yes, the irony here is that naive optimising for profit is typically not profitable.

Yes but only over a relatively long time period, which the overarching system itself is not incentivizing anyone to look at too carefully.

krisoft 9 days ago
> CIA produced a fantastic book during the peak of World War 2 called Simple Sabotage.

Not quite right. The Office of Strategic Services did that. The CIA was created only in 1947 several years after the end of the second World War in 1945.

llm_trw 9 days ago
> 4. Bring up irrelevant issues as frequently as possible.

Excellent. Continue the good work.

01HNNWZ0MV43FF 9 days ago
Let's keep talking about this. How is two years "several"? That's "a couple" literally and maybe "a few"
082349872349872 9 days ago
So while we're here: anyone know if Sonia Brownell ever worked with PWE before working with IRD? (or have suggestions as to where to look for this sort of thing?)
throwawayqqq11 9 days ago
Sorry, but i have to flag your comment.

1) dang has to decide whether this is too snarky or not.

2) Please stay on topic, its about CIA or not.

3) Its hardly "frequently bringing up irrelevant issues".

Have i missed something?

oopsallmagic 9 days ago
A sense of humor?
llm_trw 9 days ago
I'm pretty sure the post you're replying to is a joke.

We need to form a sub comittie to figure out if it is.

jwilk 9 days ago
You missed https://news.ycombinator.com/newsguidelines.html:

> If you flag, please don't also comment that you did.

c0balt 9 days ago
Flagging should be accompanied by a reply to the original post. Otherwise this bypasses the official channel and the op won't be able to receive proper feedback. Such issues should also be referred to the moderation committee and the awareness team. /s
hinkley 9 days ago
The head of the OSS also founded the CIA, so is it really that big of a stretch?
krisoft 9 days ago
> is it really that big of a stretch?

I don’t know what is a big or a small stretch. I just know it is just not true. If you studied the history of the second World War, or the history of the CIA, or the history of the Cold War then that sentence sticks out like a sore thumb. It makes as much sense as describing how many Gatling guns Hannibal mounted per elephant.

I guess in a certain post-truth sense it is a smaller stretch of the truth to say that the CIA published it, than to say that the KGB did it. And in turn attributing it to the KGB would be a smaller stretch of the truth, than attributing it to the elves of Middle Earth. But what is common between all those three is that they haven’t authored this document, because it was the OSS who did it. (As the document itself conveniently, and very prominently states.)

maxbond 9 days ago
I think you overstate. It's an ellision ("written by OSS, the predecessor of the CIA" to "CIA"). They're as common as weeds and as old as the hills. It's all well to point out that it's factually inaccurate, but it's directionally correct and gives people who aren't familiar with OSS the right impression. You don't have to like it to recognize it isn't a "post truth" phenomenon or anything comparable to Hannibal crossing the alps with Gatling guns, or even that the document was authored by the KGB.
patrakov 9 days ago
The manual misses the most important step: getting rid of people who have even the slightest idea of how the product as a whole should work and/or a coherent vision of a better future. The word "vision" is not even present in the text. Visioners are the ones who can sabotage the saboteurs.
9 days ago
walterbell 9 days ago
A good subject for organizational theory case studies would be the relative cultural immunity of companies with a well-articulated founding vision document, charter of principles, or other operational guidance for employees.
penguin_booze 9 days ago
The 'Hiring' section needs an update: ask Leetcode hard-level problems, and demand to witness enlightenment and an optimized solution in under 30 minutes. Uncertainty and doubt shall not be tolerated.
ohyes 9 days ago
This is interesting because a lot of the decisions to “sabotage” are about convincing people to attempt to cover their own asses.

I think in that light, number 1 is to foster an atmosphere of fear where anyone attempting to make things better will be confronted if things don’t go perfectly.

KronisLV 9 days ago
> Make sure production environment differs from developer environments in as many ways as possible.

I feel like this, in some capacity, is borderline inevitable in the modern architectures with a bunch of external services, or at the very least will 100% require that your devs are connected to the Internet all the time to be able to do anything, vs systems that are 100% self hostable.

Or even just running a complex Kubernetes cluster with a service mesh and other solutions on the test/staging/prod infra vs loosely mapping to more lightweight options locally, unless you have a super beefy setup. And even then, if everything is split into multiple separate services far enough, you just won't be able to run everything locally, meaning that you need to use some of the components from shared dev environments which will inevitably lead to stepping on each other's heels.

Once you go past something like Docker Compose for local environments, things can go sour.

Spivak 9 days ago
The way I think about this without going insane isn't "developer environment must be exactly the same as production environment" because like you said, you'll never do it — there's too many things you can't replicate locally.

So I flip it around — production should work exactly like the development environments. If there's a a difference between the two that matters we update production to match. You want to talk to other services by a well-known container name instead of an env var we pass? Sure, whatever we can do that.

hinkley 9 days ago
I used nginx as a forward proxy a couple times before Docker was a thing. Poor man’s service mesh still has some utility.
teddyh 9 days ago
Im some ways, this is an unsolvable problem, due to entropy. You can’t even step into the same river twice.
btbuildem 9 days ago
The eight rules laid out in the beginning of the article are strictly followed, almost word-for-word, at my workplace. Not ironically, not for sabotage reasons, but legitimately as "best practices".

It's a miracle that somehow the company remains in business.

xjay 9 days ago
In a web context, I was thinking this when I checked out the web site of the Electronic Frontier Foundation (EFF) [1]; why would they use a thin, small typeface with light gray color on a bright/white background which makes the text less appealing to read? It must be subtle sabotage from within!

(Some may counter this with Hanlon's razor [2]; Never attribute to malice that which is adequately explained by stupidity.)

[1] https://www.eff.org/

[2] https://en.wikipedia.org/wiki/Hanlon's_razor

wgx 9 days ago
I find the EFF site perfectly readable. Not sure what you’re experiencing but it looks fine to me.
misswaterfairy 9 days ago
I've noticed a lot of consultants I've worked with over the years do most, if not all, of these things.
pcloadletter_ 9 days ago
I left Microsoft a year ago because the group I worked for checked pretty much every one of the items on this list. It was wildly unproductive.
photonthug 9 days ago
All this is so normalized these days that many of the items on this list are referred to with reverence as best practice.

Plus calling these things "sabotage" isn't right even as a metaphor, and IMO confuses the issue. These people aren't on a third-party payroll, they are just self-serving.

No one is creeping into your office in the middle of the night. You invited them over, let them in, watched them piss in the fish tank, and then gave them a promotion and a raise. Now you're surprised everyone is lining up to fuck up the place? As usual the value judgements are just a distraction in matters of economics, look at the incentives.

oopsallmagic 9 days ago
"Never attribute to malice that which can be adequately explained by stupidity."
nerdponx 9 days ago
Except when there's a financial incentive. Never attribute to stupidity what can be adequately explained by greed.

Not sure if there's a name attached to this counter-principle, but it's just as important as the original in my opinion.

kmoser 9 days ago
> Deploy as infrequently as possible. Urge extreme caution about deployments. Leverage any production issue as a reason to “pull the brakes”.

Deploying infrequently doesn't necessarily sabotage things if it results in well-written and tested code before deployments, which tends to create stable systems. If anything, it's the opposite of "move fast and break things." If you want to sabotage things, urge frequent deployment and minimal testing.

kstrauser 9 days ago
Photo caption:

> This is from the 1994 music video Sabotage by Beastie Boys. The lyrics are mostly about technology leadership and developer productivity.

That caught me off guard. Well done.

lemonlime0x3C33 9 days ago
This was a depressingly accurate view of my limited experiences at large companies :(
hamstergene 9 days ago
Not sure about the entire list, but I've seen 4 of those many times. They are common techniques of impostor-employee to fool an impostor-manager:

1. A person who knows little of the topic assumes that talking a lot means knowing a lot. Hence long ChatGPT-like speeches. This has been my personal number 1 red flag since long before LLMs became a thing.

2. An incompetent manager is helpless in a situation when "everybody screwed up a little bit" as they don't pay attention to ownership or don't even understand its importance. Hence creating groups/committees to blur personal responsibility.

3. "Bring up irrelevant issues" is natural consequence of not understanding the topic very well, combined with forcing oneself to take part in the discussion. Pretty sure it's not even intentional. But either way, it's irrelevant from your point of view, but not from the the manager's, so it works.

4. Advocate caution at everything is because if the team screws up and attracts attention from higher ups, people at the most risk will be the lowest performers and the manager. It's a shared interest.

desio 9 days ago
Clever framing of the authors own biases. I'd argue that for at least some of these, the opposite behaviour would be the true sabotage.
ohyes 9 days ago
Let’s make a committee to discuss! we need all the key players involved, so let’s invite all of dev and QA, ~60 people for an hour long discussion?
oopsallmagic 9 days ago
What? You think the meeting was unnecessary? Well, you're the only one who disagrees with the outcome. Sounds like you're not being a team player. Let's have a meeting with HR tomorrow.
9 days ago
mike_hock 9 days ago
In fact, a sabotage manual should include the opposite action for each point. These are not the methods of sabotage, they're the methods of shrouding your sabotage in plausibility. It wouldn't provide you plausible deniability if doing the things on the list was never reasonable.
red_admiral 9 days ago
So cloud-based microservices for everything, then?
glitchc 9 days ago
I think tech is full of people like this. Moreover, they genuinely believe they are helping.
9 days ago
quantum_state 9 days ago
Very humorous … ironically, it’s happening in many companies…
eganist 9 days ago
It's cute, but in quite a few industries, a lot of these are driven by outside e.g regulatory forces that have proven to be necessary ("written in blood" etc), so the better question to ask is how many of these process encumberments can be streamlined e.g with paved road approaches.

Security and compliance benefit heavily from this approach, and I'm sure it can be extended elsewhere as well (architecture reviews etc).

thenthenthen 9 days ago
I recall the original OSS included some more hands-on techniques, like throwing your files (the ones you grind with) into the drawer instead of laying them down carefully. I wonder what the equivalent in software dev. would be. Throw files into folders with a lot of force? Ddos? The legitimacy of this document has been questioned, but it is surely food for thought. And don’t call me Cherly
oopsallmagic 9 days ago
The overarching point is "don't take care of your tools". So downloading 500 MB of dependencies and then letting them rot is a great example.
thenthenthen 9 days ago
(A pegboard or tool block could have easily mitigated any wrong handling of the tools?)
throwaway562if1 9 days ago
[dead]
coopykins 9 days ago
That list of sabotaged software development reminds me of my time at Oracle
julik 9 days ago
About 60% of that list checks out for a place I worked at.
nerdponx 9 days ago
Successfully carrying out even 1/3 of this list would scare off competent contributors who weren't completely desperate for a job.

The article kind of missed that detail, but this form of sabotage doesn't even need to be that effective to deeply sabotage the organization/product, it just has to be bad enough to scare off good talent and keep turnover high. The stuff in the "hiring" section makes it even worse by preventing good people from even getting in the door in the first place, but eventually a company like this would be scraping the bottom of the barrel for candidates even without deliberately bad hiring practices.

doytch 9 days ago
> Build complex “self-service” systems for stakeholders in other teams.

Is the sabotaging bit here the "complex" part?

davidgerard 9 days ago
Mandatory RTO, tech teams first.
fattybob 7 days ago
Wow that reads like every executive in any meeting
namegenbyai 9 days ago
nah, just introduce Scrum, Jira and Miro. Sprinkle with microservices and your're done. No one will question anything.
lelanthran 9 days ago
Some of these conflict:

> Encourage a complex dev setup: running a service mesh with a dozen services at a minimum.

...

> Build in-house versions of almost anything that's not a core competency.

So if you need functionality A, B, C ... H, what do you do? Do you build them all in-house or do you have 9 different services each providing the functionality required?

isidor3 9 days ago
You build 9 different services in-house, obviously.
dundermuffin 9 days ago
You don't need that functionality, you need Ruby on Rails and a cold shower.
Marietta040 8 days ago
[dead]
black_13 9 days ago
[dead]
namegenbyai 9 days ago
[flagged]
chrisandchris 9 days ago
behnamoh 9 days ago
@dang

maybe merge the threads?

jwilk 9 days ago
There are no comments in either of them.