The Systems Engineering Talent Gap in Medical Device Development
FDA and MDR expectations are rising while the pipeline of qualified engineers shrinks — here’s what device makers are doing about it
The medical device industry is facing a structural problem that no hiring sprint will solve quickly. On one side: regulatory bodies in both the US and EU are raising the bar for systems engineering rigor in submissions. On the other: the pool of engineers who can actually deliver that rigor — with the right domain knowledge, the right process discipline, and fluency in the tools that modern submissions require — is not growing fast enough to meet demand.
The result is a gap that is widening in both directions simultaneously. Companies that built their processes on informal practices, tribal knowledge, and Word documents are discovering that those practices do not survive contact with a serious FDA review. And when they go looking for experienced systems engineers who can close that gap, they find the market thin and expensive.
This is not a temporary hiring crunch. It reflects deeper structural issues in how the medical device industry has historically treated systems engineering — as a compliance activity rather than an engineering discipline — and what it now costs to retrofit rigor into organizations that never built it into their foundations.
What the FDA Actually Expects Now
The FDA has not published a single document called “here is our systems engineering standard.” What it has done, across multiple years of updated guidance, warning letters, and Q-submission feedback, is systematically raise expectations for the quality of engineering evidence in 510(k) and PMA submissions.
The 2023 update to the Design Controls guidance reinforced requirements that design inputs be traceable to design outputs, that hazard analysis be connected to design decisions, and that verification and validation activities be linked to specific requirements. The FDA’s Digital Health Center of Excellence has published additional expectations for software-containing devices that go further: architecture documentation, cybersecurity traceability, and evidence that risk controls were engineered rather than asserted.
What this means in practice is that a submission increasingly needs to tell a coherent engineering story — not just assemble a document package. Reviewers want to follow a thread from a user need to a system requirement to a design choice to a verification activity to a risk control. When that thread is broken, or when it exists only in the minds of the engineers who built the device and not in any artifact the reviewer can examine, submissions get held up, additional information requests multiply, and approval timelines stretch.
For PMA submissions, the standard is even more demanding. The FDA can and does ask for evidence of how requirements were derived, how design alternatives were evaluated, and how the systems engineering process itself was controlled. These are not gotcha questions for the unprepared — they are the expected outputs of a functioning systems engineering process. The problem is that many device makers have never had one.
The EU MDR landscape compounds this. The Medical Device Regulation, now fully in effect after the post-COVID transition extensions, requires technical documentation that demonstrates a systematic approach to design and risk management. Notified bodies are increasingly asking for evidence of requirement traceability and for documentation that shows the connection between clinical evaluation, risk analysis, and engineering decisions. Device makers selling into both markets face dual compliance burdens with overlapping but not identical expectations.
The Compound Shortage
Systems engineering as a discipline has a workforce problem independent of medical devices. The systems engineering talent pool in the US has been heavily concentrated in defense and aerospace, where the practice has been mandatory on major programs for decades. That concentration means the pipeline of new practitioners is shaped by defense program needs, not medical device needs.
When a medical device company goes looking for a systems engineer, they are often competing against Lockheed, Raytheon, Boeing, and the primes, who can offer larger programs, higher salaries in some cases, and — critically — more established systems engineering cultures. The work is less ambiguous at a defense contractor with an EIA-632 or INCOSE-based process. At a medical device startup, a new systems engineer may be asked to build the process from scratch while simultaneously delivering a submission artifact under time pressure.
The second layer of the shortage is domain knowledge. Medical device systems engineering is not just systems engineering applied to medical hardware. It requires understanding 21 CFR Part 820, the Design Controls framework, FDA’s risk management expectations under ISO 14971, the specific hazard analysis methodologies relevant to the device type (FMEA, FTA, HAZOP), and increasingly, cybersecurity requirements under FDA’s updated guidance. A systems engineer from aerospace can learn these, but it takes time — typically 12 to 18 months before they are genuinely productive without supervision on a submission.
The third layer is toolchain fluency. The traditional toolchain for medical device systems engineering — IBM DOORS, DOORS Next, or one of the document-management-heavy alternatives — has a notoriously steep learning curve. DOORS in particular was designed for defense program structures and carries decades of accumulated complexity. Engineers who have not used it in a program context often struggle to be productive without formal training that can take weeks. Companies that have customized their DOORS installations heavily compound this problem: a new hire may need to learn not just DOORS but a specific firm’s idiosyncratic implementation of it.
The combined result is that a medical device company looking for someone who knows systems engineering, knows medical device regulation, and knows modern toolchains is looking for a small intersection of a small set.
What Companies Are Doing
The response from device makers has been uneven. Large companies — Boston Scientific, Medtronic, Abbott — have the resources to maintain internal systems engineering capability, run formal onboarding programs, and invest in toolchain infrastructure. For them, the shortage is a headache. For mid-size and smaller device companies, it is closer to an existential risk.
Structured onboarding and internal academies. Some larger device makers have formalized what used to be informal apprenticeship. Rather than expecting new engineers to absorb systems engineering practice through osmosis, they are running structured programs that combine domain education (regulatory framework, risk management methodology) with toolchain training. The goal is to compress that 12-to-18-month ramp time to something closer to 6 months. The programs that work best pair training with real program work from early on — engineers learn by doing, not just by attending sessions.
Cross-training adjacent engineers. Some companies are investing in training electrical engineers, software engineers, and mechanical engineers who already have medical device domain knowledge to take on systems engineering responsibilities. This is often faster than hiring a systems engineer and training them on the domain. The bottleneck becomes toolchain fluency and process discipline, not domain knowledge. The challenge is that systems thinking — the ability to reason about interfaces, emergent behavior, and allocation — is not easily taught in a short course. It develops through practice.
Outsourced systems engineering support. Contract engineering firms with medical device specialization have seen strong demand for systems engineering services. This model works for getting through a specific submission but does not build internal capability. Companies that rely on it for multiple programs often find themselves perpetually dependent on external support, with the associated cost and risk concentration.
Toolchain modernization. The most strategically significant response — and the one with the longest return horizon — is investing in tools that make good systems engineering practice more accessible to engineers who are not systems engineering specialists. This is where the structure of the toolchain matters enormously.
Legacy document-based tools require engineers to manually maintain traceability across separate documents, manage relationships between requirements manually, and construct compliance evidence through document assembly. This approach demands high expertise to execute correctly and is extremely brittle — a single engineer leaving can leave a traceability structure that no one else fully understands.
Graph-based, model-driven tools handle these structural relationships natively. When a requirement is linked to a design element, to a verification activity, and to a hazard control, the tool maintains and queries those relationships. Traceability is not a separate artifact to be constructed — it is a query on the model. This architectural difference has real consequences for team capability: engineers who are not systems engineering specialists can contribute to a well-structured model without needing to understand the full traceability architecture they are working within.
Flow Engineering takes this architecture seriously in the medical device context. Its graph-based requirement model connects user needs, system requirements, design elements, and verification activities in a structure that reflects how FDA expects to see design justification presented. For teams that are growing their systems engineering capability, this matters: a less experienced engineer adding requirements to a well-structured model is much less likely to introduce traceability gaps than the same engineer editing a requirements document in a traditional tool. The model enforces relationships that document management tools leave to human discipline.
This is not a substitute for systems engineering expertise. Someone needs to design the model structure, define the requirement hierarchy, and make the engineering judgments about what connects to what. But it does lower the floor for contribution and raises the floor for quality, which is exactly what organizations with thin systems engineering bench depth need.
The Honest Assessment
Toolchain modernization does not solve the talent shortage. It changes the shape of what you need. Organizations moving from legacy document-based tools to model-based approaches still need systems engineering expertise to configure the process, train the team, and review the outputs. What changes is the leverage: one strong systems engineer in a model-based environment can maintain oversight of a larger team’s work more effectively than the same engineer in a document-based environment, because the model makes relationships visible and auditable in ways that distributed documents do not.
The talent gap is real and will not close quickly. The INCOSE-certified systems engineer population is not growing fast enough to meet demand across all the industries competing for it. Medical device companies that have historically underinvested in systems engineering are not going to close the gap through hiring alone.
The companies that are navigating this most effectively are treating the problem as two parallel investments: building human capability through structured development programs, and building toolchain infrastructure that raises the quality floor for the entire team. Neither substitutes for the other. Together, they shift the organization from one that depends on individual heroics to one where good systems engineering practice is encoded in processes and tools that survive personnel turnover.
The FDA’s expectations are not going to decrease. The EU MDR requirements are not going to simplify. Device makers that treat systems engineering as a compliance checkbox to be checked at submission time will continue to find it expensive and unreliable. Those that build it into the fabric of how they develop products — with the talent and the tools to support it — will find that it pays for itself in faster reviews, fewer deficiency letters, and products that actually behave the way their specifications say they will.
That last part, of course, is not just a regulatory benefit. It is the point.