The Career Path Through QA Produces Better Medtech Engineering Leaders
By Heena Purkait, Senior Engineering Project Manager
A structural engineer who has spent years studying how bridges fail is not the same as one who has only studied how they're built; both can read a blueprint, but one of them reads it differently. The same gap exists in software engineering, and it runs straight through the QA function. Most engineers who move into project leadership trace a line from design work to technical ownership to program management. My line runs through defect review boards, validation labs, and impact analysis. That path is less common but it’s also better preparation.
V&V Engineers Think In Failure Modes And That Changes Everything
Engineers who have spent time in verification and validation understand a product from the outside in. They have written test cases that exposed requirements nobody questioned. They have sat in defect triage where root cause traced back to an assumption made two years earlier. That exposure changes how you read a system and how you scope a project.
Early in my career, working across QA functions at Philips and Fresenius, I started noticing a consistent pattern: product decisions were being driven almost entirely from the development side, and user needs were regularly getting lost in translation. QA engineers are positioned differently. The job is to stay anchored to what the product actually needs to do for real users, putting you in direct contact with where the gaps are.
Over time, I started bringing that perspective into meetings with product managers and key stakeholders. The feedback started landing. Eventually I was asked to take on a subject matter expert role to provide input on requirements, which is a role that grew directly out of what V&V work had trained me to see.
Engineers with direct exposure to failure outcomes are more likely to build risk mitigation in from the start, not bolt it on later. In regulated industries, where a missed failure mode is a patient safety event, that default matters considerably.
On one project, the team was building a SaMD that performed calculations to generate treatment programs for dialysis machines. Accuracy was critical as the outputs fed directly into the cycler. Using an automated script and a structured database approach, I caught several critical bugs that manual testing had missed. The automated approach provided a level of confidence in the system's accuracy that the team hadn't had before. That kind of catch happens because V&V engineers are trained to ask what happens when the inputs are wrong, when the sequence is unexpected, when the edge case is the actual case.
CAPA Isn't Compliance Overhead; It's Systems Thinking Training
Corrective and preventive action processes look like paperwork from the outside. From inside them, they are one of the most rigorous problem-solving frameworks in regulated industry. Working through CAPA cycles (identifying root cause, scoping the fix, validating effectiveness) trains engineers to think systemically. Impact analysis does the same from the other direction: map every downstream effect of a change across requirements, test cases, and validation documentation.
Project managers who haven't done this work tend to treat scope change as a timeline problem. Those who have worked through 21 CFR Part 820 and IEC 62304 understand it as a systems problem. That framing is the right one.
The Bias That Costs Organizations Technical Leadership
QA functions carry a persistent reputational disadvantage: staffed as support roles, funded as cost centers, bypassed in succession planning. I’ve experienced this first-hand.
As I grew in my QA role, I repeatedly ran into project managers who didn't understand the value QA teams were contributing. I was asked to shorten testing cycles, blamed when bugs surfaced late in development, and, at one point, a project manager told me outright that I couldn't understand PM responsibilities because I was coming from QA.
That comment sent me to the Project Management Professional (PMP) exam; I wanted to understand the PM language well enough to defend the QA timelines with vocabulary that would actually land. After I completed the certification, something shifted. The same people who had questioned my perspective started engaging with it differently, not because my knowledge had changed but the credential made it legible to them.
This is a real cost to organizations. The skills concentrated in experienced V&V engineers (e.g., cross-functional communication) are the same skills that distinguish effective project managers in regulated industries. The pipeline already exists despite not always getting recognized.
Proximity To Quality Gaps Produces Inventors
The patent I hold came directly out of testing work, not design work. The invention (a system for automated simulation and verification of dialysis treatment files) was built to solve two specific problems I kept running into in validation work: the time it took to build reliable test data and the environmental cost of using physical disposables for every test cycle.
Once the tool was built, test data that had previously taken hours to generate could be produced at scale. It also enabled testing across a far wider range of scenarios, which surfaced critical bugs that wouldn't have been caught otherwise. The invention came from being close enough to the problem to see exactly what was inefficient about the existing approach.
FDA's Digital Health Center of Excellence has been making a version of this argument for years: V&V engineers are increasingly positioned to drive the innovation road map, not just verify it. The people building and running validation processes are often the first to see where automation, simulation, or new tooling could close a quality gap, which is a function of proximity.
The engineers who have been doing this work are ready for more. Whether they get tapped for leadership depends on whether the people doing the tapping understand what the work actually is.
About The Author:
Heena Purkait is a senior engineering project manager at a leading global renal care company, where she leads engineering programs for cloud-based dialysis and connected health platforms. She is a named inventor on a published U.S. patent for a dialysis treatment file simulation and verification system that strengthens patient safety and regulatory compliance. Over 15 years in medical device engineering, she has guided multiple product releases through FDA-regulated and EMEA environments, moving from hands-on verification and validation into global program leadership. Purkait holds an M.S. in biomedical engineering from Wayne State University, where her research on blast-induced neural injury resulted in peer-reviewed publications, and is a certified Project Management Professional (PMP) and Lean Six Sigma Green Belt.