Two tips for meeting survival in an entrenched bureaucracy | Opensource.com

Two tips for meeting survival in an entrenched bureaucracy

Posted 21 Jun 2010 by 

Rating: 
(3 votes)
Image by : 

opensource.com

submit to reddit

It might be a better world if we all worked in open, collaborative organizations where the best ideas win. But unfortunately, the reality is that bureaucracy still rules in all but the most progressive companies. We have a long way to go. The reality doesn’t always match the dream.

In the real world, we generate great ideas, propose elegant solutions, and then force them to run the bureaucratic gauntlet. “the best ideas win” becomes “the safest ideas win” (and then lose eventually) as they travel through the bureaucracy and its meetings.

These meetings are the favorite hiding place of two species of people I dread encountering. Learn to identify, manage, or avoid these bureaucrats, as they are the enemies of meritocracy.

Devil’s Advocates

The devil’s advocate was wonderfully defined by Tom Kelley in his book The Ten Faces of Innovation. Devil’s advocates make a habit of shooting down the ideas of others or offering critiques by starting with the phrase “Let me play devil’s advocate” (or something similar).

This phrase allows the bureaucrat to avoid taking personal accountability for the comments they are about to make. Because they are speaking for the devil rather than themselves, they can crush someone else's idea without feeling guilty about it.

Professional Meeting Attendees

It is easy to spot the professional meeting attendee because they usually look or sound hurried and exhausted, complaining about how many meetings they have that day and how much they have to get done. Woe is them, for sure.

The reality is they often don’t actually do the hard work of creating and building, but instead sit in meetings all day long. They are happy to offer sage advice and wisdom, but usually avoid taking on work.

In small organizations and startups, the professional meeting attendee species is rare. But it breeds rapidly in large organizations where meetings are plentiful and there is always someone else to do the work.

So what should good open source-minded workers do to improve things when they can’t escape these meeting bureaucrats? A few tips from me:

Tip #1: Avoid shark-infested waters

Most people, unless they are thrill-seekers, avoid swimming in shark-infested waters. Why? Because that’s where sharks have the upper hand. On land, I could run circles around a great white shark, but in the ocean, I’m chum.

Don’t be chum. Avoid swimming in professional meeting attendee and devil’s advocate-infested waters at all costs. Don't let them have the upper hand.

Both species love “weekly checkpoint and status meetings,” for example. If you are forced to attend these types of meetings, consider whether it would be appropriate to recommend some changes to the meeting structure.

One example: I’m a huge fan of Basecamp, which is a simple, collaborative system that makes it easy for everyone to be updated all of the time, reducing the need for in-person checkpoints. Conversations can be asynchronous, so they tend to progress more quickly and don’t have forced beginnings and endings like meetings do. Could you do your updates through a system like this as an alternative to weekly meetings?

If you must do the meetings, you may be able to still make the waters less friendly to the bureaucrats. Design thinking offers some great techniques for managing conversations so they stay productive and helping people build on the ideas of others rather than tearing them down.

Tip #2 is one technique I learned from design thinking I use in almost every meeting that turns unproductive.

Tip #2: When a shark attacks, punch it where it is sensitive

When a shark attacks, many experts agree that playing dead is a good way to end up dead for real. Instead, the best way to survive is to punch the shark where it is sensitive-- the eyes, gills, or nose.

Please do not punch any bureaucrats.

But when someone utters the words “Let me play the devil’s advocate for a second,” consider (if you dare) stopping them right there and saying something like: “If you don't like (challenged idea), perhaps you'd like to suggest a better one?”

One of two things will happen: the bureaucrat will be embarrassed and apologetic if they didn’t realize they were shooting down someone else’s idea. Or they’ll be angry at being called out. But either way, you will have hit them (hopefully subtly and politely) in a sensitive spot, and they will probably back off.

If you are worried that the person will hate you for calling them out, keep in mind that at least one person—the person with the idea the devil was attacking—and probably many others in the meeting, will love you for it.

It might be worth the tradeoff. With this one simple policing move, you make the meeting safer and more creative-friendly for everyone.

The reality is that it is tough being an open, collaborative person in an entrenched bureaucracy, and there are no panaceas-- only fixes and hacks.

Do you have things that have worked for you? How do you survive and stay productive in your bureaucracy? I'd love for you to share your ideas and tips.

submit to reddit

1 Comments

Michael Tiemann
Open Source Evangelist

Chris, if you like large-animal analogies analogies explaining corporate psychopathy (and therapy), you will love the latest book from Chip and Dan Heath, Switch. Here's an excerpt from my wife's Amazon.com review:

"Switch" is a book for anyone from the grassroots, to cubicle nation, to CEOs. Most of the examples consciously focus on people who needed to effect significant change with little power and few resources available to them. How could a low-level NGO employee make a difference in alleviating the malnourishment of Vietnamese children, in only six months? By finding "bright spots," identifying children who were thriving, finding out what their mothers were doing differently, and spreading that knowledge to other families. Stories like this are both inspiring and practical for all of us. This is really what I appreciated most about "Switch." I found myself taking notes that were not only about the book itself, but about how I could apply this knowledge to challenges I am working on. The Elephant-Rider-Path metaphor helped me see my own work in a new light. What more can a reader ask for?

I, too, found the book to be entirely consistent with my own experiences of change, both when successful (starting the world's first open source company) and not (convincing my co-founders that we should take 10% of our equity to buy Red Hat in 1995 instead of waiting 5 years for Red Hat to buy Cygnus with 10% of their equity).

Vote up!
0
Vote down!
0