CEO's Lessons: How I got fired from my first test manager role

One failed software project. Three lessons. Seventeen years of experience helping organisations build better software.

Getting fired made me a better test leader. 

When people ask me how I became passionate about software testing, quality assurance, and helping organisations build better software, they often expect a story about a successful project. 

Instead, I tell them about the project that got me fired.

Early in my career, I was given what felt like the opportunity of a lifetime. I had just been promoted to my first Test Manager role on a large international software project. Our team stretched across Finland, China, India, France, Italy and the United States. We were building what was, at the time, an incredibly ambitious product: a touchscreen smartphone designed to compete in a rapidly evolving market.

I wanted to prove myself.

So I did what I believed every good Test Manager should do. I studied the books. I earned the certifications. I followed the processes. Every requirement had corresponding test cases. Every feature had measurable KPIs. We tracked our progress obsessively, and by the numbers, everything looked excellent. Some feature areas consistently reported pass rates close to 98%.

If you'd asked me then whether the project was under control, I would have confidently answered yes.

Then our Chief Technology Officer arrived for a product demonstration.

Within minutes, he opened the photo gallery and swiped through a series of images. That simple interaction triggered a catastrophic defect in our haptic feedback implementation. Instead of providing subtle tactile feedback, the device vibrated continuously, making the failure impossible to ignore. The room fell silent. Nobody cared about our impressive pass rates anymore. The only thing that mattered was that the product had failed in front of the person whose opinion mattered most.

A month later, the project was cancelled. On a Friday afternoon, I was told I didn't need to come back on Monday.

At the time, it felt like the biggest failure of my career. Looking back seventeen years later, I see it very differently. Getting fired wasn't the lesson.

It was the beginning of one.

Getting fired made me a better Test Leader 

For a long time, I thought the project had failed because we had missed a bug. The real failure was much deeper. We had become experts at doing things right, but we had forgotten to ask whether we were doing the right things.

We had detailed requirements.

We had mapped test cases.

We had dashboards full of KPIs.

We had pass rates that looked fantastic.

What we didn't have was a genuine understanding of software quality from the user's perspective.

We measured activity instead of confidence.

We measured compliance instead of risk.

We optimised reports instead of outcomes.

That painful experience forced me to rethink everything I thought I knew about software testing. I stopped looking for better templates and bigger test suites. Instead, I started learning from the people who consistently found the problems that others missed. Mentors such as Maaret Pyhäjärvi and Michael Bolton challenged the way I thought about testing. Not as a process to execute, but as a discipline of critical thinking, exploration, communication, and continuous learning. Those lessons have shaped every client engagement, every training session, and every testing strategy I've developed since.

Today, those same principles are at the heart of Prove Expertise. We don't measure success by the number of test cases executed or the percentage of tests that pass. We measure success by helping organisations make better decisions, reduce business risk, improve software quality, and build resilient, secure systems that perform when they matter most.

Lesson 1: Stop doing things right. Start doing the right things. 

If I could go back and give one piece of advice to my younger self, it wouldn't be "write better test cases" or "improve your reporting."

It would be this:

Don't become so focused on doing things right that you forget to ask whether you're doing the right things.

That's exactly what happened on my first Test Manager assignment. Our team followed the process meticulously. Every requirement had corresponding test cases. We measured our progress through pass rates, coverage metrics and carefully planned execution. From a project management perspective, everything looked healthy.

But software quality isn't determined by spreadsheets.

It's determined by what happens when a real user interacts with your product.

When our CTO picked up the device and performed one of the most natural actions imaginable (swiping through photos) our carefully managed testing process failed to identify a defect that instantly undermined confidence in the product. In that moment, months of planning and thousands of executed test cases became irrelevant.

That experience fundamentally changed how I think about software testing.

Quality isn't measured by activity

One of the biggest misconceptions in software testing is that more activity automatically leads to better quality.

More test cases.

More automation.

More documentation.

More reports.

These all have value. But only if they're helping you answer the question that actually matters:

How confident are we that this software will succeed when real people use it?

I've seen teams proudly report thousands of successful automated tests while critical customer journeys remain largely unexplored.

I've also seen small, highly skilled teams uncover business-critical defects in a single afternoon because they focused on understanding risk instead of simply executing predefined scripts.

Testing isn't about proving that software works. It's about discovering where it might fail.

Modern QA starts with risk, not requirements

Requirements are important. They tell us what a product is supposed to do.

They rarely tell us where the greatest risks are.

Every software project operates under constraints. Time is limited. Budgets are limited. Releases have deadlines. No team can test every possible scenario, user behaviour or system interaction.

That's why effective testing should focus on making informed decisions.

Where would a failure have the greatest business impact?

Which customer journeys matter most?

What assumptions haven't we challenged yet?

Where are users most likely to behave differently than we expect?

These are the questions that guide modern quality assurance.

What we've learned at Prove Expertise

One pattern has remained remarkably consistent across the organisations we've worked with. The teams that deliver the highest quality software aren't necessarily the ones with the biggest QA departments or the largest automation suites.

They're the teams that continually ask better questions.

They challenge assumptions.

They prioritise business risk over vanity metrics.

They adapt their testing strategy as new information emerges.

That's the mindset we bring to every client engagement at Prove Expertise. Whether we're improving software quality, strengthening cybersecurity, or helping organisations modernise their testing practices, our goal isn't simply to help teams test more.

It's to help them test smarter.

Lesson 2: Your testing time is your most valuable resource 

One of the hardest lessons I learned after that project had nothing to do with testing techniques.

