Spoiler – project driven quality engineering doesn’t work and you are inflicting damage on QE/QA/testing professionals if you are in charge and think it does.
I was chatting with Simon Tomes on the wonderful MoT Call for Insights (go and do it!) about what kind of conditions you need in place to do ‘good quality engineering.’ Whatever that is, I’ll leave it to you to work out, which is what you should do. No one distant from your context can tell you what that is by the way, maybe a hint or two is the best you can hope for.
Anyway, one of those is whether or not you are within a project context or a product context. I said this:
“A project is an infinitely harder place to do good quality engineering work because the container for it doesn’t lend itself to quality engineering as it’s motivated by different things.
It’s motivated by dates, times, requirements and lists, different things than what you want to achieve with quality engineering, which is sustainability, joy in the work, long term ownership. Whereas if you have a project, it doesn’t want that.”
There are a few reasons for this:
- Projects want testing not quality – a project is interested in moving from one gate to the next with some kind of testing information to oil those wheels. The quality is a distant second, its not all that important to be honest. Tests in a pipeline that have run thousands of times? The project will stare at you implacably and ask for test results in word document.
- Projects don’t care who owns what system, only who owns what process – testers end up owning quality, not everyone with a stake in the product. Its why you end up with whole industries around release testing, because no one owns the relationships with systems that need to work together. Release testing problems are ownership problems, prove me wrong.
- Projects are allergic to cross functional teams, which is what quality engineering needs to thrive – Projects encourage barriers with gates (see above) between people. This is the antithesis of what quality engineering represents, it’s final form is a stable, long running team with ownership beyond building a list of requirements.
But there’s no alternative I hear middle management scream. Of course there is. Take that project money, set up a team(s) with everything that it needs to succeed, support them all the way and watch them fly. It feels so weird to have to say this in 2026.
Failing that, just make sure to ask the product vs project question at your next interview…
Diagram Industries 