In the 1950s, psychologist Solomon Asch ran a deceptively simple experiment, one of whose trials you can watch on YouTube. Each session included a group of people who were all part of the experiment, but only one was a genuine subject. The others were actors instructed to give clearly wrong answers. The task was to match one line drawn in ink on a display to another of the same length. When the actors unanimously gave an incorrect answer, over a third of the real participants conformed, choosing the same wrong answer despite the correct one being obvious.
This wasn’t about ignorance. It was about conformity without reflection, in which many people "go along to get along" without considering the possible negative consequences
What does this have to do with software development? More than we like to admit.
How many defects do you think are due to conformity without reflection?
How many times have you seen a barely testable feature get pushed into development, not because it was ready, but because everyone else nodded along? Or maybe you’ve watched product and engineering teams proudly ship a feature that, deep down, nobody really believed would bring value to users?
I’ve been one of those developers. I once led a full redesign of an app, not because it solved a problem, not because we had research or feedback, but because “the product manager thought it was due." We shipped it. And then we rolled it all back a month later when key user metrics tanked. We did not take into account the needs of the user base, many of whom were on older mobile devices. The new version, packed with animations and parallax effects, ran painfully slowly for them. Long story short: nobody questioned the redesign before development.
Looking back, the problem wasn’t lack of skill or effort. It was conformity without reflection.
And this kind of conformity isn’t limited to features, it’s also baked into our processes. Teams stick with suboptimal approaches because “that’s what mature teams use." They enforce asynchronous code reviews even when they slow down collaboration, without any clear evidence that they improve quality. Challenging these defaults feels risky until someone else does it first.
Human conformity is a feature, not a bug… most of the time
The tendency to conform isn’t a flaw in our thinking, but rather an evolutionary feature. In ancestral environments, disagreeing with the group could mean exclusion, conflict, or even death. Survival depended on belonging. So our brains are wired to prioritise conformity over accuracy, even when the stakes are low.
Unfortunately, this tendency gets reinforced long before we enter the workforce. Edward de Bono, creator of lateral thinking, repeatedly criticised traditional education for promoting what he called “vertical thinking”: solving predefined problems within fixed constraints. Standardised education rewards compliance, not curiosity. By the time developers graduate, most have learned to optimise within boundaries, not to question them.
Donald Schön, in The Reflective Practitioner, also notes that professionals tend to default to “problem-solving mode” rather than reflecting on how problems are framed. In software teams, that habit is magnified. Developers are hired to deliver, not to doubt. They’re evaluated on their ability to build, not their ability to challenge given tasks and problems. What's more, the very thought processes required to design and code effectively tend to make the developer use a narrow lens.
Organisational structures often reinforce unthinking compliance
Conformity without reflection is also baked into most organisational structures. Developers typically operate within hierarchies, and hierarchies entail task execution without reflection. Even in agile organisations, it’s common to see KPIs and OKRs focused on “doing more,” managers tracking burn-down charts, and individual development plans (IDPs) created for developers to nudge them continually to deliver more features. All of this emphasises output over inquiry, unintentionally signalling that questioning the work is not part of the job.
Amy Edmondson’s research on psychological safety shows that people won’t speak up even when they see something wrong, unless they believe doing so won’t cost them status or trust. In teams where questioning is not culturally protected, silence becomes the rational choice. And so, social conformity becomes the default.
Software testers can serve as the needed voice of dissent
Here’s where the role of testers becomes uniquely powerful.
Neither conformity nor dissent are personality traits. They’re situational. Most people conform or stay silent until they see someone else challenge the group. Sociologist Mark Granovetter described this using the idea of a “conformity threshold”: each person has a point at which they are willing to dissent, depending on how many others they see dissent first. Some people will speak up immediately. Most need to see a few others question the norm before they feel safe to join.
That’s why it matters so much who is expected, permitted, and supported to challenge assumptions early.
While developers are often under subtle pressure to conform, testers are structurally expected and socially permitted to doubt, investigate, and challenge. Philip Selznick wrote that when roles become institutionalised, they carry normative expectations: not only in what you do, but also in how you behave. For testers, that expectation is to find flaws.
Even when organisations impose KPIs or OKRs on testers, they usually reinforce this identity: test coverage, number of bugs found, regressions avoided. Unlike developers, testers are rarely punished for raising doubts. In fact, they’re expected to interrupt the consensus, and that makes a huge difference.
Because testers are expected to question, they often act as the first visible dissenters, helping to lower the dissent comfort threshold for everyone else. What starts as a single question can create permission for an entire team to think more critically.
Deciding when to speak up, when to stay quiet, and when to take a middle way
Of course, not every organisation gives testers the space to dissent early, or at all. Some are expected to focus only on defects after development. Others are held accountable for quality without having any influence upstream. In those environments, asking better questions can feel like stepping outside your role, or even risking job security.
Each tester has to decide what they can do, what they want to do, and whether their current environment allows it. But when the space does exist, or can be created, one of the most practical and effective moves is to shift left. Arguing for shift-left is often easier than arguing for dissent itself. The argument can be framed in practical, risk-reduction terms that managers often understand intuitively. For example, earlier involvement is easy to support when you mention Boehm’s cost-of-change curve and prove it with collected data on the time spent and delays caused when tasks are sent back from testing to development. These are familiar growing pains, and shift-left offers a familiar solution, one that just happens to embed dissent exactly where it’s most valuable.
It's not always fun being the person who is seen as "bringing the bad news." The more comfortable you can become with being uncomfortable at times, the better off you will be. You might be surprised at how many people are grateful that you step out and tell the truth as you see it.
Shift-left testing enhances teams' ability to cope with complexity
When introduced successfully, shift-left testing becomes far more than a process change.
Yes, it shortens feedback loops and catches bugs earlier. But its deeper value lies in embedding dissent early, right at the point where flawed assumptions may take root. When testers are involved in ideation, they’re not just protecting quality. They're protecting epistemic integrity, meaning that we stay honest about how we know what we know. We make sure our beliefs, decisions, and conclusions are based on valid reasoning, solid evidence, and a willingness to question assumptions. Testers help make it acceptable to challenge the problem before the story is even added to the sprint.
This need for diversity in thought isn’t just philosophical, it’s systemic. As cybernetics teaches us through W. Ross Ashby’s Law of Requisite Variety, systems must contain enough internal variety to handle the complexity of their environment. When testers join early, they bring crucial cognitive variety. They think differently. They ask different questions.
To wrap up
The more real options a team can see, not just variations within a frame, but different ways of framing altogether, the better their chances of making decisions that actually fit the complexity of the environment they’re building for.
In a room full of people who are primed to conform, dissent is the most valuable thing you can have.
For more information
- How to Benefit from Being Uncomfortable, Cassandra H. Leung
- Social influence: Compliance and conformity, Robert B. Cialdini, Noah J. Goldstein
- The need to belong: Desire for interpersonal attachments as a fundamental human motivation, Roy F. Baumeister, Mark R. Leary
- Effects of group pressure upon the modification and distortion of judgments, Solomon Asch
- Status Quo Bias in Decision Making, William Samuelson, Richard Zeckhauser
- Anomalies: The endowment effect, loss aversion, and status quo bias, Daniel Kahneman, Jack L. Knetsch, Richard H. Thaler
- Threshold Models of Collective Behavior, Mark Granovetter
- Behavioral study of obedience, Stanley Milgram
- The person and the situation: Perspectives of social psychology, L. Ross, R. E. Nisbett
- An Introduction to Cybernetics, W. Ross Ashby
- The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies, Scott E. Page
- Psychological safety and learning behavior in work teams, Amy Edmondson
- Toward A Theory of Conversion Behavior, Serge Moscovici
- Creative problem solving as a result of majority vs minority influence, Dr. Charlan Jeanne Nemeth, Joel Wachtler
- Lateral Thinking: Creativity Step by Step, Edward De Bono
- The Reflective Practitioner: How Professionals Think in Action, Donald Schön
- Leadership in Administration: A Sociological Interpretation, Philip Selznick
