I wouldn’t say using the term “bikeshedding” is a guilty pleasure of mine, but it’s certainly a lazy indulgence. For those unaware, it is a term that within software engineering has achieved wide usage as a way of calling out non-productive feedback. The challenge is the usual situations where the term gets used have ambiguity about which party is at fault. Thus as a manager, when you hear members of your team dismiss feedback as bikeshedding, it is your responsibility to dig in and ensure that they have sought out the other parties’ perspectives, and communicated their reasoning. On the flipside when your team is being accused, take it as a guide that they need to try and raise the quality of their feedback.
For those unfamiliar with the term, the best description is the email that popularized it, from Poul-Henning Kamp to a FreeBSD email list, posted at http://bikeshed.com/. What he describes is this process around a decision being critiqued:
- Experts think deeply about all options and tradeoffs and put forward a proposal.
- Proposal is reviewed by committee of non-experts.
- Rather than focus on the deep tradeoffs, committee spend their time voicing objections and making counter-proposals only on trivial details.
This is bikeshedding. Within companies, the “experts” are individuals or teams who have made a decision. The “committee” are stakeholders who don’t agree. Their bikeshedding generally takes two forms, either focusing on trivial details of the implementation that don’t meet their need or proposing a completely different solution — “why can’t you just do X instead”.
Everyone bikesheds occasionally, for the reasons that we like to have our opinions heard, but do not have time to gain expert knowledge in every area that impacts us. In this original formulation, it seems clear the problem is always with the bikeshedders. They are the ones making low value noise, and so need to hold themselves to a high standard of feedback that has high utility in giving the experts reason to reconsider their decision. Therefore it seems fine to call out their behavior when they don’t.
The flip side of this is that we all see decisions being made by other parties that not only impact us, but some or all of the following are also true:
- We were not consulted as stakeholders in the decision
- The decision does not seem deeply considered
- The decision and its rationale was not communicated well, or at all.
To see a real example of that, see this Quora response from the inaugural bikedshedder. It seems…. not that unreasonable.
When we call out details and how they impact us, and get told we are bikeshedding, it is pretty frustrating to not only be heard, but to be dismissed. Now maybe what we are asking is totally wrong, but that gets to the core challenge in this situation: how much work and time should everybody be putting into decisions to make sure all stakeholders are heard, to deeply consider all possibilities and their tradeoffs, and to communicate that rationale to all stakeholders in a way that they can understand on their terms? Obviously, that is an impossible standard to hold for all decisions — organizations would never get anything done. So what it comes down to is, this is really a debate about how much time and stakeholder communication needs to go into making a decision, which is context dependent.
That’s what the conversation needs to be about. So how to do that?
When your team is accusing others of bikeshedding: Coach them that when making decisions, we need to do a better job of engaging as many stakeholders as we can, ideally getting their alignment, but at minimum communicating what we are doing and why. When we don’t do this, and later have stakeholders complaining, we have to understand that even when their complaints are not well founded, the fact that they are complaining means we have missed. So be patient, explain our reasons, and maybe think about how we want to change our process for similar decisions in the future.
When your team is being called bikeshedders: Coach them to give the experts the benefits of the doubt that they have considered our preferred solution. Especially remember the engineering adage — “bring requirements not solutions”. And like all good behaviors, this applies when we think the expert team is sloppy about how they make or communicate decisions. We never know for sure, so assume good faith, patiently ask them to explain, and if they are willing to do that, accept they have shown enough judgment to own their decision.
But more than that, remember that “bikeshedding” is negatively laden but used in situations where it is ambiguous who has caused the problem. Thus it’s a term best avoided.