Beyond billable hours - QA Innovation
What do you do with a QA organization that has more capacity than customer work? This is the story of how we turned idle bench time into a training ground, an internal product called Sedstart, and eventually a different kind of services conversation.
Beyond Billable Hours: Turning QA Capacity into a Business Innovation Engine
There's a moment every services organization eventually hits: skilled people sitting on the bench, waiting for the next project to start.
We hit that moment in our QA organization.
We had capable people. We had experience. We had a strong delivery organization.
But the market was changing, and the bench kept growing faster than the pipeline of customer work.
The obvious response was to tighten utilization and wait for the market to turn.
We asked a different question instead:
What can a services organization build when it has capacity but not enough customer work?
That question changed how I thought about QA leadership.
Instead of treating available capacity only as something to be optimized, we started treating it as an opportunity to build capabilities, experiment with new ideas, create products, and eventually generate new business.
This is the story of that journey.
The Problem Was Bigger Than Utilization
In a traditional services organization, utilization is an important metric.
People need projects. Projects generate revenue. Revenue sustains the organization.
But looking only at utilization can create a narrow definition of productivity:
If someone isn't working on a customer project, they aren't productive.
I started questioning that assumption.
If we had people who were temporarily available, we still had something valuable: skills, experience, context, and time.
The question became how to convert that combination into something useful.
At the same time, the market was changing.
The skills customers were asking for were evolving. Automation was changing rapidly. New tools and technologies were appearing. Customers expected more than traditional testing services.
This created two related problems:
- How do we make our people more relevant to the market?
- How do we create something that differentiates our services?
We decided to address both through experimentation.
Start With the Capability Gap
The first step was not to launch a product.
It was to understand where we were.
We assessed the QA organization against the skills and capabilities that were increasingly relevant in the market.
The assessment looked at four areas:
- What were we already good at?
- Where were the skill gaps?
- How were we contributing to the business?
- Where were the opportunities to create more value?
This sounds straightforward, but it changed the conversation.
Instead of asking:
"What training should we provide?"
we started asking:
"What capabilities does the market need, what do we have today, and how can we close the gap?"
That distinction matters.
Training became an instrument for building business capability rather than an activity performed because people had free time.
We Stopped Treating Training as a Course
One of the first experiments was to rethink how people learned new technologies.
Traditional training often follows a familiar pattern:
- Attend training.
- Watch demonstrations.
- Complete a few exercises.
- Move on.
That wasn't enough for the kind of skills we wanted to build.
We wanted people to experience the problems they would encounter on real projects.
So we created custom applications and APIs with deliberately complex scenarios around the technologies and skills we wanted people to learn.
The goal was simple:
Don't just teach the tool. Create an environment where people have to solve realistic problems using the tool.
This led to hands-on bootcamps, live coding sessions, reusable training resources, and project-oriented learning.
The training environment itself became a small product.
It had applications, APIs, scenarios, exercises, documentation, and problems that people could repeatedly use.
That approach also exposed something important.
People learn very differently when the problem feels real.
From Training to Real Projects
The next step was to reduce the distance between learning and delivery.
Where possible, we explored opportunities to let people learn through actual project work.
One approach was to consider projects that might not have been attractive from a purely commercial perspective, but could provide meaningful learning opportunities.
The thinking was not:
"Let's take bad projects."
It was:
"Can we deliberately use selected projects to accelerate capability development while still delivering value to customers?"
That changed how we thought about the relationship between business development, learning, and delivery.
A project could generate revenue.
It could also generate experience.
And that experience could increase the organization's ability to win the next project.
The boundary between "training" and "delivery" became less rigid.
Then We Asked a Bigger Question
Once we had people developing new skills, another question emerged.
What if we used the same available capacity to build something that could become a product?
This was the point where the idea behind Sedstart started becoming important.
Instead of asking people to wait for the next customer project, we used available capacity to experiment with a product idea around test automation.
The initial objective wasn't to build a massive product company.
It was much simpler:
Can we solve a real problem well enough to create something that customers would actually use?
That distinction was important.
We weren't trying to predict the perfect product upfront.
We were experimenting.
Building a Product Inside a Services Organization
Building a product is very different from delivering a customer project.
A customer project starts with a known customer and a known problem.
A product starts with a hypothesis.
You have to answer questions such as:
- Is this problem important enough?
- Who actually has the problem?
- What would they pay for?
- Can we build something meaningfully better?
- Can the services organization benefit from the product?
- Can the product itself create opportunities for services?
That meant the team had to think beyond implementation.
We had to think about users, positioning, usability, adoption, differentiation, and commercial value.
The product became a practical way of developing capabilities that traditional project work didn't necessarily expose people to.
And something else happened.
The product itself started becoming useful in conversations with potential customers.
Products Can Change the Services Conversation
A services organization can easily become trapped in a commodity conversation.
The conversation becomes:
How many people do you have?
How much does each person cost?
What is the hourly rate?
How quickly can you provide resources?
That is difficult to differentiate.
A product or technology capability can change the conversation.
Instead of starting with people and hours, you can start with a problem and a solution.
In our case, Sedstart could support the services proposition while also existing as a product in its own right.
That created a different kind of sales conversation.
The product demonstrated capability.
It provided something tangible to discuss.
And it gave the organization another way to differentiate its services.
This led to a broader realization:
A product doesn't have to replace services. It can make services more valuable.
The Pattern Spread Beyond QA
The most interesting outcome wasn't that one product was built.
It was that the approach started appearing elsewhere in the organization.
Other divisions experimented with their own ideas, including products such as CV Square and a RoR Migration Calculator.
The specific products are less important than the underlying pattern.
The organization was beginning to see available capacity differently.
Instead of asking only:
"How do we keep everyone busy?"
the question became:
"What can this team create that could make the organization better?"
That shift is subtle, but significant.
Innovation stopped being something that happened only when someone had a brilliant idea.
It started becoming an activity that could be deliberately enabled.
Innovation Needs More Than Ideas
This experience also taught me that having ideas is the easy part.
The difficult part is creating the conditions in which people can actually test those ideas.
I found four things particularly important.
1. The organization has to accept experimentation
Not every experiment will work.
Some will fail.
Some will produce something useful but not commercially viable.
Some will reveal that the original assumption was wrong.
If every experiment is judged as if it were a normal customer project, people will naturally avoid experimentation.
You need room to test ideas without expecting certainty from day one.
2. People need permission, not just motivation
It is easy to tell people to "be innovative."
It is much harder to give them the time and freedom to do it.
If innovation is always something people are expected to do after their normal work, it will rarely survive for long.
People need a reasonable amount of ownership and space to experiment.
3. Leadership needs to tolerate ambiguity
Leadership support isn't simply approving a budget.
It means accepting that the outcome may not be known upfront.
A product may change direction.
A training initiative may expose a completely different capability gap.
An experiment may fail.
The organization has to be comfortable learning before it starts scaling.
4. Passion matters
Not every initiative can be driven through process.
At some point, someone has to care enough about the problem to keep pushing it forward.
The role of leadership is not to manufacture that passion.
It is to recognize it and avoid creating unnecessary barriers around it.
What We Learned About QA
The biggest lesson for me was that QA can contribute to the business in more ways than delivery.
A mature QA organization can become a source of:
- Market-relevant skills
- Internal tools
- Training assets
- Automation capabilities
- Products
- Sales enablement
- New service offerings
- Business experiments
That doesn't mean every QA organization should become a product company.
It means we should stop thinking about QA only in terms of test execution and resource utilization.
A QA organization has accumulated domain knowledge, technical skills, customer experience, and problem-solving capability.
Those are assets.
The interesting question is how deliberately we use them.
The Results Were More Than a Product
The outcome of this journey wasn't simply the creation of a product.
We saw benefits across multiple dimensions.
Capability
People developed skills that were more aligned with emerging market requirements.
Learning
Training became more practical and closer to real project conditions.
Innovation
Teams had a mechanism to experiment with ideas rather than keeping them as suggestions.
Sales
Products and technology capabilities created new ways to demonstrate value to customers.
Business
Some experiments moved beyond internal initiatives and created commercial opportunities.
Organizational behavior
Perhaps most importantly, other teams began considering similar approaches.
That last part is what made the experience particularly interesting to me.
An experiment had become a pattern.
What I Would Do Differently
Looking back, I would change a few things.
First, I would define measurable success criteria earlier.
When you are building something experimentally, it is easy to keep going because the team is learning and the product is improving.
But learning and commercial success are different outcomes.
They should be measured separately.
Second, I would validate the customer problem earlier.
Building something technically interesting is relatively easy.
Building something customers genuinely need is much harder.
Third, I would make the portfolio of experiments more explicit.
Not every idea deserves the same investment.
A simple framework can help classify initiatives into:
- Capability-building experiments
- Internal productivity tools
- Sales enablement products
- Potential commercial products
That makes it easier to decide where to invest and when to stop.
The Bigger Lesson: Don't Waste Capacity
The most important lesson I took from this experience is not that every organization should build products when utilization falls.
It is this:
Unused capacity is not necessarily wasted capacity.
In a services organization, available capacity can be used to create capabilities that the organization will need tomorrow.
It can be used to experiment with products.
It can be used to create internal tools.
It can be used to train people on realistic problems.
It can be used to discover new business opportunities.
The key is to connect those activities to real business problems rather than treating innovation as an isolated side project.
That changes the role of a QA organization.
Instead of being measured only by how efficiently it delivers today's work, it can also contribute to building the capabilities and offerings that create tomorrow's work.
And perhaps that is the more interesting way to think about innovation in a services business.
Don't just optimize the capacity you have today. Ask what that capacity can create for tomorrow.