I’ve written on how software testers think differently and play a different role to others in a technical team that has often created tension within teams. 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 alter of “ensuring quality”.
In these enlightened times, now “quality is now a team responsibility” that physical role of software tester is disappearing. But the mindset, that nit picking, that tenacity to say “but what if” and “but why” is still required. Even though an org no longer has quality engineers.The truth is someone else consciously or unconsciously has picked up this mantle. That person often has the title of devops or SRE and software engineer.
This mindset helps us all understand potential risks incurred as we design, develop, release and support. I loosely call people in tech with this mindset “whistleblowers”. Sure, traditionally, whistleblowers point out failings or illegal activity, often in situations where the majority either are unable or unwilling to speak out. But there’s a similarity here. We need whistleblowers in tech willing to raise concerns around potential failures and risk.
On the face of it, a whistleblower, has the same end goal as everyone else. That being, our consumers have a secure and reliable experience. That is, one that delights and enables them to do their jobs well. But it goes beyond that. Whistleblowers often think beyond the vision. For example, questioning assumptions on an end goal will be made not just for one, but for many in a consistent reliable way.
The whistleblower mindset look for risks and is kind of obsessed with failure. In a good way. They’re the ones that raise concerns about tech debt, or questions assumptions in design meetings or ask questions on standardisation of API errors, or raise concerns on unreadable code. They raise the concerns because they feel at some point this oversight will come back to haunt us all. 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 useful. It helps us better understand the tensions that exist. Once we understand and acknowledge, we can work to improve. For that reason I still support the dissection and analysis of this tension. But there’s more work to be done. Once we dissect, we must repair. We’ve got to find ways to support the vital work these folks do.
I believe, just as whistleblowers are supported by law, we in tech must create spaces for our very own whistleblowers.Just as whistleblowers are supported by law, we in tech must create spaces for our very own whistleblowers. Click To Tweet
Spaces were they feel supported and strengthened and listened to. Because trust me, there’s nothing worse than working in a way that ends up having you feeling undervalues, disrespected and unsupported.
Focus on Unity
There’s a lot to explore in this space, so let’s begin here today. One way to improve is to focus on what unites us. What we all have in common. Here’s a quick stab. I bet you can all think of other stuff too.
The reality is, that all teams by nature tend to be passionate about delivery quality. It could be that quality means different things to different people 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 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 that improve.
Many of us want to come to work and feel useful and somehow contributing to society. There’s nothing more demoralising than working on a feature or a product that’s retired before the consumer even sees it. If we work our butts off to deliver something, lets 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’s other things that come before that. Often we work so we can enjoy those things. And that’s totally ok.
We all love. We all feel pain. We experience despair and its counterpart hope. And we do this not in a 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 anything like me, you do so on a daily basis.
We rejoice in births, cry at deaths. We miss our loved ones, and embrace them when they return.
Maybe it’s in our similarities, not our differences will we figure out ways of working. Ways that takes into account and accepts differences, knowing that our humanity unites us more than what divides us
I updated this to version 2.0 after I published. Changed photo and some wording. Sentiment hasn’t changed.