Simple Sabotage Field Manual – How to Destroy Your Organizations(butwhatfor.beehiiv.com) |
Simple Sabotage Field Manual – How to Destroy Your Organizations(butwhatfor.beehiiv.com) |
So spread dissent. Destroy fairness, no paid overtimes, everyone gets the same pay. Promote one group over other without merit. Hire most annoying extremists you find. Give leadership to vapid narcisits. One film company is great recent example of this.
This is from KGB and CIA manual. They would sponsor and train extremists. Still works long after soviet union is gone.
But the Simple Sabotage Field Manual was developed in and for wartime. It was meant to provide information to dissenters and occupied peoples on how to surreptitiously affect the war effort. The time scale is far different. You needed the factories and bureaucracies to slow down as soon as possible, not have a slow decline over the years.
The article feels like one of these chain mail jokes rather than a serious article, but anyway.
"Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions."
That bullet point list more or less describes Scrum.
An easy way to throw an effective team into disarray in tech is to waylay it with back channel requests and unplanned work. If you’re too busy fighting fires and working personal errands for disruptive managers and executives then you’re not delivering what your team is supposed to deliver.
The ‘proper channel’ isn’t a bureaucracy as described in the SSFM, it’s simply an ordered list of priorities with a gatekeeper.
Edit: as far as dogmatically adhering to this process goes, then any effective agile/scrum process will have a baked in allowance to handle the unexpected or adapt to change, rather than stubbornly stay the course.
> I don’t think it does unless you take a dim view of it and perpetuate the simplistic scrum-agile bad meme.
Look, the thing is, if you've worked in a load of different organisations, and lots of different teams, with other smart people and have never really seen Scrum done well, and have in some cases actively seen it inhibit the delivery of quality software, I think it's legitimate to start questioning the process. People - smart people - struggle to make it work effectively. Plus, 50% of software developers (UX, product management, QA, SRE, stakeholders, etc.) are worse than average: a process that top quartile people struggle to make work well, sometimes even under the most favourable of circumstances, is less valuable when broadly applied across the delivery professions as a whole, and over different industry sectors.
On the flip side, with any process being introduced, I think it's fair to spend some time, maybe 6 months (but it will vary, depending on the process), implementing that process fairly strictly. It does need time to bed in, and there will be areas of friction simply due to creating new habits or resistance to change rather than due to problems with the process during that time. You need time for those issues to shake out so that you can see how much value the process itself really delivers and where it can be improved. At the 6 month point you can review the process, implement improvements, and move forward. You can keep doing the same review/evolve process on whatever cycle you choose, and that way your processes are more in step with changes in the wider organisation (hopefully growth).
Your processes need to fit your organisation, your business model, your culture. So, by all means, you can start with a process like Scrum, but to be really successful with it you need to treat it as just that: a starting point. You need to evolve it to fit your business. We all like to mock cargo-culting and yet, somehow, Scrum and agile often seem to blag a free pass. I don't understand why, because they shouldn't get that free pass. Your processes need to work for your business, and they are always a means for delivering value and never an end in themselves.
But you also need to understand the audience and the context. This was targeted towards people under the nazi yoke, and in many instances, if you were found to be sabotaging things, you would probably be facing a firing squad very shortly. So the point here is to exploit weaknesses in the system that also have plausible deniability.
It's one thing to have checks on other people's work to deal with honest mistakes as quality control. A system set up to show that you mistrust the decision making of your senior workers is making it clear efficiency is never the goal. If I can't trust a senior to make sure a junior is doing well, they ain't senior.
The best term I've heard used for this is Minimum Viable Bureaucracy. You can't ever get rid of all of it, and you shouldn't.
I can't think of anything in the Scrum Guide that describes "insisting on doing everything through 'channels'" outside describing the roles and the division of labor between them. I mean, maybe in a really badly-run SAFe shop, this happens.
This + ramping up technical debt and seeding docs with outdated information would probably be enough to kill almost any project.
sic is Latin. ‘Spelling is correct’ is a backronym.
And you’d use it in writing to point out that the quoted thing is not an error or typo on the editor’s part.
> Advocate “caution.” Be “reasonable” and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on.
I do both of these things.
Do I want to destroy my organisation? No. I want to prevent miscommunication and haste from destroying it.
I dislike the popularity of this list for this reason.
Lets restate some: "Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions." -> "Insist on doing everything through 'short-cuts'. Never permit official channels to be taken in order to expedite decisions"
"Bring up irrelevant issues as frequently as possible." -> "Insist that things you don't like are irrelevant as frequently as possible."
"Haggle over precise wordings of communications, minutes, resolutions." -> "Argue that people are being caught up trying to be precise, leading to documents that are lacking precision"
"Insist on perfect work in relatively unimportant products" -> "Insist that products are unimportant and so sloppy work is ok"
"Hold conferences when there is more critical work to be done." -> "Claim that doing work is the only important thing and that communication is wasteful"
"Do your work poorly and blame it on bad tools, machinery, or equipment. Complain that these things are preventing you from doing your job right." -> "When you have the right tools and equipment, use them well, but then claim you are just really talented and that a master can work with poor tools."
"Never pass on your skill and experience to a new or less skilful worker." -> "Watch new workers like a hawk and never let them think for themselves."
The idea is interesting, the implementation in the article is tepid.
To paraphrase: "Don't attribute to malice that which can be adequately explained by covering one's ass".
Each of the items on the list are things you or someone else in an organisation does in good faith.
That is why these work.
When you do them in bad faith, you can stretch the timelines for things significantly while the responsibility for such a delay ends up so diffused among the bureaucracy that no one takes the blame.
“It’s just harder to get things done in a big organisation” as they say.
If you keep a lookout for these, particularly when they may be not in good faith you can head them off.
If a report has to have days of the week spelled out (“Monday” rather than “MON”, “percent” rather than “%”) but you also have a strict limit on character count due to space constraints, you end up with less precise wording in the report. Taking a step back and looking at it from the “if I wanted to actively sabotage this process, what would I do” might allow you to see good faith efforts that end up in bad outcomes.
The real issue here imo is, power structures. That's societal, and cultural. I sincerely doubt people use these to sabotage anything, infact the people who have control over such things are at the tippy top of an organization or place of governance (laws begat norms). So if that were the case um, you were screwed before you even started by who you listened to and who you worked most closely with. Not by some threat actor... IE we're doing it to ourselves by who and what we reward and it's only an evil plot if it really is being done by government agents or something, in which case we'll, see point #1.
Did they also employ these sabotage techniques in Japan?
Hilariously enough, lots of the things he says about production workers in factories is almost identical to stuff I see software people say about their jobs, so it's well worth a read.
My presentation of this was mostly cheeky; I am not usually this sarcastic.
Given that these are all common behaviours in real organisations they probably don't do that much overall damage. You'd do much worse by being effective, getting promoted and then making some really terrible but plausible decision that does decades of damage (like hiring some great marketers and going all-in on a risky venture that sounds good, but with little prospect of success). It doesn't take much effort, but once people are organised around a stupid goal it can take years to unpick.
Interesting that the meaning of "coup de main" here is the complete opposite of how it is actually used in French, where it means "helping hand". Used for informal and occasional situations. An example of a "coup de main" is when a friend gives you a few minutes of his time to help you move a heavy piece of furniture.
“The Art of Simple Sabotage” (2019) https://www.cia.gov/stories/story/the-art-of-simple-sabotage...
It's not terribly dissimilar to work-to-rule protests.
Just dug out a physical copy that I've got of this - a friend bought it for me a while back.
On a more serious note, this is a must read for developers and managers. It clearly identifies the paths that lead to disaster. You can see it as a list of organizational anti-patterns :)
I read anything that's referring to Germany or Austria as a group of people close to or on the spectrum. Perhaps this is why the saying exists "it takes one to know one" when thinking of Hans Asperger!
And you have to question, are govt budgets a representation of the characteristics of society, ergo are large military budgets reflecting the violent nature of a country?
I myself do not write this kind of software but I work regularly with people who write safety-critical components in things like airplanes, industrial manufacturing systems, and so on. If they decided, for example, they were too good to go through official channels, some very bad things could happen.
In fact, it kinda reads like someone just took the podcast and wrote a blog post on it. Not a critique, just an observation.
Updated Project Gutenberg link (multiple formats):
* 100% valid and necessary in some contexts (this is your point IIUC)
* ...but can nevertheless be used for organizational sabotage if overdone on purpose (point of the article)
* ...and lead to Dilbert hell if done because of bad incentives (the reason why this article keeps being so popular among office workers)And yet, do you not see how if _every single thing_ that your organization does went through this process, it would find itself in gridlock of decision making? How would your organization fare if it has to spend two weeks just do decide if the paper cups at the water cooler should have knurled or smooth bottoms. Or if the decision over whether you should implement a minor feature that would take an engineer half a day takes several months.
The manual isn't suggesting advocating caution when it's needed, it's advocating extreme caution when none is needed.
It is made so that it is hard to tell the difference between sabotage and being genuinely helpful. If you ask people to advocate caution when you know there is a good chance for an accident to happen, it is helpful. If you ask people to advocate caution even though the risk is low and everything goes well, it is sabotage.
Precise wording may be important in a legally binding contract, or when misinterpretation can have serious consequences. The way you sabotage is by doing that on points where it doesn't matter. For example, let's say you want to publish a memo telling people to bring back the encabulator to the store room after they finished using it, a common sense reminder. A saboteur can start arguing what is meant by "finishing", for example, what if it is needed an hour later, maybe suggest a logbook, special rules about overnight use, etc... when in reality, all that is needed it to remind Bob (who may be a fellow saboteur) not to be an asshole.
That's like 2000 man hours down the drain to produce a sentence I'm not even sure who is the intended audience for.
To me, what you described sounds like both Hell and entertaining Theater; Theater the first couple of times, Hell at 3+. It’s alternatively The Ninth Layer Of Hell if I have to provide input at any point for any reason.
Hell is paved with good intentions.
It is too easy for saboteurs like you to hide in larger organization...
It's not that these things are inherently negative - but it's where you can put sand in the gears of your org.
That sounds like the kind of activity that needs to be shut down to me.
So here we are at two schools: Unconsidered busy effort vs Considered intentional effort
He goes on this rant towards the end about Midwestern Values and I had been living in Indiana for about 5 years at this point, and nobody ever explained it to me so concisely and bitingly accurate what that perspective was. The short version in a picture of the story is the old man going up two flights on a rickety old ladder to check the roof, because he's been using that ladder for 30 years and it's "perfectly fine." You should get a new ladder, or you'll probably kill yourself!
The ladder is not perfectly fine, and each year he goes on using it the risk gets bigger. But we don't strive for perfection because we're used to "making do" with "good enough" tools. I could never make these my core values. As a professional, I need the freedom to bring my own tools, and as a full-time employee I'm going to need the right tools provided on the job site (because it's not in my contract to provide my own tools!)
As an app dev for non-profit corp whose primary business is not app development, I couldn't hack it here. I still live here, but I work for a foreign company now, on the open source project that I wish we could have adopted to make my life as an app dev a bit easier, or at least a bit more livable.
Your perspective on this classic document (that gets reposted at least once every year) reminds me of this struggle of my own.
The article seems to suggest that these things were lifted from the actual manual. Perhaps they cherry-picked these over things that are more relevant to commercial office work, but I would suspect instead that the statements which were excluded are less relevant.
If that’s the case, these are hardly things simply which the author dislikes. In the author’s own words: “If you are like me, many of these things sound surprisingly familiar.”
Perhaps the other methods as suggested by this comment’s parent are less effective (as an intentional means of sabotage) and so were excluded. It still seems worth it to be aware of these things and especially to look for them being perpetrated in bad faith.
You're doing this wrong. The list tells you not to "Never permit short-cuts to be taken in order to expedite decisions." Not and Never cancel out, leaving you with "permit short-cuts to be taken in order to expedite decisions"
Permitting shortcuts is not an insistence on always taking shortcuts. Your other "restatements" aren't any better.
At which point, it boils down to how willing an organisation is to fire someone for going rogue, or whether it’ll close ranks around the senior engineer for whatever reason/excuse and fire the junior.
If I can look at a board such that I don't have to ask in standup what's going on with a ticket (unless it's going much longer than expected), then we can use that for more valuable conversations.
The whole point of the standup should be to handle learnings like "we don't need this work" or "we're doing the wrong thing. Let's fix that!"
I have never formally formed a committee, but I often organized small one-off or semiregular circles to get differing opinions on some matter and/or to understand how to align interests. And I believe it paid off for me, usually in form of a better design or a useful shortcut around an otherwise long and dark path.
At some point, the cost of building not quite the right thing has to be weighed against the cost of spending literally millions deciding on what to build next.
Do you discuss the minutiae of what you guys can eat for lunch? Probably overdoing it.
Do you discuss the minutiae of a technical piece of equipment or software that is mission critical? Probably the right kind of effort to be as precise as possible.
All that matters is who has authority and the business both enforcing that authority and also making sure that authority is being used to accomplish business efficiently and not causing greater risk in the process. The rest just falls in to place. Or doesn't, and the business dies.
Ironically, you can sabotage any attempt to apply some useful agile (or scrum) principles in earnest simply by trotting out a few strawman arguments against it.
If an aspect of Scrum is inhibiting flow . . . junk it. But also first make sure that it actually IS inhibiting you, and it's not just highlighting a weakness or cultural flaw in your organization that you'd rather not deal with and pretend doesn't exist. Step 1 in moving beyond Scrum is to acknowledge the elephants in the room, feed them a peanut, and decide how to efficiently house them somewhere else.