Skip to content

Save QA for when the fall is deadly

I’ve worked with a slew of really great Quality Assurance practitioners in my time. Their work is important in the right contexts. The work is hard and appreciated when that context is right.

But, they’re not a great fit in all contexts and can, in some cases, create more downsides than positives.

QA as a speciality and separate job function makes sense when the downside risk of bugs is so great that the company can afford to invest in doing everything possible to prevent errors or to give customers and other stakeholders the impression that they’re doing everything in their power to prevent errors.

If your company has grown huge, or your customers work in regulated industries, or your company is building things where the risk of errors affects life and limb, QA can be a fantastic safeguard for the very real downside risks involved.

But, if you’re a MarTech startup, or an Uber for dog walking, or laundry as a service or some other VC-funded race to product market fit, QA can be detrimental to the way your engineering team works and can impede the progress you’re trying to make.

Often, QA and engineering can develop an adversarial relationship – much like writers and editors back in my journalism days.

Editors think of writers as hacks who need babysitting and don’t follow instructors. Writers think of editors as hacks who don’t understand what they’re trying to say and destroy their artistic vision.

In some product organizations, a similar dynamic emerges where engineers view QA as an impediment to progress, as stuffed shirts that test edge cases that will never happen and make them revisit work they felt was already finished. Meanwhile QA can view engineers as hacks who don’t care about the quality of their work and can’t be trusted to do anything right.

Of note: the best QA folks I’ve worked with actually do kind of believe that last part – it’s part of what makes them great.

Sometimes, you can have a culture where the two functions become actively hostile to one another – with engineering trying to slip things by and QA dipping into especially pedantic and petty obstacles in an escalating arms race of spite and passive aggressive posturing.

The above are generalizations or even slight exaggerations of my past work experiences, but that relationship between the two isn’t always sour. I’ve worked at places where QA is instead viewed as a key partner – a safety net that makes sure none of us look bad.

But, as an engineering leader, part of your goal should be to delay hiring QA resources – internal or external – for as long as you can.

Not necessarily for these inter-function dysfunctions – like I mentioned, there are ways to iron those out and have a great culture with QA – but for how it changes the mindset of your engineers.

A lot of the work of managing software engineers is granting them authority and ownership over the work the business needs them to do – to build a sense of care.

The most straightforward way to do this is to ensure that they are fully responsible for how their work functions and performs – to put them in charge of the quality of their work rather than offloading that to another team.

Bugs and errors happen. All the time. It’s one reason QA teams exist.

I posit that engineers make fewer bugs and errors when QA isn’t there. They are more careful and more likely to implement best practices around testing when the safety net of QA is taken away.

Think of your engineers as trapeze artists. A high wire performer without a safety net will be more careful, more precise than one with a net beneath them.

Unlike trapeze artists, nobody is going to die when a foot slips or a bug goes live in most software startups – because, to stretch the metaphor, the wire is inches above the ground. You slip off the wire, jump right back on and continue on your path – possibly with no one noticing.

When your business reaches heights where that wire feels at a deadly height, or what’s beneath you isn’t solid floor but shark-infested waters (regulated industries), then add the net – add QA.

Until then, give your engineers direct ownership over the quality of their work.

The longer a business can maintain a culture of that care the faster progress will be made and more cohesive the entire product organization will be.

Leave a Reply

Your email address will not be published. Required fields are marked *