Want to be a better Quality Engineer: Lose the Ego

I had a great chat with Ben Dowen and Simon Tomes today in an MOT online chat where we talked about quality narratives and what it means to influence people. My key point and takeaway was that to be a good Quality Engineer and trusted advisor, we need to put away our egos and be more humble.

Why the ego?

Ego – your sense of personal identity or feelings of self-importance.

– iHasco Blog

Firstly, what do I mean by having an ego when it comes to being the quality expert? It’s the mentality to be right, to win and to prove that we know the most about quality. This can look like many things:

• Finding those really obscure bugs
• Building a test vs. dev culture
• Saying that nobody else can test or doesn’t have a testing mindset
• Being closed off to other ways of working
• Forcing an unrealistic bar of quality onto teams

Its all things that try to elevate ourselves to make our skills look indispensable and special. The way that we make ourselves look important in our craft, or even make our craft and profession important.

Having an ego is a natural reaction to perceptions about QA and testing throughout the industry. We are fed a narrative of “this takes too long”, “we don’t need testers”, “you’re not technical enough” and so build up an ego to prove these narratives wrong. It comes from a place of not wanting to be seen as disposable and wanting to have security in our jobs and our roles.

But it’s this mentality that holds us back from being a good Quality Engineer.

We’re not here to win

A key part of being a Quality Engineer is having the ability to influence others. Our role in creating a culture of quality is to help others see the value in quality and testing activities so that they implement them into building a product. Fundamentally we cannot implement quality processes and thinking into a product alone… we succeed or fail by working with our cross-functional teams to implement holistic Quality Engineering*.

Quality is a team sport, we don’t win or lose as individuals, instead we succeed as a group who’s made a product that’s “good enough” for all of the product users (customers, the business, ourselves, the support team, marketing, etc…). We need to put the part of ourselves that wants to win and be the best aside in order to help the team thrive. Trying to win looks like:

• WHO ARE YOU FINDING THOSE OBSCURE BUGS FOR? Does anyone really care that the app doesn’t work when running on a Gameboy Advance whilst Mercury is in retrograde? If it’s just to prove that you can find them, then maybe it was just to fuel your ego…
• WHO WANTS THOSE THOUSAND OF BUGS? Why do we need a backlog of 10,000 bugs that are all severity 4-5 that never gets fixed? Are they helping quality at all or did we just raise them to show we’re doing something…
• WHO ARE YOU HELPING BY GATEKEEPING? How does it help your team to say that nobody else has a testing mindset and can’t help you to test? That might make you feel special but does create a bottleneck…
• WHO WANTS TEST VS. DEV REALLY? What does it say about testing as a profession or you as a quality specialist when you take glee in showing a developer that they’re wrong? What’s the goal there, other than trying to win…

Winning through our testing and quality activities isn’t helping anyone but ourselves to feel special. We’re not helping our teams and colleagues and we’re certainly not helping drive quality in our products by winning. If anything we’re hurting our ability to build in quality.

Influence & being a trusted advisor

If we’re seen as people who are out to win all the time and doing things for our own ego then people aren’t going to want to work with us or listen to our advice. To be able to influence, coach people, sell testing ideas to people and build a culture of quality in teams we need to have credibility; that means working with people and showing we have the team’s best interests at heart.

Just being smart and right doesn’t mean people want to work with you, or even listen to you. Look at pop culture, it’s littered with examples of smart people who aren’t trusted: The Traitors, Dr. Eggman, The Riddler, Sheldon Cooper… all of them probably should be listened to but aren’t because they try to win rather than working with people.

As Galinda the Good said in the musical Wicked, it’s all about being popular to be a trusted advisor and win people over.

Celebrated heads of state or especially great communicators, did that have brains or knowledge? Don’t make me laugh, they were popular!

– Galinda the Good

You’re more likely to actually make changes to ways of working and implement better quality standards by being listened to. So to be a great Quality Engineer is to be someone that people want to listen to and want to come to for help when it comes to quality matters. Putting the ego aside helps with this.

Putting the ego aside

Here are some of the ways that I’ve worked to put my own ego aside to help make me a better advisor and Quality Engineer.

• BE HUMAN AND TALK LIKE ONE – Ditch the jargon and acronyms and try to speak in a plain and simple way. Don’t name drop models and name and instead communicate the meaning behind what those references are telling us. Oh and you don’t have to use formal language for everything.
• COMPROMISE AND PRAGMATISM – Sometimes it’s better to take a step forwards and make some improvement. Maybe we don’t have to push for gold all the time and instead can talk about how we get to bronze (which is still a win). Work out and help teams to define what good enough looks like for them, rather than imposing your view of perfection.
• DELEGATE AND LET PEOPLE DO THINGS – Other people can have ideas about testing, they might have a better context about a problem which makes their ideas better. Get other people testing and coming up with test tooling and strategies that work for them (maybe you can be a reviewer).
• RAISE THE USEFUL BUGS AND FORGET THE REST – Ask the team if a bug is really needed or if we can ignore it. Nobody needs a bug that’s never going to be fixed, in fact those bugs just make you look like you don’t know what the team wants.
• STOP THE CONFLICT – Show you’re a force for working together and not against people. Stop the Test vs. Dev memes, talk about how you’ve worked with people well, show your pragmatism and maybe stop arguing about semantics or specific use of words.
• GET INVOLVED WITH THINGS PEOPLE CARE ABOUT – Get involved in discussions that things that might be outside of your role and show that you care. Talk about code, architecture and product analysis to show you care about what other people are doing too.

This doesn’t mean being a doormat that people walk all over. Obviously it’s important have opinions but hold them lightly and be willing to let others change your mind on things! The key thing here if not to steamroll and be inflexible on your thinking, instead work with what you’ve got and help other’s to grow their thinking.