Ben Northrop


Decisions and software development


If you Speak Up, Speak First!


(2 comments)
March 2nd 2016


As a developer, there are often situations in which the team discusses big decisions and where there are opinions on each side. Consider this scenario...

The team is re-architecting a core service, and is considering whether to go with design A or design B. Both have pros and cons (in terms of scalability, performance, etc.) and the team is uncertain which route to go. From prior experience, you have solid reasons to prefer design B, but as the new guy on the team, you decide to let the conversation play out before you chip in your 2 cents.

Fail! Wait...already? Yes. What many people don't realize is that early opinions matter incommensurately, and if you feel strongly about a given decision, you need to chime in first. The reason for this is called a cascade. To see how it works, consider again your team, and their individual preferences before discussion:

You Dana Al Fran Bob Carlo
Preference (pre) B B A B A B

As you can see, before discussion, there's a 4-2 split among the team in favor of the design you prefer, design B. All things being equal then, you would expect the team to arrive at a consensus for this design, but in reality, this consensus is anything but assured - it depends highly on how the discussion plays out. Imagine the team goes around the room and one-by-one states their preference and then explains their reasons. Al and Bob are always the most out-spoken, so they go first:

Al Bob
Preference (pre) A A
Stated Preference A A

Both Al and Bob, who also happen to be the most senior developers, go on the record supporting design A and then give their reasons (which are sensible, by the way). Now, it's Carlo's turn. His preference is for option B, but he also is new to the team, so he begins to reconsider. Despite the fact that Carlo has a good reason for option B, he wonders, "is it worth it to go against the grain here"? Not confident in his own opinion and fearing a little blow-back from Al and Bob, Carlo decides its safer to just go along with the consensus opinion and states a preference for option A. And here starts the cascade!

Al Bob Carlo Dana Fran You
Preference (pre) A A B B B B
Preference (stated) A A A A A A

It's important to note that not only did Carlo switch his preference to option A, but he also withheld a valuable bit of knowledge that only he had in favor of option B - knowledge that could have been persuasive to others. In any case, by the time it gets to Dana, Fran, and you, it seems as though the proverbial ship has sailed. There is solid support for option A, and there's not much sense in talking it out further.

But wait...didn't the team, collectively, prefer option B? What happened here? Why did the group decision succumb to the preference of the few who spoke first? This is the power of the cascade - people go along with the observed actions of others, even when these actions contradict their own private beliefs. This can happen for a couple of reasons.

First, people naturally like to agree with each other. This is so much the case that when we do, we actually both end up feeling better about ourselves ("Oh, you like React? I like React! We both must be exceptionally brilliant people!"). When we happen to disagree, depending on the social context, there can be a cost - others might actually think worse of us for our dissenting opinions. This is real, although it depends highly on the team environment and on the group leaders (we all know tech leads who are more or less accepting of divergent opinions). When people defer to the preference of a person with more seniority, against their own preference, this is called a reputational cascade, and it happens often.

Second, as people consider the preferences of others, they begin to discount their own reasons for favoring or opposing a given decision. This is called an informational cascade. "Wow, 100 people liked this song? Maybe I'm wrong, it probably is good!". As the cascade rolls over people, it gets ever stronger, as people withhold not only their original preferences but also information that they uniquely held that would be relevant to others in making the decision. This happens in plenty of real-world instances (for example, juries), and to sometimes alarming effect.

The moral here is probably not exactly what the title suggests, although it is true - speaking first will likely give you more persuasive power. More constructively though, we should try to structure our team discussions with an awareness of cascades. Get all the information on the table before allowing people to state their preferences. And if junior people are worried about going against the grain, let them speak first, or just have everyone write down their preferences on a piece of paper, and tally the anonymous votes. I've done this often, and it can make a boring decision fun(ish).

Anyway, I'd be curious to hear what you have to say. Does this happen on your teams? Do the outspoken people on your team have inordinate sway over team decisions?

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I'm a Distinguished Technical Consultant for Summa and have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben at summa-tech dot com.

Got a Comment?


Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (2)

March 08, 2016
Tallying the votes before revealing them is quite useful -- my team uses it CONSTANTLY for doing quick difficulty estimates. (Time estimates are particularly good for this technique, because they tend to be one-dimensional. Which architecture to use might have an infinite number of possible answers.)

However, this does suffer from one major problem: some people will be quite sure of their answer while others have a weak preference and some more just have no idea.

I\'m not sure what to do about this. A system where you write down your preference and also how strongly you feel about it seems overly complicated.

I wish I had a good answer here.
Ben
March 09, 2016
Thanks Michael! I\'ve been on teams that have done this as well - independently come up with estimates, and then shared them - and, agreed, it does work well. Something like the Wideband Delphi method. Good point about decisions that are multi-dimensional - a simple vote is not always nuanced enough to get to the \"right\" solution.

And great point about the strength of preferences. There are always experts whose opinions should probably be heeded more.

Anyway, thanks for the comment.