Supporting the whistleblowers

Whistleblowers

I’ve written before on how software testers think differently and play a different role to others in a technical team. In the past, a typical non testing view of the role was gatekeeper. This didn’t turn out so well. The history of quality and software testers is littered with corpses of gatekeepers and independent arbitrators of quality. Corpses that had full accountability without authority to enact, and so died on an altar of “ensuring quality”.

Roll on to today. In our enlightened times, “quality is now a team responsibility”, and the physical role of a software tester is disappearing. But the mindset, that nit picking, that inclination to query and ask “but what if” and “but why” is still required and still happens. You may find now, in a company with no software testers, someone else will consciously or unconsciously pick up that mantle. That person often has the title with Devops or SRE, or architect in it. Typically a role that offers a system wide view of the service being delivered.

No matter who does it, this mindset is vital. It helps us understand potential risks incurred as we design, develop, release and support. I loosely call people in tech with this mindset “whistleblowers”. Traditionally, whistleblowers point out failings or illegal activity, often in situations where the majority are unable or unwilling to speak out. Whistleblowers in tech raise concerns about potential failures and risks.

On the face of it, a whistleblower has the same end goal as everyone else. That is, to give our consumers a secure and reliable experience. One that delights and enables them to do their jobs well. But it goes beyond that. Whistleblowers often think beyond that vision. They think not only of how a feature may be used, but how that feature may be used by many all at the same time. They think about the impacts of failure and how that might impact our ability to respond reliably.

The whistleblower mindset looks for risks and is kind of obsessed with failure—in a good way. They’re the ones who raise concerns about tech debt, question assumptions in design meetings, ask questions on standardisation of API errors, or raise concerns about unreadable code. They raise the concerns because they feel this oversight will come back to haunt us all at some point. They raise it now when action can be applied.

Tension within Teams

This mindset can and does create tension within teams, though. As the rest of the team drives to the release cycle, it almost feels like these people swim against the tide of rapid release. The whistleblower opens their mouth, and often, the response in the meeting is a collective eye roll.
In the past, I’ve felt that exploring these divisions has been worthwhile. It helps us better understand the tensions that exist. Once we know and acknowledge, we can work to improve. There’s more work to be done. We’ve got to find ways to support these folks' vital work.

Just as whistleblowers are supported by law, we in tech must create spaces for our very own whistleblowers—spaces where they feel supported, strengthened, and listened to. Trust me, there’s nothing worse than working in a way that leaves people feeling undervalued, disrespected, and unsupported.

Focus on Unity

One way to improve is to focus on what unites us—what we all have in common. You may be surprised about some of these.

Quality

My experience is that most people are passionate about quality. The nature of that quality differs, though. A software engineer may value the quality of maintainable code, while an ops person values the reliability of a system. A product owner values a compelling feature. So, while there’s a disparity in how that value may play out in a team, there’s no denying that we all value quality to some degree and want to see it improve. We can use that to unite us and appreciate each other's perspectives.

Valuable Work

Many of us want to come to work, feel useful, and somehow contribute to society. Nothing is more demoralising than working on a feature or a product that’s retired before the consumer sees it. If we work our butts off to deliver something, let's at least make sure it gets delivered.

Outside of Work

Many of us have loved ones outside of work, be they family, friends, or a close community. And while we may enjoy our work, there are other things that come before that. Often, we work so we can enjoy those things, and that’s totally okay.

Our Humanity

We all love. We all feel pain. We experience despair and its counterpart, hope. And we do this not in nice, clean linear graphs but more like up and down, round and round, loop the loop way. In us, we have the best of us and the worst. We live and deny that reality all the time. If you are anything like me, you do so on a daily basis.
We rejoice in births and cry at deaths. We miss our loved ones and embrace them when they return.
Maybe our similarities, not our differences, are what help us find ways to work better together—ways that acknowledge and appreciate our differences.

I updated this to version 2.0 after I published it. I changed the photo and some wording, but the sentiment hasn’t changed.