Argue Over Artifacts

One of the principal ways technology and engineering teams end up wasting time is by getting stuck in a loop of ever devolving arguments over ideas. We even have a name for it: bike-shedding. In fact, in preparing to write this article I learned something new about bike-shedding even after I've been using the term for well over a decade - the actual name of it! Formally, this is called the Law of Triviality.

Wikipedia's Editors describe the law in a pretty helpful way for the average consumer:

After a suggestion of building something new for the community, like a bike shed, problems arise when everyone involved argues about the details. This is a metaphor indicating that it is not necessary to argue about every little feature based simply on having the knowledge to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change. [1]

Put another way, this law posits that as humans we seem to have a proclivity for picking the most mundane details when presented with the abstract problem. Software engineers, who work in a pretty remarkably abstract space day-to-day, are particularly prone to these kinds of shenanigans.[2] It is, accordingly, a frequent topic of discussion for us to figure out how to avoid aforementioned shenanigans whenever we can.

There's lots of advice out there for how to minimize bike shedding and the adverse affects it has on an organization. There are probably a lot of folks more qualified than I am on this front, but there's a strategy that I've been able to employ a few times to keep conversations moving in the right direction: arguing over artifacts instead of ideas.

Applying Cunningham's Law

I'm a huge fan of writing Tech Specs and Decision Logs for capturing solution design and directional reasoning, respectively. I even gave a talk on it a few years ago.[3] I couple this with a reputation for a heavy bias towards action. Folks at places I'm working tend to find out pretty quick that if I propose a plan and nobody tells me not to, I'm probably going to attempt it (within reason).

After having produced these documents (or, artifacts), I circulate them around the organization widely for feedback. When we're talking about solving a problem or picking a direction using one of these artifacts there are a few important bits of alignment that happen which help prevent bike shedding:

• The problem we're trying to solve, the goals/non-goals, and background is stated. We're not talking about any solution or direction without providing relevant context as to why and what's important about it.
• We talk about other things that we considered and rejected. This inevitably heads off the repeated back and forth when other folks think of those solutions and want to propose them.
• The full detail of the solution/direction is included. That should leave little to people's imagination in the way a verbal conversation might, so everyone can be highly confident you're talking about the same thing.
• Other folks (including yourself!) can go back and reference the reasoning, avoiding later bike-shedding about what you meant / considered.

All of these, when done well, can work together to head off the major causes of bike shedding: misunderstandings on what's important and what's not. Additionally, they're effective at applying Cunningham's Law within the context of a specific organization: folks are more likely to provide feedback when presented with a problematic solution than they are to a generic call for help.

Dealing with the 20%

As with all things, I consider an approach like this a success if it can resolve 80% of the problem and only leaves me with 20% of what I needed to deal with prior. That means that, even following this approach, you're likely to still have some bike shedding happen.

As always there this stems from misunderstandings about what is important. There are a few options that concrete artifacts give you for how to move forward.

• Understand the other side. Your level of detail in your artifact should spark a similar level of detail from any opposition. This is a huge opportunity to learn something new about whatever team / system you're working with.
• Explicitly de-scope their concern as a non-goal or anti-goal. Sometimes it helps to just state that we're choosing not to deal with a complication or concern right now so that nobody reading the document later assumes you did.
• Re-align on what's important and why. It's stated explicitly in the artifact you're looking at so it should be relatively easy to get everyone on the same page to move the conversation forward.
• Change your mind. Sometimes the quickest way to clear a bike shed that you don't care terribly much about is to just go with the flow. If it's important to one or more folks, not important to you, and just changing the specification would move things forward - then what are you arguing about?

Nothing will ever eliminate all the bike shedding, but the goal should be to move things forward. I've found these tactics super helpful for doing just that, and I hope you will to.

Notes

1. Law of Triviality, Wikipedia
2. Software engineers are certainly not the only ones in a field that's subject to these kinds of shenanigans. It just happens to be the field I know the best.
3. Move Fast and Decide Things - Datadog Dash