It was about time.

Back then, our calendars were full. We designed acceptance tests, documented results, updated reports, attended status meetings and monitored KPIs. Every day felt productive because every hour was accounted for. Looking back, I realise we confused being busy with making progress.

Experience has taught me that every hour invested in one activity is an hour unavailable for another. That's an obvious statement, but it's surprisingly easy to forget in software projects.

Every decision has an opportunity cost. An hour spent maintaining low-value regression tests is an hour not spent exploring a new feature. An afternoon spent preparing presentation slides is an afternoon not spent investigating a customer-reported issue. A week spent chasing marginal coverage improvements could have been used to validate the workflows that generate the majority of your business revenue.

Great testing is built on thousands of these decisions.

Prioritisation is a professional skill

One question has stayed with me throughout my career:

If I only had two days to test this release, where would I start?

Every tester should have an answer.

The answer shouldn't come from a template or a checklist. It comes from understanding the product, the users and the business.

Which functionality creates the greatest value?

Which failure would have the biggest impact?

What has changed since the last release?

Where are we making assumptions instead of validating behaviour?

Those questions help establish priorities long before the first test case is executed.

High-performing teams make different decisions

One characteristic stands out when I look at the strongest QA teams I've worked alongside over the past seventeen years. They rarely try to do everything. Instead, they make conscious trade-offs.

They know that software can never be tested exhaustively. Rather than chasing completeness, they concentrate their effort where uncertainty is highest and where failures would matter most. That approach requires judgement, experience and close collaboration with developers, product owners and stakeholders.

There is no universal priority list. Every release, every product and every organisation has different risks.

The ability to recognise those differences is one of the qualities that separates experienced testers from those who simply follow a process.

How we apply this at Prove Expertise

When organisations ask us to improve their quality assurance, they often expect recommendations about tools or automation.

Those are important conversations, but they usually come later.

Our first questions are different.

• What are you trying to protect?
• Which customer journeys matter most?
• Where would failure have the greatest business impact?
• How do you currently decide what deserves testing attention?

The answers shape everything that follows.

Those conversations have become a cornerstone of how we help organisations strengthen software quality and cybersecurity. The same discipline of prioritisation applies when evaluating security risks, deciding where to invest testing effort and identifying weaknesses before they become incidents.

Lesson 3: The best testers influence more than they control 

One question completely changed the way I think about software quality.

Who actually controls quality?

When I first got into testing I believed it was the testing team. Then I started looking at software projects more honestly.

As testers, we don't decide what gets built.

We don't write most of the production code.

We don't control release schedules.

We don't approve budgets.

We don't decide how many developers join the project or how much time is available before launch.

Yet we're expected to help deliver quality. They call us "QA."

That contradiction frustrated me. Eventually, I realised I was asking the wrong question. Quality has never been the responsibility of one role or one department. It's the result of hundreds of decisions made across an organisation every single day.

Influence creates better software

Once I accepted that reality, my role as a tester changed. Finding defects was still important, but discovering a bug wasn't the finish line. The real work began when I needed to explain why it mattered, who should care and what action should follow.

That requires much more than technical knowledge. It requires communication, trust, and the ability to present evidence without creating conflict.

The most effective testers I've worked with aren't remembered because they found the highest number of defects. They're remembered because developers wanted to hear their feedback, product owners trusted their judgement and leadership valued their perspective when difficult decisions had to be made.

Those relationships are built over time, and they have a direct impact on software quality.

The same principle applies to cybersecurity

The longer I've worked with organisations, the more similarities I've seen between software testing and cybersecurity.

Neither discipline succeeds through checklists alone.

A penetration test doesn't improve security unless its findings lead to meaningful action.

A vulnerability assessment has little value if the organisation lacks the processes or commitment to address what it uncovers.

A defect report that nobody understands or prioritises doesn't improve the product. A carefully written test report doesn't reduce business risk unless it changes a decision somewhere in the development process.

Whether you're discussing a usability issue, a reliability problem or a security vulnerability, success depends on your ability to influence the people who can act on that information.

What we've learned at Prove Expertise

One characteristic stands out in organisations that consistently deliver reliable and secure software. Quality is treated as a shared responsibility.

Developers, testers, security specialists, product owners and business stakeholders all contribute different perspectives, but they work towards the same outcome. Conversations about quality happen early, risks are discussed openly and testing is integrated into decision-making rather than treated as a final approval gate.

This collaborative approach also produces stronger security outcomes. Many of the most serious vulnerabilities emerge because assumptions go unchallenged, communication breaks down or risks aren't recognised until late in the development lifecycle.

What this means for today's software teams 

Roughly two decades have passed since that Friday afternoon when I packed my things and walked out of my first Test Manager role.

Software development has changed dramatically during that time.

Teams release software continuously instead of a few times a year. Cloud platforms have replaced dedicated servers. AI is becoming part of everyday development. Cybersecurity has become a board-level concern.

One thing, however, has remained remarkably consistent.

The teams that consistently deliver reliable software share a common mindset. They stay curious, question assumptions, and treat quality as an ongoing conversation instead of a milestone on a project plan. They understand that every release introduces uncertainty, and they actively work to reduce it.

I've had the privilege of working with organisations of different sizes, industries and levels of maturity. Every project has its own challenges, yet similar patterns emerge time and again. Teams that invest time in understanding business risk make better technical decisions. Teams that communicate openly identify issues earlier. Teams that encourage testers, developers and security specialists to collaborate create software that performs more reliably in production.

None of these habits require revolutionary tools. Just experienced people who know which questions to ask.