This is the third post in a series of our takes on bike shedding. After understanding the origin story and how we might lose our empathy in our crusade against bike shedding can we still glean anything valuable from the infamous bike shed?
You’re probably reading this post because you feel like there’s some room for improvement on your team. As a Test Double agent, I relish the opportunity to don my detective hat and magnifying glass. Please join me on this journey. This topic runs deep and wide, encompassing pretty much the entire field of behavioral science—in which I am not an expert!
I have, however, been on a lot of teams that each had their share of strengths and blind spots. I often find that our blind spots lie in our communication habits and our tribal assumptions. Rather than defining a bike shed as a complete waste of time, I suggest we reframe bike sheds as representing our team’s blind spots. In this frame, a bike shed could be the right thing to discuss right now, but only if the team makes a conscious and intentional decision to do so. We examine our values and hopefully hear from people who wouldn’t have felt comfortable speaking up unless they are asked. A healthy team will outperform a demoralized team every time. More to the point, I’m willing to bet that you would prefer working on a healthy team rather than a dysfunctional one.
Wherever your team is on that spectrum, I hope this post helps you shed a little light on your project’s bike sheds.
Communication is the lifeblood of every team. Ask these questions of yourself and maybe even open the floor to your team to help you examine your communication.
When the salt begins to flow it should trigger your bike shed detector. Anxiety, stress, and fear might be warning you that people feel like they aren’t being heard. Too much negativity is a clear signal that your team is out of alignment.
It’s normal for folks who like to get things done to balk at adding another meeting to the calendar. To an extent, this is probably a healthy pressure against wasting time. Unfortunately, your team may not be feeling enough healthy pain to push back because we humans tend to acclimate to our environment. This bike shed is one of the classics because most developers have no problem rallying around the cause of fewer meetings. I believe it’s still worth mentioning because the feeling of busyness so quickly lulls us into a false sense of security that we are getting things done.
It’s important to acknowledge when we are talking about the present context versus any other. Understand that team members may bear scars from similar situations. This isn’t a license to de-legitimize others’ experiences, because they may simply want to spare this team the pain they’ve experienced. Psychologists suggest that we may not be consciously aware of how our feelings affect our thinking. Identify and make explicit the contexts involved. This brings the bike shed into clear focus so your team can have a focused productive conversation.
Everyone has a different perspective. By default most people only consider their own. You can identify this bike shed in the wild by noticing language differences. Often you will hear a repeated word or phrase. Write it down and continue listening. When you have a few repeated words and phrases from each point of view, you can compare. If you notice that one person is talking numbers and data and the other person speaks of feelings and style, you have just identified a potential disconnect. Maybe there are actually multiple conversations here, and everyone needs to get on the same page to understand whether there is even a difference of opinion at all. In keeping with the theme, perhaps one person sees only the size of the bike shed where another is more concerned with the curb appeal. The team should have both of these conversations with everyone making an effort to understand the distinctions between each topic.
In his book, Peopleware, Tom DeMarco describes what he calls a jelled team.
A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts.
Sometimes a team is jelled to the point of perfection. Or at least that’s what it seems like from the inside. In reality, the team may have developed tribal assumptions and blind spots. It’s great to have a confident team, but we should always be on the lookout for things to improve. Don’t let a bike shed’s cloud of fear, uncertainty, and doubt slow down your team. Ask questions like these instead.
Fear of the unknown is a dangerous influence on your team’s behavior. I’ve seen pull requests stagnate because the team doesn’t feel comfortable shipping something when it feels risky and there isn’t a mitigation strategy. Consider embracing NoOps as a step toward reducing the pain of shipping.
When developers take on a task, they are putting in the investment and so should be trusted to make the final call. If not trusted, then why are they on the team in the first place? Take note of the amount of chatter around seeking validation. Is there a hidden power structure? The team should also feel confident about using data to test their assumptions. Your team could have plenty of healthy discussion about which data to collect and how to use it, especially when you consider the alternatives. Some teams might not collect any data and become paralyzed with the fear of not knowing the impact of their changes. Others may collect lots of data and not know how to use it, or worse, not have much confidence that it is the right data.
When key stakeholders are unavailable, developers may be left without any sense of the strategic position of their code. This includes insights into your customer’s key features and most visible parts of your product. Stakeholders here run the gamut from customer support, marketing, executives, and data scientists. Everyone here has a lot of valuable information. Managers everywhere struggle to provide a healthy pipeline of relevant feedback for devs from the rich variety available in their organizations.
Maintaining a healthy flow of communication between all stakeholders is key if you want to avoid wasteful rework. Developers who understand the business needs can make better technical decisions. Helping strategic leadership understand technical constraints empowers them to plot a profitable course for the company. Everybody wins!
Sometimes we get so wrapped up in our opinions about quality that we forget to respect the autonomy of fellow developers. If the code works and passes all the agreed upon tests, does there really need to be an extended discussion about alternative approaches when the work is already done? You have an ideal bike shed in your mind. It’s probably an awesome bike shed, but remember that you weren’t the one who put in the work to build it.
Teams may have deep cultural dysfunctions. These will require lots of dedicated time and effort to fix. Everyone has human flaws, and your team is no exception. Some individuals will try to actively harm others. This is a sad reality. However, I believe in the vast majority of cases people would rather get along and do good work. Take time to reflect on the pain your team is experiencing. Discuss it openly and honestly. Then you will unleash your team’s ability to heal, emerging as better humans and coworkers than before.
The bike shed’s long and checkered history has a lot to teach us. Perhaps the greatest lesson is that we can push a metaphor way past the limit of usefulness. Though I may be guilty in this very post, I hope the illustration just makes the point more sticky. If we get too comfortable with the status quo, we will miss opportunities to grow. I hope identifying your bike sheds and encouraging healthy conversations around them improves the productivity and quality of life for your team.
Thank you to Joshua Wehner for collaborating on this post.