Comment by gilbetron | Hacker News Reader

Comment by gilbetron | Hacker News Reader

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.

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.

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.

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...

Part of the purpose of the document is to sabotage surreptitiously. If you always take shortcuts and something gets messed up, it's easy for people to see that you were the cause. However, if you always insist on doing things through the proper channels then it's a lot harder for people to see that you're the problem or argue against your methodology.

> 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.

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

"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.

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.

The point is the sabotager probably has a pretty good idea of whats irrelevant and what's critical for the purpose of the organisation they are trying to prevent (or at least the former, which is all that's strictly necessary to do this).

Reply on news.ycombinator.com