Bike-shedding

Thanks to Richard Shotton for pointing me at Russell Davies' description of 'bike-shedding' as a way to describe the way that significant amounts of time get wasted in corporate meetings by focusing on trivial issues that attendees know more about. Worth quoting in full:

'I was once in a meeting about a software project. It was like meetings I’d been in my whole life – aimless, drifting, pointless. Then suddenly one of the developers said “Hang on we’re bike-shedding”. “Ah yes” said another “we are”. The meeting immediately shifted gear. Decisions were quickly taken or dismissed and we all got back to work. I was a little shellshocked so I went back to my desk and googled “bike-shedding”. Reading that wikipedia entry was one of the things that convinced me that the practises of agile, user-centric software and web development will eventually displace those of most creative industries. “Bike-shedding” comes from a story by C. Northcote Parkinson (he of Parkinson’s Law). He tells the tale of a committee that has to approve the plans for a nuclear power station. Since they know very little about nuclear power stations they talk about it briefly and then just approve the recommendation put in front of them. Next they have to approve the plans for a bike shed. They all know about bike sheds. They’ve all seen one and used one. So they talk about the bike shed for hours, arguing about construction methods and paint choice and everything. This is why bike-shedding is also known as The Law of Triviality: “ members of an organisation give disproportionate weight to trivial issues”. I’m sure this observation is familiar to you. Most branding conversations seem, to me, to be one long bike-shedding session. It’s not so terrible, it’s human nature. The difference is that software people have identified and named the pattern. That naming is an organisational hack that allows them to break out of it and get on with something more useful.'

Excellent.