rdschneider

Faced with a long transpacific flight, I loaded lots of reading material onto my new Kindle paperwhite. I’ve found Project Gutenberg to be a great source for interesting free books. One of the titles I selected was the Simple Sabotage Field Manual. After all, you never know when you’ll be called upon to derail a train or cause a dam to burst.

In WWII, the United States Office of Strategic Services put out this entertaining and surprisingly well-written book. It was designed to help civilians figure out ways to quietly but effectively disrupt Axis daily operations in occupied Europe. But as I was reading it, I noticed that the section on tactics for damaging meeting and conference efficiency in Axis wartime industries bears an uncanny resemblance to the ways that I’ve seen IT committees – both standards bodies and internal – operate. See if any of the following tricks to destroy productivity sound familiar:

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

In the coming weeks, I’ll be writing a series of blog posts about SOA governance – a responsibility that’s particularly susceptible to ‘sabotage’. I’ll supply some suggestions to keep things moving along and help avoid this unfortunate outcome.

Comments are closed.