[HN Gopher] Simple Sabotage Field Manual - How to Destroy Your O...
___________________________________________________________________
Simple Sabotage Field Manual - How to Destroy Your Organizations
Author : stanrivers
Score : 228 points
Date : 2023-07-23 02:11 UTC (20 hours ago)
(HTM) web link (butwhatfor.beehiiv.com)
(TXT) w3m dump (butwhatfor.beehiiv.com)
| loopdoend wrote:
| Sounds exactly like the Government of Canada to me.
| vlark wrote:
| The entire section "General Interference with Organisations and
| Production" is a perfect description of how academia works.
| roenxi wrote:
| The lack of sources and case studies leaves an interesting
| possibility open. This document might actually be fiction the
| opinions of someone who didn't like meetings as opposed to an
| effective guide.
|
| 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.
| jt2190 wrote:
| Link to the declassified "Simple Sabotage Field Manual" document
| at the top of this article:
|
| "The Art of Simple Sabotage" (2019)
| https://www.cia.gov/stories/story/the-art-of-simple-sabotage...
| rightbyte wrote:
| I always knew agile was a CIA plant gone ammock. (/s?)
|
| 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.
| broast wrote:
| This doesn't add up to me. I thought "People over processes"
| was a pillar in the agile manifesto.
| psunavy03 wrote:
| "Individuals and interactions over processes and tools" does
| not mean no processes and tools. It means the processes and
| tools used in the organization should facilitate and enhance
| individual interactions. Everything on the right is still
| there, it just is used to enhance and promote what's on the
| left.
|
| 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.
| XorNot wrote:
| And yet the only conversation in my daily stand up is a
| request to make sure the tickets are all in the right column
| on the board and deep consternation if the ticket has to be
| changed or _gasp_ dropped in some way.
| ebiester wrote:
| I think the two are separate.
|
| 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!"
| samstave wrote:
| The thing I hate about Chain Mail is that regardless of how
| many links you may have in the Mail - your defenses are still
| susceptable to piercing by Spear Phishing. :-)
| jurynulifcation wrote:
| I see that someone has already mentioned that it is indeed
| "amok". However, another slight correction: "/s" is an internet
| tone indicator for sarcasm. "sic"(?) stands for "spelling is
| correct." When simply stated, as a parenthetical like so "caret
| (sic) and a stick" then it means the writet is confident their
| spelling is correct. When posited as a question, as in "ammock
| (sic?)" then it expresses the authors' non-confidence in their
| spelling and is also an invitation for correction.
| hairofadog wrote:
| I read their "/s" to mean sarcasm as in "haha, I don't really
| think agile is a CIA thing" and then their question mark to
| mean "but maybe?"
| jurynulifcation wrote:
| Oh fair. I had not considered that interpretation.
| ljm wrote:
| > "sic"(?) stands for "spelling is correct." _(sic)_
|
| _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.
| rgblambda wrote:
| To be fair, if you've seen a senior team member write a badly
| worded Jira ticket containing a large amount of possibly
| unnecessary work, then foist it upon a junior (Or just describe
| what the want in a call and let the junior write it) because
| they knew it wouldn't stand up to scrutiny in Backlog
| Refinement, you would be a bit more in favour of that rule.
| hibikir wrote:
| If you have malicious senior developers that foist work on
| people that would never be approved when the full team is
| there, your problem is not using one methodology or another:
| your problem is in hiring and firing.
|
| 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.
| ljm wrote:
| That kind of behaviour might only present after a long
| tenure at the organisation, once such an engineer sees
| themselves at the top of the pecking order.
|
| 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.
| psunavy03 wrote:
| Half of the problem with implementing Agile is people like this
| who insist that shittily-implemented Agile is actually Agile
| implemented accurately, and then railing against the ensuing
| straw man.
|
| 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.
| genocidicbunny wrote:
| The article might be a joke, but the subject of it -- the SSFM,
| is a very real thing. The whole point of it is to guide people
| on how to exploit the inherent inefficiencies in large
| organizations, so of course a lot of the concepts are probably
| familiar to us.
|
| 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.
| [deleted]
| ljm wrote:
| I don't think it does unless you take a dim view of it and
| perpetuate the simplistic scrum-agile bad meme.
|
| 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.
| bartread wrote:
| I agree with your second point but...
|
| > 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.
| TheCleric wrote:
| I would also add that, in my experience, anyone who is
| involved with and doesn't buy into the process (any
| process, not just Scrum) will be indistinguishable from a
| purposeful sabateur.
| ljm wrote:
| IIRC this might have been covered in The Five
| Dysfunctions of a Team, in terms of a lack of commitment.
| patmorgan23 wrote:
| On the cargo culting point. I just want to add. You can
| actually get pretty far by apeing what you've seen before
| even if you don't totally understand. You should definitely
| try and understand and figure out why it works but you can
| still get by without it sometimes.
| psunavy03 wrote:
| This is all true. No one should dogmatically follow Scrum
| or any other framework. But the trouble is there's two
| kinds of people who deviate from it. Those who actually
| know what they're doing and can move beyond it, and those
| who are scared of or threatened by a new normal and want to
| kneecap 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.
| isityouyesitsme wrote:
| Scrum as a concept doesn't matter. Agile as a thing doesn't
| matter. Team structure doesn't matter.
|
| 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.
| ljm wrote:
| Yeah that's a totally fair point, and one I took as given
| because it's hard to discuss something like this if you
| need a disclaimer on facilitating organisational change
| every time the topic comes up. After explaining for years
| that no, doing agile doesn't mean daily status reports and
| endless meetings, you start to consider that maybe these
| arguments are offered in poor faith and you want to focus
| on the good faith nuance.
|
| 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.
| pydry wrote:
| If developers do unionize this is essentially a recipe for the
| kind of industrial action that, unlike striking, would be very
| effective.
|
| This + ramping up technical debt and seeding docs with outdated
| information would probably be enough to kill almost any
| project.
| psd1 wrote:
| It's a loan word, but "amok" is the consensus spelling in
| English
| [deleted]
| pixelfarmer wrote:
| "The Happy Worker" is a documentary that mentions exactly this.
|
| https://www.youtube.com/watch?v=PzzYGRXfAaI (trailer)
| mlrtyc wrote:
| Worked for python-dev and many other software projects.
| ojkelly wrote:
| I think the comments here are missing the point.
|
| 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.
| chayesfss wrote:
| [dead]
| GartzenDeHaes wrote:
| Or you could just use ISO 9001
| https://en.wikipedia.org/wiki/ISO_9000.
| kramerger wrote:
| Now I suspect some managers I know work for CIA.
|
| 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 :)
| LightBug1 wrote:
| We do.
| brakmic wrote:
| Goes in a similar direction:
| https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
| beaker52 wrote:
| > Haggle over precise wordings of communications, minutes,
| resolutions.
|
| > 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.
| marginalia_nu wrote:
| I've seen cases where 100+ people were required to attend
| multi-day meeting marathons to agree on the perfect sprint goal
| formulation, a negotiation held hostage by a few pedants that
| were never quite happy with the exact wording.
|
| That's like 2000 man hours down the drain to produce a sentence
| I'm not even sure who is the intended audience for.
| lcnPylGDnU4H9OF wrote:
| Honestly, it sounds like there will still be a few pedants
| who disagree with the phrasing of this new Commandment.
|
| 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.
| perrygeo wrote:
| The flipside is seeing thousands of hours wasted building the
| wrong thing because people couldn't be bothered to
| communicate properly. "Getting the words right" turns out to
| be a fundamental step for producing successful software - not
| because the words themself are directly important, but
| because it's a reflection of a robust mental model of the
| problem.
| marcinzm wrote:
| There is a difference between what is perceived as
| effective communication and what is actually effective
| communication. More communication for the sheer sake of
| more communication almost never means more effective
| communication or coordination.
| marginalia_nu wrote:
| To be clear, these wordings has no impact on what was to be
| built, that had already been decided at a separate set of
| meetings. This goal setting meeting was sheer process.
|
| 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.
| GuB-42 wrote:
| I think that's the reason why this list is so clever.
|
| 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.
| [deleted]
| npteljes wrote:
| I don't think the simple symptoms lead to the illness in this
| case. Which is to say, even if you do these things, you might
| do them in a well intended way, and with an overall positive
| impact. Lawful good and lawful evil are both lawful. Law in
| itself doesn't indicate evil (or good, for that matter!).
| chewz wrote:
| > Do I want to destroy my organisation? No. I want to prevent
| miscommunication and haste from destroying it.
|
| Hell is paved with good intentions.
|
| It is too easy for saboteurs like you to hide in larger
| organization...
| abwizz wrote:
| some might argue that organzations can't grow large without
| them
| beebeepka wrote:
| Similar to how systematic overeating leads to body growth
| abwizz wrote:
| true
|
| and, advancing the metaphor, fat bodies arguably have
| other abilities and constraints than slim ones i.e. they
| are suitable for different applications
| genocidicbunny wrote:
| > Do I want to destroy my organisation? No. I want to prevent
| miscommunication and haste from destroying it.
|
| 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.
| dmbche wrote:
| The point is that by stretching you "zealousness" further, you
| can affect negatively your organisation without being blamed
| directly.
|
| It's not that these things are inherently negative - but it's
| where you can put sand in the gears of your org.
| bigbacaloa wrote:
| Those who these things are generally well meaning but need to
| be shut down anyway.
| beaker52 wrote:
| So how exactly are we supposed to do things then? Just start
| putting in effort and communicate vaguely for maximum
| directionless effort?
|
| 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
| psd1 wrote:
| I think both of you are holding the idea of ranking
| organisational strategies on a linear scale. But what works
| for a tech startup might not be good for operating a
| chemical plant.
| marcinzm wrote:
| The worst cases of pointless busy work I've seen were when
| everyone follows an out of date plan that they know is out
| of date because the effort to change it is too high.
| prox wrote:
| Everything exists on a gradient. Your goals are valid and
| methodology probably as well if you meet them.
|
| 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.
| praptak wrote:
| That's the point of this document. To enumerate types actions
| which are: * 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)
| pluto_modadic wrote:
| by Dilbert hell do you mean Kafkaesque office politics? or is
| there like a specific kind of Dilbert hell?
| praptak wrote:
| The office reality presented in Dilbert is hell on earth.
| There are some references to hell in Dilbert but I don't
| think they are very specific.
| gilbetron wrote:
| I like the idea of this, but many of the list items come off as
| things the author doesn't like.
|
| 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.
| pluto_modadic wrote:
| they were not things from a modern author. They're direct
| quotes from the office of strategic services (so old that it's
| from before OSS was the CIA). Quick google would have helped
| you know that. https://www.cia.gov/stories/story/the-art-of-
| simple-sabotage...
| yebyen wrote:
| I bet a lot of people already know Technology Connections, but
| I like to bring up the first video of his that I ever watched
| at a time like this - that's right, the one about heat pumps!
|
| 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.
| mcpackieh wrote:
| > _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"_
|
| 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.
| lcnPylGDnU4H9OF wrote:
| I haven't seen this before and I can't verify with the link to
| the actual field manual because it's a 404. Does anyone have a
| PDF of the actual manual handy? (Edit:
| https://en.wikisource.org/wiki/Simple_Sabotage_Field_Manual/...
| Scroll to section (11a).)
|
| 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.
| pickledish wrote:
| I think I agree with you --- phrases like "irrelevant issues"
| and "more critical work" are so subjective, that everyone can
| read along with this and agree with it, but it's not actually
| saying much, since the agreeing on WHAT is relevant or critical
| has always been the hard part
| btbuildem wrote:
| "Irrelevant" and "critical" are far from subjective in a
| business organization. The goal is clear: make more money.
| Everything either contributes or detracts from that goal.
| pessimizer wrote:
| Far from subjective, but when they are based on speculation
| about how particular fixes and features will be received by
| customer and market, and ultimately affect the bottom line,
| "irrelevant" and "critical" can be uncalculable.
| mgenelin wrote:
| I did a lightning talk back at devopsdays Minneapolis in 2016
| titled "Updating Classic Workplace Sabotage Techniques" based on
| the book published on the topic. 5 min video goes through all the
| techniques:
|
| https://youtu.be/t8pSMr5WpWE
|
| My presentation of this was mostly cheeky; I am not usually this
| sarcastic.
| baz00 wrote:
| The most effective methodology is to implement one of the loosely
| agile based methodologies like SAFe Agile. Then hire consultants,
| none of whom have ever actually managed a software team, to make
| sure everyone follows the process down to the last letter. This
| decreases efficiency to the point that the organisation is no
| long able to do productive work, there is no ROI and the staff
| are all burned out from spending 20 hours a week in zoom meetings
| and filling in JIRA tickets.
| [deleted]
| dumpster_fire wrote:
| This just reads like a basic description of every large
| organization out there with humans in them.
| genocidicbunny wrote:
| That's kind of the point of the SSFM -- to clue people into the
| simple sabotages they can participate in by more or less just
| following the rules.
|
| It's not terribly dissimilar to work-to-rule protests.
| blitz_skull wrote:
| Jocko Willink recently talked about this very topic on his
| podcast: https://www.youtube.com/watch?v=7nU2qkRUk5o
|
| In fact, it kinda reads like someone just took the podcast and
| wrote a blog post on it. Not a critique, just an observation.
| turtleyacht wrote:
| The ebook link on the blog 404s.
|
| Updated Project Gutenberg link (multiple formats):
|
| https://www.gutenberg.org/ebooks/26184
| Thoeu388 wrote:
| It is more effective to change people, not processes. This way
| organization stays dysfunctional long after you leave.
|
| 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.
| genocidicbunny wrote:
| Depends on your goals. If your goal is to effect a long-term
| attack on an organization, then yes, you want to introduce
| systemic issues that will fester.
|
| 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.
| romusha wrote:
| The guidance is basically the workplace bible in many developing
| countries. Good job, you sabotage yourself
| smallnix wrote:
| > Don't order new working materials until your current stocks
| have been virtually exhausted, so that the slightest delay in
| filling your order will mean a shutdown.
|
| Did they also employ these sabotage techniques in Japan?
| disgruntledphd2 wrote:
| The Lean/Deming approach is _incredibly_ different, and I
| strongly suggest if you 'd like to know more to read "Out of
| the Crisis".
|
| 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.
| marcinzm wrote:
| They did everywhere which is why the last 3 years have included
| massive ongoing cascading supply chain shortages across the
| world. It's very efficient as long as nothing ever changes too
| much too quickly which tends to be the case in manufacturing
| outside a pandemic but is much more rare in software.
| 29athrowaway wrote:
| The most modern version of this sabotage manual are MBA programs.
| darkclouds wrote:
| > Amongst its responsibilities was frustrating the German war
| effort, and to that end, it wrote a short set of "best practices"
| - the Simple Sabotage Field Manual.
|
| 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?
| ndsipa_pomu wrote:
| A lot of theses tactics appear to be used here in the UK with
| regards to installing cycle infrastructure, low emission zones
| and liveable neighbourhoods.
|
| Just dug out a physical copy that I've got of this - a friend
| bought it for me a while back.
| GuB-42 wrote:
| > Sabotage varies from highly technical "coup de main" acts that
| require detailed planning and the use of specially trained
| operative...
|
| 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.
| thumbuddy wrote:
| A lot of the comments here seem to be about discussing legitimate
| sabotage of a company. Meanwhile the article seems to mostly be
| about using common sense to be efficient and how a lot of "best
| practices" are actually horrible for that. So some satire.
|
| 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.
| 0ct4via wrote:
| The original SSFM, from which the title of this post is derived:
| https://www.hsdl.org/c/abstract/?docid=750070
| smodo wrote:
| I've definitely seen most of this going on in management teams.
| Especially the forming of committees as a way of bike shedding.
| 'We are clueless about the problem but we do know how to make a
| list of other clueless people.'
| samus wrote:
| Committees can be a good fit for issues where the exact shape
| of the solution does not really matter as long as it aligns
| with constrains set up ahead of time. It frees up leadership
| from bikeshedding to focus on more critical issues and can
| smooth over company politics by ensuring that all relevant
| parties' opinion is taken into account.
| praptak wrote:
| Forming committees is mostly useful for avoiding
| responsibility. If I make a bad technical decision then I get
| flak. If I organize a committee to justify that decision then I
| might even get points for "leadership". Also, if the decision
| is bad then I'm not personally responsible.
|
| To paraphrase: "Don't attribute to malice that which can be
| adequately explained by covering one's ass".
| zelphirkalt wrote:
| Although there could be legitimate hope, that one of the
| other people is not clueless and will bring up important
| points. Not necessarily only "covering ones ass", but
| probably also a responsible thing to do, when making an
| important decision. At least, if the list of people actually
| includes technical people who have experience with the
| matter.
| inglor_cz wrote:
| Just yesterday, someone quoted Paul Hamming on the fact
| that scientists who have "open doors policy" are more
| successful long-term.
|
| 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.
___________________________________________________________________
(page generated 2023-07-23 23:03 UTC)