“The reward of being accepted is often greater than the reward of winning an argument, or looking smart, or finding truth. Most days, we’d rather be wrong with the crowd, than be right by ourselves,” (James Clear, Atomic Habits).
As we enter an era of political correctness and overt conflict minimalization, it can be hard to know when it's time to speak against the crowd. If you examine the Asch Conformity Experiment, you will see that even in the face of a trivial and obvious comparison, humans succumb to the temptation of fitting in with their perceived social equals in a group against their better judgement.
Consider a complex problem space like software development. On a given day, you may be discussing feature requirements or an elaborate architecture/algorithm problem. The complexity has elevated astronomically from simple comparison, and so does the motivation to agree with the group. You have a lot more explaining to do (and therefore potential conflict) if you disagree.
It's possible to introduce waste during software development through simple timidity. If someone on your team isn't comfortable sharing their ideas, you miss out on a lifetime of experience and knowledge that could improve your solutions. If you fail at building something, and someone saw it coming, you've wasted valuable time.
One way we can avoid introducing this type of waste during development is honest inspection. This requires us to be bold. Honest inspection can uncover your faults; let everyone know that you've been doing something wrong this whole time. However, we will frequently trip over lackadaisical implementation without it. Then we fall into the trap of having introduced unnecessary waste without considering all of the readily available options. This sort of waste should offend your sensibilities. What is the point of making improvements if their agency is going to be muddied and hindered by waste?
The worst thing that can happen when you challenge the norm to fight for your ideas in software is that you find out that you’re wrong, or your idea didn’t fit exactly in this area. This sort of wrongness is an exceptional learning tool. Exploit your own creative ideas to improve your software, or your understanding. Be humble. Be bold.
If you’re curious about when you should challenge the norm, there are a few simple things that I try to do. Firstly, ask yourself “Will I regret having missed my chance to say this down the road?” If the answer approaches “Well, we might waste time going down the wrong path if I don’t speak up,” we already know we should do something now, as we hate wasting time.
Remember to ask “Why” when something doesn’t completely make sense. Sure, this can expose you as being less knowledgeable, but that’s okay! You’ll almost always learn something when you dig into the reasoning behind a requirement or implementation. Also, from a team perspective, someone exposing their ignorance should be seen as a positive! It's a demonstration of a varied background, and allows for education. Another way people can respond is to say “We’ve always done it this way”, which is exactly where you should cue in to challenge the norm. That’s not a reasonable justification to continue down your current path.
Speaking up and standing out from the crowd is no small task. We should view it as a responsibility. Something to aspire to, but not for its own sake. Instead, for the sake of the success of our complex projects and group efforts.