Have you ever stayed silent about a product or process decision you disagreed with? Why?

Check out my MoT article, "Overcoming the Trap of Intellectual Conformity: Tips for Software Testers.

The piece draws on psychology, sociology, and systems thinking to explore how conformity shows up in development teams, and how testers are uniquely positioned to challenge it. Rather than offering another testing technique, you’ll explore how social pressure, organisational defaults, and professional roles shape the way teams make decisions, and how testers can use their capability of structurally permitted dissent to challenge flawed assumptions before they turn into costly mistakes.

What you’ll learn:

  • Why conformity without reflection happens even when the truth is obvious, and why that matters in software teams
  • How organisational roles and incentives shape which members of the team are expected to question decisions
  • What makes testers uniquely positioned to challenge flawed assumptions early
  • Why shift-left testing isn’t just about speed, but also about embedding dissent where it matters most
  • How to make a practical case for early tester involvement even in unsupportive environments

After reading, share your thoughts:

  • Have you ever stayed silent about a product or process decision you disagreed with? Why?
  • How does your organisation handle dissent: is it welcomed or discouraged?
  • Are testers included early where you work? What would need to change if not?
  • Do you think your team defaults to questioning or conforming?
8 Likes

Honestly, this is not just a great article, its a very important article and a cracking read :heart_eyes:. Its the unsaid truth in many an organisation. One of the human frailties is standing out in the crowd. There is a safety in agreeing with everyone because whatever happens, no-one is singled out for praise or criticism.

I’ve never stayed silent precisely as your article suggested, its my job to challenge any perceived quality risks. However, with all the challenging, someone needs to make a decision on how to proceed and either act on that dissent or provide a response that counters that dissent. Its very difficult if your dissent is countered in a way you disagree with not to conform. So I will normally respond for example with something like “I really think this is a big risk. If you disagree and proceed thats fine, but our job is to prevent risk so we’ll be adding this concern to our scope just to be on the safe side”. Which is a way of standing your ground but not falling into “I told you so” if you’re proven right.

Whilst I’m comfortable being the voice of dissent, I’m not in every quality conversation so I’m trying to coach my team in being that voice and feeling comfortable with it. Thats proving difficult for the reasons you suggest around hierarchy…they need to be comfortable dissenting to those in higher positions and standing there ground if they brush it off. Thats taking its time to reenforce.
Shifting left is also on similar journey. Sometimes we’re talking about quality early, sometimes not but its improving.

For us to succeed its a combination of the teams having the confidence to challenge quality early, influencing our standing but getting some of those challenges right and then shifting left will naturally enhance.

2 Likes

Hey Gary! Thanks so much for such a thoughtful and honest comment!

I do agree that dissent isn’t just hard and it can feel risky. Especially in many “hierarchical” companies where power and incentives aren’t “equally distributed”. Interestingly, this is what agency theory is describing well: in many organisations people who make the decisions (managers mostly) don’t have the same risks or costs as those who execute them. So, when testers raise a concern, they may be flagging not just technical debt or product risks but also decision-making asymmetry and that’s usually quite uncomfortable for hierarchies designed to preserve control :slight_smile:

That’s why I loved your point about framing dissent as risk. I think it’s tactically very smart since not only it connects to a decision-maker’s existing mental model (delivery, cost, and risk), but it also creates a paper trail for our safety. We’re not “being difficult” but rather give more $-related information for more informed decision-making. If a manager decides to ignore this, well, it’s his responsibility now and it’s very well documented :slight_smile:

And yes, coaching others for proper structured dissent is hard. Most people won’t do what the corporate handbook on “culture” says, but chances are higher they’ll do what they’ve seen someone survive (and excel) doing. Which makes your actions of showing dissend not just possible but valuable incredibly powerful.

2 Likes

I’ll read your article later but from the title, yes its quite common in my workplace.
The repetitive reasoning I’ve seen is time and budget constraints. More specifically, the way a person on management level does not like looking at issues in depth and prefers to jump to conclusions based on their own assumptions.

We do have a very good feedback cycle though. I recently brought up an improvement in our retro discussion process by having the team create tickets for retro points in JIRA. This way an issue gets tracked in a place which matters most to everyone. Following that, raising points repeatedly would eventually land them a place in the list of tasks and then they would see actual implementation.

1 Like