Run a strong development team with systems engineering principles and you can  hire better people, faster.  That’s a major proposition for the pharmaceutical and medical device industries, who are having a hard time finding the right people for the job.  “Medtech” should stop hiring only people from “Medtech”, which is a lot easier when you have a systems-driven practice in place.


Let’s review a few cases:

Pharma Company #1 is in the US, but can’ seem to find the right people to hire.  They run about 30% contract staff, many from out of state.  They claim they can’t find the quality of individual they are looking for, despite being surrounded by a mecca of engineering talent.

Pharma Company #2 is in the EU (Europe).  They are running about 30-40% temp engineering staff.  This is in part due to the rapid scale up in combination product activities after recent FDA regulations.  There aren’t many medical device engineers in their area.  They can’t find enough temp staff or employees to fill their ranks.

Pharma Company #3 is having a hard time finding talent.  They’ve had so many challenges in recruiting, they’ve decided to create a satellite engineering group in another city. That city supposedly has more talent for hire.  Contrast this with Pharma Company #1, who can’t seem to hire amidst the mecca of engineering.

Medical Device Company #4 just spent 8 months in live interviews with 12 candidates, and countless others before that cut, without making a single hire,

So what’s the common thread across these companies?  They are all working in the medical device space and focused, almost entirely, on hiring medical device engineers.  Is that optimal?  No.  Is that necessarily bad?  Probably.  These companies feel that they need a company full of medical device engineers to design a medical device correctly.


You don’t need a company full of medical device engineers to design a medical device correctly, you need a DevOps process that enables development personnel of many flavors to develop a medical device… safely and effectively… which I had to say for my colleagues at the FDA ;).  Not everybody has to be a medical device expert!

So how does a systems engineering focus help solve this challenge?  Medical device regulations such as CFR 820.30 tell us WHAT we have to do to develop a medical device correctly… but they don’t tell us HOW do develop a medical device effectively.  That’s the core of systems engineering.  It starts with disciplined processes for tech-feasibility, tech-development, architecture, requirements, verification, and interface definitions.  Structure these processes and your teams correctly, and every engineer can work within their defined system bounds without need for being a medical device expert.

Limiting hires to only medical device experts is often a crutch for a weak development organization.  That can have it’s time and place, and we’ve often been hired to improve or remediate programs by sheer force of expertise and strong execution… but the highest value programs are those to which we can apply systems engineering principles from the start… to develop an effective project, an effective organization, … a learning organization.

Apply systems engineering and your company can hire top talent from outside and inside your domain.

I had a great conversation with a colleague while at the 2014 PDA “Universe of Pre-filled Syringes and Injection Devices” conference.  Mike is a 15-year veteran of the pharma and medical device world and has seen examples of both good and bad engineering practices.  We talked about the discipline of system engineering and why it is necessary to the successful completion of programs.  I realized that one of the difficulties in getting organizations to adopt systems engineering is one of nomenclature: systems engineering does not have the awareness it deserves because in some organizations that it’s just called “[good] engineering”.  In these organizations, “systems engineering” practices, though not by name, are the crucial component of how to do engineering well.

Mike told me that 3M’s biotech divisions have followed this.  Suttons Creek team members who have worked at Lockheed Martin confirm that aerospace companies follow this model. In each case, systems engineering is part of the company culture, though only one company has a formal systems engineering department. Systems thinking pervades the entire organization, and everyone in the corporation is trained on it.  Unfortunately, even Fortune 200 companies sometimes fail to define a strong process for product development that can handle our increasingly complex and integrated world.

Let’s consider a current example for why systems engineering is needed from the pharmaceutical industry: the growth of combination products. Pharmaceutical companies are working on large-molecule, biologic drugs that require injection systems.  These companies don’t have the expertise in-house to develop electromechanical systems, so they outsource to many vendors. But which vendors should you choose? And how do you integrate what they do with your product?

It doesn’t get easier if you decide to build an engineering team in-house. Consider a pharmaceutical company with 3 engineering teams that are tasked with designing a new drug delivery technology. The mechanical engineering team is more likely to design a mechanical auto-injector.  The electrical engineering team might build a transdermal iontophoresis device.  A software engineering team might recommend you create a electromechanical patch injector that has many indicators and sensors…  and you guessed it…. those features require software.   So who is right?  How are all the variables in that complex decision managed?

In many companies, there is no clear authority, and so it ends up falling to politics: the VP of R&D started out as Mechanical Engineer, so the mechanical engineering team wins. But it is the job of a systems engineer, or someone serving that function, to properly answer this question.  It takes a strong technical leader to make a balanced decision based on all of the inputs, including human factors, development time, business risk, cost schedules, reliability, etc.  It takes someone who has systems engineering training, whether through education or practice, and often both.  This is one of the things we try to impart upon our clients: one component of “doing engineering well” is learning how to manage the technical aspects of programs with a variety of tools, none of which is a soldering iron.