How to derail any meeting

TL;DR: How a WWII field manual can help modern knowledge workers identify those inadvertently sabotaging your organization today.

2 minute read

The Office of Strategic Services “Simple Sabotage Field Manual” was declassified and subsequently made its way around the internet. The book, published in 1944 by the predecessor to the CIA, had headings like “Encouraging Destructiveness.” Still, it was the section on “General Interference with Organizations and Production” that caught my eye, not because I intend to sabotage any organization shortly, but because I see so many modern knowledge workers unintentionally doing to their organization precisely what the OSS playbook described doing to adversaries some 70 years ago. Here are a few of my favorite[^emphasis-mine] from the list:

Insist on doing everything through “channels.” Never permit shortcuts to be taken to expedite decisions.

Haggle over precise wordings of communications, minutes, and resolutions.

Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.

Advocate “caution.” Be “reasonable” and urge your fellow conferees to be “reasonable” and avoid haste, which might result in embarrassment or difficulties later on.

Be worried about the propriety of any decision — raise the question of whether such action as is contemplated lies within the group’s jurisdiction or whether it might conflict with the policy of some higher echelon.

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.

Make “speeches.” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of personal experiences.

Bring up irrelevant issues as frequently as possible.

In making work assignments, always sign out the unimportant jobs first.

Insist on perfect work in relatively unimportant products.

Do any of those tactics sound familiar? Are there any of those you haven’t experienced in a meeting at least once and experienced this week? While I doubt your coworkers are double agents for the now-defunct OSS, there’s something to be said for the fact that the behaviors that were once used as means of espionage are now all-too-common antipatterns in day-to-day corporate America.

That got me thinking: what additional antipatterns would the OSS add to that list if they were writing that field manual for modern times? The common thread, as I saw it, was to maximize meta-discussion — the discussion about having the discussion you need before you can do the work you set out to do.

With that in mind, here’s how I’d update the Simple Sabotage Field Manual for today’s workplace:

If you’ve called the meeting, don’t take audio-visual needs into account until after the meeting’s scheduled to start. Don’t include call-in information in the meeting invitation. Spend the first ten minutes of the meeting working through any presentation and teleconferencing needs.
Assume the meeting will start 3–5 minutes late, and show up accordingly. Once settled, bring up issues already decided in your absence.
Insist on introductions, go around the table providing each attendee with the opportunity to describe their role and how it relates to the meeting. This is especially true as latecomers enter the meeting, providing additional opportunities to interrupt the discussion.
If on a conference call, enable join notifications so that discussions are automatically interrupted whenever someone joins or leaves. Even better, when someone does join, pause the conversation to ask, “Who just joined?”.
Don’t do any work outside the meeting. Use the meeting as a forcing function. Meetings are when your team does work. Even better, if you’ve called the meeting, don’t send any materials in advance, or if you’re an attendee, restate issues addressed in preparatory materials (which you didn’t read).
Insist that the group table the discussion to take a step back and define with specificity what you’re solving for, the scope of the project, and the particular meeting’s goals. Assert that the group won’t be able to reach a consensus until those questions have been answered.
If the discussion gains momentum, ask open-ended, process-based questions like what does success look like?, what’s our success metric?, or how do we measure our success metric?.
Whenever you sense a decision nearing, insist that the group forego decision-making until stakeholders not initially invited to the meeting can have the opportunity to weigh in.

Conclusion

The OSS’s Simple Sabotage Field Manual was written to help operatives disrupt enemy organizations. But the tactics it describes are all too common in today’s workplace. By recognizing these antipatterns, we can work to minimize their impact and make our meetings more productive.

Originally published January 15, 2016 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit