Strategic use of bikeshedding

I read Albert Cory’s article “Bikeshedding for fun and profit” with bemusement. Anyone who has participated in group decision-making has at least one story to tell about it, even if they don’t know the term. Cory presents ways to avoid bikeshedding and ways to use bikeshedding to “hide” controversial topics.

I can’t advocate for the use of bikeshedding to distract from more significant topics. That’s damaging to the long-term health of the community and people’s trust in you. But it occurred to me that I’ve used bikeshedding to shape discussion before. I just never explicitly thought of it in those terms.

Painting a bike shed can be an excellent icebreaker. When I present a draft for review and edit by a group, the only thing worse than having everyone tear it to shreds is everyone having no feedback at all. I’ve found that leaving in a deliberately not-great trivial piece will attract enough attention to get the conversation started. Once people are comfortable discussing the trivial part, we shift the conversation to the more substantive pieces.

The danger here is two-fold. First, that people will get stuck on the bike shed and not shift to the important matters. I’ve found that with some gentle pressure, you can get enough of a consensus to call it done and move on. Let them go for a little bit and then reign it in. The other danger is that no one will take the bait and you end up including the bad part in with the rest. You need to make sure that the bad part is at least acceptable. In both cases, I’ve found clunky wording to be a good fit, as opposed to bad ideas.

There’s another benefit. Even if all the group does is finally settle on a color for the bike shed, leaving the rest of the document untouched, they now have a sense of ownership. They contributed, however trivially to the document, so they can claim it as theirs. This helps tremendously when it comes time to follow through and execute on the plan.

This post’s featured photo by Alexander Shustov on Unsplash.

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share