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 really 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 alter of “ensuring quality”.
Roll on to today. In our enlightened times, “quality is now a team responsibility” and that physical role of 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 be 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 all 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 either are unable or unwilling to speak out. Whistleblowers in tech 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 enabling our consumers have 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 impacts of failure and how that might impact our ability to respond reliably.
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. There’s more work to be done. 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.
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 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. Some of these you be be surprised about.
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 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. We can use that to unite us and appreciate each others perspectives.
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 find a way of working better together. Ways that acknowledge and appreciate the differences.
I updated this to version 2.0 after I published. Changed photo and some wording. Sentiment hasn’t changed.