Skip to main content

Corporate self-sabotage

CMSWatch has pointed to such an unbelievably funny classic: the OSS Simple Sabotage Manual from 1944 (OSS is the Office of Strategic Services, predecessor to the CIA). Check it out here.

You will learn how your cooperation is sabotaged:

(1) Insist on doing everything through "channels." Never permit short-cuts to be taken in order to expedite decisions.
(2) Make "speeches." Talk as frequently as possible and at great length. Illustrate your "points" by long anecdotes and accounts of personal
experiences. Never hesitate to make a few appropriate "patriotic" comments.
(3) When possible, refer all matters to committees, for "further study and consideration."
Attempt to make the committees as large as possible — never less than five.
(4) Bring up irrelevant issues as frequently as possible.
(5) Haggle over precise wordings of communications,
minutes, resolutions.
(6) Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
(7) Advocate "caution." Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on.
(8) Be worried about the propriety of any decision — raise the question of whether such action as is contemplated lies within the jurisdiction
of the group or whether it might conflict with the policy of some higher echelon.


The document also shows quite clearly that some allied spies must still be working for Germany's train company:

(6) Transportation: Railways
(a) Passengers
(1) Make train travel as inconvenient as possible for enemy personnel. Make mistakes in issuing train tickets, leaving portions of the journey uncovered by the ticket book; issue two tickets for the same seat in the train, so that an interesting argument will result; near train time, instead of issuing printed tickets write them out slowly by hand, prolonging the process until the train is nearly ready to leave or has left the station. On station bulletin boards announcing train arrivals and departures, see that false and misleading information is given about trains bound for enemy destinations.
(2) In trains bound for enemy destinations, attendants should make life as uncomfortable as possible for passengers. See that the food is especially bad, take up tickets after midnight, call all station stops very loudly during the night, handle baggage as noisily as possible during the night, and so on.
(3) See that the luggage of enemy personnel is mislaid or unloaded at the wrong stations. Switch address labels on enemy baggage.
(4) Engineers should see that trains run slow or make unscheduled stops for plausible reasons.

Comments

Post a Comment

Popular posts from this blog

Python script to set genre in iTunes with Last.fm tags

Now that I have started to seriously use iTunes I figured it might be nice to have the genre tag set in a meaningful way. Since I have a reasonably large collection of mp3s doing that manually was out of question - I wrote me a Python script to do that. There seems to be a large demand for such a functionality (at least I found a lot of questions on how to automatically set the genre tag) so maybe someone else finds the script useful. It is pasted below. General Strategy The basic idea is to use Last.fm's tags for genre tagging. In iTunes the genre tag is IMO best used when it only contains one single genre, i.e. something like "Electronica", not something like "Electronica / Dance". On the other hand dropping all but one tag would lose a lot of information, so I decided to use the groupings tag for additional information that is contained in the list of tags that an artist has on Last.fm. In the example above that would be something like "Electronica, Dan
15 comments
Read more

The misuse of the term "RESTful" in the Rails community

Today I went to a talk at the local Ruby on Rails group. The speaker was quite clueful. He had even implemented his own DSL to describe his business problem. Obviously, the guy was not a noobie in Ruby. However, what really turned me off was his usage of the word "RESTful". For him, it seemed to be a way to describe the inner workings of his application, like, say, "separation of concerns". RoR guys are generally not the most clueless people, but nobody in the audience challenged him about this. It seemed to be the generally accepted usage of the term in the Rails community. This made me think that DHH and Rails have done two things to REST: First, they greatly help to evangelize the term "RESTful" Second, they hijacked the meaning of the term and changed it from "architectural style" to "application architecture" As it happens I listened to a podcast from the Pragmatic Programmers on my way home. It was about the .Net Ruby implementati
2 comments
Read more

What is Multi-Tenancy? A closer look

Lately, I had a lot of conversations about multi-tenancy (MT). So I finally wrote up my thoughts on that term. In this post I will argue that MT is a value that depends on a continuous variable. Therefore, any statement about a system being “MT” can only be made in the context of the given requirements. It is not a property of the system itself . I will also show that perfect multi-tenancy is indistinguishable from single-tenancy (ST). MT is a value that depends on a continuous variable Imagine a step-function "ST-MT" (values are either 0 or 1) that determines if a given system is MT (1) or ST (0). That function will look like this: ST-MT = function (system, business requirements) Look at  the function’s arguments: the first one is obvious – the result will depend on the system itself. The second one is more interesting: it is the cumulative set of business requirements . Typically, these requirements will include: Resource sharing: systems typically declare
2 comments
Read more