This is part of a series on building QA & quality engineering functions that work:
→ The QA Team I Wish Every Company Had
→ How to Build the Right QA Team for Your Company (you are here)
→ How to Translate QA Gaps into Hiring and Process Decisions
So, you've moved past the question "should we hire a QA?" and on to "what kind of QA do we actually need?"*
In my last post, I talked about the QA roles that I think should exist and how I wish companies would evolve their teams to better support product quality. But not every company needs the same QA team setup (some might not even need a QA team at all! 😮). What works for one team might be overkill or completely inadequate for another.
So many companies get this wrong. Many assume all they really need is really high automated test coverage and only hire SDETs. Or worse, they'll have developers write and maintain *all* automation. All in the hope that automated tests alone will solve all their quality problems (spoiler: they won't).
Finding Your Ideal QA Team Make Up
So, what kind of QA team does your company actually need? Well… it depends. What's at stake when things go wrong? An early-stage startup with a few hundred users isn't in the same position as a mature product where a bad release reaches thousands. How baked-in is quality already? A team that treats quality as a shared responsibility needs a very different QA function than one that only thinks about testing as a last-minute gate before shipping. And where is your product actually breaking right now? Those answers narrow the field faster than any list of QA roles and responsibilities.
The Right QA Role Depends on Your Team's Quality Gaps
Once companies realize they need QA the next mistake they often make is hiring for a solution that fixes the wrong problem. Imagine a team keeps getting blindsided by production issues so they rush to hire an SDET to build and scale test automation.
Now, it's totally possible that a lack of automation was really the problem! But it's also possible that the real issue was a lack of exploratory testing. Or unclear requirements. Or missing risk analysis. Or all of the above.
The right QA team isnt about choosing between automation and manual testing or hiring for a target mix of titles. It's about solving the specific quality challenges that exist in your product (and on your team!) today.
Start there and you'll hire for what's actually broken.