The SQA2 Blog: Advice Center, General
When someone new joins your account from a QA vendor, they often arrive with no context on the project. They get credentials, whatever documentation exists, and a calendar full of knowledge transfer meetings. Senior engineers spend the next month explaining the system. Tickets bounce because the new person doesn’t know what normal looks like yet.
Nobody invoices you for any of that. You pay for it anyway, in your engineers’ hours and in the defects that slip through while the new person is learning. I think of it as the onboarding tax. Most companies pay it over and over and never put a number on it.
Why it keeps happening
People change on every QA team. They get promoted, move to other projects, and leave for new jobs. No vendor can promise you the same faces forever, and any vendor who does is promising something they don’t control.
The tax doesn’t come from people changing. It comes from what happens when they do. In most models, everything a Quality Engineer learns about your system lives in that person. When they go, it goes, and the replacement starts from zero while your team pays the tax again. Staffing layers make it worse. When there’s a subcontractor behind your vendor, you may not even know who employs the person testing your software, let alone whether anything they learned will be there next quarter.
For regulated companies there’s a second cost. Quality Engineers work inside sensitive environments, including test data that mirrors production, staging credentials, and sometimes real customer records. A high-churn bench means a steady rotation of newly credentialed people through exactly the systems your auditors ask about.
Vendor scorecards don’t capture any of this. They weigh rate, skills, and ramp time. What happens to the knowledge when a person changes never makes the list.
Continuity is not the same faces
Here’s the definition I’d offer instead: continuity means the client never starts over. The team can change, as long as a change on the team costs the client nothing they’ve already paid for.
The knowledge a QA team builds up about a system is real and it’s valuable. They learn which module gets touchy when upstream rules change, why a certain defect pattern keeps coming back, and which failures actually matter to the business. If that knowledge only lives in individual heads, it’s fragile no matter how good the individuals are. The question to ask about any QA setup is whether that knowledge survives the people who built it.
How we built for that
At SQA², we designed the model around that question.
Our embedded Quality Engineers work inside client teams day to day. Behind them sits our Software Quality as a Service (SQaaS) organization, where team members work on client projects continuously. When a client needs more capacity, we usually already have people in our ecosystem with experience on that client’s platform. We’re not hiring for the need or pulling a stranger off a bench. We move a SQaaS team member into the embedded role, and the ramp-up is close to zero.
Underneath both sits a knowledge repository. Everything the team learns about a client’s systems gets documented and owned by the engagement, not by any one person. It holds the coverage decisions, the defect history, and the reasoning behind them. Each client’s repository is their own, maintained within the confidentiality terms of that engagement. Whoever joins the account inherits all of it, and whoever leaves takes nothing away that the client depends on.
The repository is the part I’d point at if you asked what makes this durable. It’s an asset, and it compounds. Every release tested and every quirk learned makes it worth more than it was the year before. A bench of individuals is worth the same on day one of year ten as it was on day one of year one. A repository is not. The longer we work with a client, the more valuable it gets, and the wider the gap grows between a team backed by one and a team without one.
This is what lets us say something most vendors can’t: our continuity doesn’t depend on who we put on the project. People on our teams change too. The knowledge doesn’t.
What it looks like in practice
We’ve worked with one client for over ten years. Their needs changed constantly in that time. We scaled the team up for their big pushes and scaled it back down after. When they recently needed added capacity, we had two team members on the account in under a week, because those people were already in our SQaaS organization and already had experience on the client’s platform.
Through every change in team size and every change in personnel, the client never started over. Several of our other client relationships have passed the five-year mark. In an industry where vendor relationships often don’t outlive the contract cycle, we think that tenure says more than any capability deck.
Before your next renewal
If part of your QA arrives through a vendor, it’s worth understanding a few things about how they operate. You should know whether the people on your account are their employees or come through a subcontractor, and whether QA is their core business or one service line among many. Most of all, you should know what happens to the knowledge of your system when someone on the team changes, because someone always will.
Continuity is easy to overlook in QA. Most of the focus goes to bugs, test cases, automation, and technical ability. All of that matters. None of it holds up over a long engagement without continuity underneath it.
