Bike-shedding
There is an apocryphal story about a management committee meeting with three items on the agenda: design a power plant, build a bike shed for employee use, supply refreshments for the Welfare Committee. The story goes that the first item was approved in a few minutes. The second item turned into a forty-minute discussion about what color the shed should be and who should get to use it. The third item it was decided, after deliberation, did not have enough information to make a decision, so it was added to the next planned meeting’s agenda. The vast majority of the time in the meeting was spent on the least consequential of the agenda items. This is bike-shedding.
Bike-shedding is mostly used to describe prioritization problems and meeting management, but it applies to nearly all areas of product design and development. Many times, the largest, most important topics are complicated or expensive, intimidating to offer opinions on. The color of a bike shed? Far less significant, and easy to offer a reasonable opinion. People like to feel valued and important, offering an opinion reinforces that.
Product management tools, issue trackers and a good manager can help with this category of problem. But, engineers love talking about details and if there are weeds, we can and frequently will wander off into them.
One client in the early phases of product design had a great solution for this category of problem. They created a large visual X-Y graph on one wall. They used colorful tape to create the axis. The X-Axis represented significance. The Y-Axis represented cost (mostly in time, but dollars were considered also). These axes were the correct ones for them, but different ones may apply to your business.
Every idea was weighed on these scales. One person was running the board and they would write down each idea on a sticky note and then stick it on the board in the relative position where it would belong.
This allowed a quick visual way to see what was important and what was expensive, that is, where should they be spending their time and attention. And, if someone had an idea, their idea was validated in that it got a sticky note just for it and a place on the board. Frequently, that satisfied even the worst ideas. Some contributors who pushed hard for their ideas ended up being quick to prioritize their ideas behind others once they could see the cost/significance ratings.
Techniques like this help us see where we should spend our resources and if done well, help to unify the vision of the team on what are the most important tasks.
How do we judge the significance of an item? It really depends on the priorities of the organization, but here a few questions that can be asked:
What happens if we don’t get this right?
How easy is it to change?
Who is affected by this?
For many web-based projects, the cost of changing something is very low. Live A-B testing is an example of this. If you are uncertain of which way to go with a design decision, you can go both ways, route traffic to each of them and measure the results. Let user behavior drive the decision.
Even most hardware products these days support over-the-air updates, so firmware and software can be modified after the product has shipped. This means that the physical layout of buttons or size/style of hardware is more important to get right than the software. Getting the software close enough, or getting the most important features done, with upgrades following, is sufficient to ship.
The important follow up to that idea is the question “What happens if we don’t get this right?” There are times where getting the software wrong ruins the product, so it cannot be entirely neglected. But, again, be aware of which features are dominating your software development resources. If you are spending weeks designing a use-once configuration screen, you may be wasting your time. However, if the screen is the initial log-in experience or the daily use work-flow, it may justifiably deserve your attention.
For the lower priority items, they should not be ignored, they just shouldn’t dominate your time. Going back to the bike shed example, let’s pretend that bikes are being stolen, workers are angry, and morale is suffering. The importance of the shed increases, sliding it’s sticky far to the right. The relative cost (compared to building a power plant!) is still quite low.
The best thing to do in these cases is to do something. Make a decision and go with it. If you are running the meeting, pick a color and move forward. If someone has a strong opinion against your choice, adopt their suggestion immediately. The color is relatively unimportant.
Or, and this is what I would actually do in this case, don’t even include the bike shed on the agenda, or mention it just as a decided item not an item for discussion. The power plant deserves all your time. The principle here is that if you bring something up in a meeting you are inviting a discussion about it. Many things deserve discussion. The color of the bike shed does not.
None of this is to say that details are unimportant. The details of the power plant are very important and deserve many meetings and much discussion. That is an important thing to get right.
Spending your time and energy in meetings on the most important tasks also sends a critical message to the other people attending the meeting: you value their time. Have you ever walked out of a meeting after listening to a debate or, perish the thought, arguing about the color of the bike shed? That’s an hour that you will never get back.
Going back to the original example and following the maxim ‘You are what you do’, we would determine that the company is a bike shed company that dabbles in power plants. Our resources are finite, time and money for startups, established companies, and individuals are precious. Spend them deliberately.