You Need a QA Evangelist

The internal IT team at most organizations gets killed by user support.

Okay, those are strong words. Truthfully, it’s not so dramatic. And if you’ve got your eyes open, your user support will help you grow valuable experience far quicker than it drags down your engineers.

But user support is a significant challenge that can stymie project progress. And unfortunately most of the problem is self-inflicted by organizations. We build and deploy buggy systems. And we allow buggy work processes to continue.

Bad QA. Or none at all.

You need someone to take responsibility for that. Product companies have teams of software testers and other folks with a primary job function to ensure quality. But somehow organizations don’t do that for their internal systems development. Quality may be viewed as a shared responsibility, but nobody executes their daily work with commitment to quality as the driving force. And a typical engineer or manager simply isn’t trained to ensure quality or to reliably identify process problems that allow quality to degrade.

Meet the QA Evangelist.

Not every organization is going to be big enough to have one. (Smaller organizations can partly make up for QA problems by being agile enough to quickly fix them, together with a collective willingness to accept unsolved problems.)

For organizations where it makes sense, the QA Evangelist is not a manager, and not an engineer. This role should be able to work across multiple teams, and should do so from the point-of-view of a subject matter expert who excels in promoting a quality mindset. But no good burying this role in the trenches as the only poor soul who has to do QA (engineer), or kicking them upstairs where they’ll be so embroiled in politics they can’t make a difference (manager).

QA should be approached not as a top-down mandate to eliminate all problems, but as a grassroots, consensus-based, pragmatic process whereby quality grows out of the team’s strengths, and in ways that make the team feel positive about the change.

Everyone thinks quality should be better. Everyone thinks it’s everyone’s job. But without someone in tech whose primary motivator is quality, your only chance at quality assurance will be to have an endless supply of nagging users who are very tolerant of unsolved problems.

Get ahead, and evangelize the solution!

Product Development Is Not My Thing

flowchart of agile software product development
It’s been about eight months since I started working for a software product company. Prior to that, I’d spent a lot of time writing software for various audiences – but always for internal use. At my current gig, I’m not working directly in software product development – my role is quality assurance and testing.

I’m not directly influencing the software product output. I am influencing primarily the software development process which causes that output – by finding bugs, finding process problems, and recommending improvements. It’s an internal support service role.

Probably my most natural role in technology is in the areas of support and service. That can mean many things, and in the case of my current job role it means I provide a service to help ensure high quality in the product that the company sells. I’m not sure if I would want to work directly on the product side – even though that’s the revenue generator, it is also the area where the work can get bogged down in a lot of details that don’t necessarily lead to creative solutions to technology problems.

True, in an ideal world product developers would always be primarily focused on innovating and providing the most creative solutions, but in the end the constraints of working within a product framework mean there are a lot of limits on what can be done. Every decision must keep in mind not just the problem at hand, but also the generalized problem that the anticipated product audience has. There is naturally a constant struggle to retain innovation.

When you work directly in service or support, you also have these sorts of constraints but the decisions and actions you take have a little more wiggle room because they aren’t getting baked into the product. There’s a little more chance to be flexible, find new and promising solutions, and move freely.

But of course that only matters if you find ways to take advantage of that flexibility.