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?
