Ask HN: Strategies to rein in or prevent bikeshedding?

Nothing wrong with bikeshedding, as long as everyone bikeshedding knows they are bikeshedding. It only becomes a problem when someone asserts that blue “is the one true color” to paint the shed and doesn’t recognize that a shed can be other colors.

At that point, you reach an impasse that the other team members must then bend to that person’s opinions or leave.

In a meeting? "Let's take that offline."

In general? There needs to be one person with the authority to make the final call on the question. That one person needs to hear the bikeshedder, not until they stop talking, but at least until they start repeating the points they previously made. Then they make the decision, and they don't revisit it without sufficient new information.

If the bikeshedder can't accept that, then you need to get rid of them.

I think this question is too general, do you have some specific examples?

If someone is bikeshedding about what some other project that they aren't working on or going to do themselves, then: "That's a great/interesting idea, why don't you put it in an email/ticket and it can get prioritized in the context of the other deliverables for the project".

If it's about their own project/work, or how to tackle it, then: "Sure, whatever you think is a good idea, just go do it. I trust your judgement. Do it however you feel is best, let's look at it when it's done.".

Bikeshedding isn't always a bad thing (as distinct from talking too much, being all talk no action, being disagreeable / argumentative, which are). It can be used deliberately or constructively too... if someone has big project that they've spent a lot of time on, and are emotionally attached to, but you think the whole project is actually stupid or a bad idea... then you can stall it by telling them you support their goals, and want to work with them, but you just have some positive suggestions for this inconsequential aspect of their project that you'd like them to think/talk about at great length... and then will often get sucked into it, lose sight of driving their project forward, but not get upset or defensive about a confrontation.

The IEEE consensus process has some good ideas on how to achieve "rough consensus" even in the face of persistent objections: https://datatracker.ietf.org/doc/html/rfc7282 . Some takeaways

- Lack of disagreement is more important than agreement.

- Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.

- It's not a vote - one strong, well-reasoned objection carries more weight that dozens of "yeah looks good to me"s and vice versa.

I think it's important to not label concerns as "bikeshedding" at first. Or to label someone as a "bikeshedder" a priori. That's a shortcut to critical thinking and good way to shut down communication. All concerns should be heard, initially at least.

But not every concern should carry the same weight. Dealing with someone who repeatedly brings up the same minor concerns is exhausting. This requires a decision maker who can politely move the debate forward saying "We've noted your concern but we're not addressing it here ..." The group acknowledges the issue, the person raising the issue gets "I told you so" rights, but it's explicitly de-prioritized - no insults required.

The point of "taking it offline" is that they stop wasting everyone else's time with it - they only waste one other person's. Depending on how pathological they are, that may be enough to stop the bikeshedding, because 1) you've just told them they're going on more than the topic deserves, and 2) they can't hold everyone's attention, just yours.

It also effectively says "This isn't the most important thing for us to discuss right now".

But it's important that they have a chance to "be heard", both for their own psychology, and because even if they're a bikeshedder, they aren't always wrong. You just don't want to waste more of the group's time on giving them the chance to be heard.