tl;dr: The key principle to understand with the Return on Quality Investment (ROQI) is that wealth preservation (saving) is not the same as wealth creation (return). QA leaders should be unafraid to avoid using the term ROI and instead lead with loss avoidance, e.g., "our QA efforts cost X, but they are saving money / helping with wealth preservation / loss avoidance for 10*X.”
For Quality Assurance to be a power center, we need to be able to articulate precisely the value contributed by the team to the organization. Executives will challenge every dollar allocated to what they see as context efforts, and try to divert them to the core; i.e., adding new products, expanding to new geos, etc. That is their job, after all, and they will struggle to understand why your context team needs such heavy investment. [1]
I propose we look into three areas to answer the dreaded question, “Is it worth it?” when defining your budget for your QA team for 2026. Each of these should be seen only through the lens of QA:
Feature Delays due to Quality Control bottlenecks.
Churn due to low Product Quality.
Reputation damage due to Incidents.
The mindset when answering these questions should be always the same: we are optimizing for future revenue, above all. That means, we know our team needs to be lean, and we commit to constantly optimizing costs.
At the end, a short story on how this looked for me in the past, and how a high-level company mindset would help you define a successful team.
First: Gather the data
In preparation for the conversation, you should make sure to gather all available data on the points for your discussion. This needs to be comprehensive and unbiased; you must do your best so this data represents the business reality.
Each area has a slightly different group of stakeholders you need to talk with, which is where your SETIs and QA Analysts can help.
Feature Delays due to Quality Control Bottlenecks
Meet with your SRE or DevOps team and ask them to help you collect metrics that explain to your organization the challenges of not having QA, e.g., building the wrong solution, or involving QA late in the process, i.e. why shifting left is important. A few metrics I’ve used in the past:
Time from pull request/code merged until deployment
This is very tactical, but it's easy to translate into how effective we are as a team. You could run your CI pipelines in 5 minutes, and all automated tests could be flawless, but if deployments are only twice a month, then there’s something in the QA process that needs to change.% feature rollbacks
If you are rolling back features often, it means that your practices are not mature enough when either defining or validating those features internally; both require QA involvement early on.Avg. time from project conception to full launch
Related to the above, even if you’ve caught issues before a user ever sees them, the problem may be that your involvement is so late in the process that features take months to be delivered. Again, add a point for shift-left.
Churn due to Low Product Quality
If you read my last article, this is why Customer Support should be one of your best friends. They have the knowledge and expertise to help you communicate the challenge properly. They can provide you with:
NPS overall for users.
Expenditure on discounts, rewards, or other financial compensation given to customers due to issues with the service.
Actual churn due to the quality of our product. For this, make sure they include the category in the forms they give to leaving customers.
Reputation Damage due to Incidents in Production
This is when you talk with marketing and sales reps, and you get a sense of the following things:
General communications sent to the customer base on topics regarding quality.
How important is quality for your ICP? A good product marketing team should have these quantified based on interviews.
Marketing investments done with a messaging around quality.
Armed with all this information, you should now have an understanding of what’s at stake if your product lacks quality in certain areas. For example, you can now argue why the onboarding flows should be flawless, because your users might not use the product if something fails there, or justify why payments could be handled manually, and the QA investment there should be nil.
Second: A fireside chat with Finance
Your finance leader may not care about delivery velocity, or they may equate churn attributed to low product quality with bad customer support; or they may argue the value given by the product is so overwhelming that product failures will be dismissed even if your quality drops. In many respects, it’s a controversial topic.
The difficulty, from a data-minded leader's perspective, is simply that we wouldn’t know if we could have gotten away with similar results with less investment. That’s what a CFO would articulate, and I would say most of us would agree. If you are faced with this conversation, then now is when you flip the script: we agree, let’s experiment!
Option 1: Lookback Analysis
My preferred option, and the good news is that you probably have this information already: Examine those rushed new product launches.
During those crazy launches, you purposely skipped QA practices simply because you were willing to afford it, and the results were self-explanatory. I’m sure your issues spiked immediately, and after 6 months, some of the largest projects were consuming 4x costs in infrastructure, and deliveries were equally delayed. Those 'successful' product launches give you a blueprint of the cost of skipping QA. They are a playground where expectations from your customers are also low.
Option 2: Show Me the Money!
If the objective is to experiment with new tools and processes to reduce costs while sustaining productivity, what you need is a budget to make that happen. You’ll likely need someone working on this full-time, and you’ll also need to try new tools and frameworks.
This is where you commit to a plan and align on how much you are willing to invest and for how long to achieve a clear goal on cost reduction or increased effectiveness.
This is your opportunity to get promoted. If you show you can build a better organization that’s more cost-effective, then you are on the path to being a key asset in your company.
Third: An innovative QA tactic, revenue generating
Let’s imagine you get a chance to present the budget plan and 2026 roadmap to your executive team. They are going to be interested in cost-effectiveness and how to reduce churn; that will make them feel satisfied with the department… and you can do them one better!
You can build an extra case around delivery velocity, and how that could open the door for your team to deliver multiple projects with high quality and customized features to unblock deals without dreading a release will hamper the rest of your system. This could have such a positive impact, i.e., imagine telling a customer that their special fix will take 2 days instead of a month. That even though you would agree it requires consistent investment from the engineering on writing and maintaining tests and infrastructure, you’ll want to do so for the upside alone.
Again, to prove the above you should set an experiment, define how you are going to measure success across the organization, and track those metrics to show this has paid off. For us, it was winning deals because we would implement features in hours, instead of months, and customize flows in minutes, without endangering all our users. Having tech not to be a bottleneck for sales was seen as such a competitive advantage that the investment in the area kept steady for years.
This takes me to my real life example.
A team without QA
In my whole career, I only hired 1 QA leader, and when I hired that person, whom I already knew, I hired them to run the SRE, IT, Sec&Compliance, and QA teams. Why?
Because my objective was to have them so busy with other things that automating Quality Control and teaching the art of Quality Analysts to Tech, UX, and Product, would be their only reasonable path forward. He was in the job for 3 years, we had a team of ~60 engineers at peak, and he never hired a single other person with a QA background. We did hire SDETs, SREs, and trained many others to cover aspects of the QA function to create a QA culture.
You can think this is a fairy tale, but let me show you our metrics and how we defined success:
Northstar: 0 business-critical incidents per Q.
With an incredible idealistic Northstar we defined those KPIs that would get us closer to the goal.
1 user reported an incident per quarter max.
This is key. We didn’t care as much about having issues in our app unless a user reported them. There are two things you should keep in mind though:Given how we implemented CI/CD in an extremely strict manner, CFR and other standard metrics weren’t as meaningful for us.
I’m not including anything related to monitoring and alerting in this essay, but there were matching metrics to ensure we were tracking everything meaningful happening in our app in real-time.
Also extremely important, we tracked how many issues we fixed proactively, ie. we would actively fix issues that were blocking users before they reached out to us, and we would notify them once everything was taken care of. That would be tracked as a great achievement in a separate board. There’s nothing better than to reach out to a customer and say: “we’ve seen you experienced a challenge, it’s fixed,” or even better if they never even realized the issue.5-minute CI duration
This meant running 1500 end-to-end (E2E) tests in under 5 minutes, you can imagine the efforts on parallelization, ephemeral environments, and infrastructure to run these tests in a team of at most 60 individuals.
All worth it, because as you know, while engineers tend to trust passing test results, they often retry failing tests a number of times and consider failures followed by passing results as flaky. By reducing the length of the CI pipeline, we save hundreds of hours a year, as each minute saved has a multiplying effect. For example, 1 minute saved here for a team of 60 potentially represents 10+ hours saved per week; thus going from 30 minutes, to 5 was an incredible achievement.1-minute rollbacks
Whenever an issue was detected we would rollback. As fast as possible, as automated as possible. That meant all changes—configuration, flags, db migrations, etc.—needed to be tightly coupled in a single release, and all services needed to be backward compatible. This gave us the confidence of knowing that if we released frequently enough, we would be able to revert mistakes in seconds.95% E2E coverage
Test coverage is a vanity metric, but the main concern here was: “have we automated 95% of the tests defined for this product?” For different products in different maturity stages, we oscillated between 80-99% coverage.
It would hold us accountable, and by defining these e2e mandatory tests sets in our design and launch documents, we were able to hold ourselves accountable to the quality we needed in each area.
This was the enforcement tool for our QA leader to make sure the organization was learning.
The byproduct of these ambitious targets was that two years later we had 2.5 million fully automated E2E test runs per month, from a base of 1500 automated E2E tests. On top of that, we had unit tests, integration tests, and image diff tests to provide more comprehensive coverage. All that was supported by a community of dedicated Software Engineers, and one individual who had this as their main core responsibility. We’ve done deployments at crazy hours with extreme confidence.
The-one-thing: Cost - Quality - Speed.
Counterintuitively, when discussing budget allocation for QA, you need to fix Quality by means of feedback from Marketing, Customer Support, and Sales, and you should center your plan around Speed & Cost. Don’t discuss ideal Quality standards; leverage the voice of your customers. They define what Quality is acceptable. Shift the conversation to what you can do to increase the effectiveness of the team, and talk about velocity and costs for the whole organization.
Be radically clear: optimizing revenue is QA's top priority.
References
How do you test your tests? (Probabilistic flakiness) - Meta DevInfra
Is Software Security a waste of money? - Schneier on Security
Push for QA as your devex powerhouse - E.-
No ROI? No Problem - Richard Bejtlich
Capchase Communities Blue-print - E.-
Security ROI - Schneier on Security
Core vs Context - Geoffrey Moore
ROQI Calculator - desplega.ai