Part 10 – It’s the Thought That Counts

A common observation made by hiring managers, especially in the medical device industry but also in the pharmaceutical industry, is a lack of experienced people to fill their open positions.  Our belief is that the typical hiring process frequently asks the wrong questions.  This, at times, actively hinders identification and access to qualified individuals who would otherwise greatly benefit the hiring organization.  In this article, we discuss three hiring practices that we believe artificially reduces the apparent talent pool size, and which ultimately inhibit high product quality.

To illustrate this, let us return to a portion of the job description posited in our third article Everything I Know I Learned After College:


Senior / Principal Quality Lead

“ …

Skills needed:

  • Competency in Statistical techniques: Gauge R&R, SPC, process capability, sampling plans and sample size determination, DOE, ANOVA, Regression, Lean
  • Design FMEA, process FMEA


  • Practical knowledge of FDA Quality Systems Regulations, ISO 13485 (medical device quality management systems), ISO 14971 (Risk Management), IEC 62366 (usability engineering)
  • Previous experience working in an FDA regulated environment



On the surface these requirements seem reasonable, consisting of knowledge of a series of techniques and tools, and experience working in quality systems associated with the FDA and medical devices.  But this type of job description, or hiring ad, masks two underlying problems:

  • Listing a set of skills often conflates “skills” with “tools”
  • The insistence of experience with FDA-associated quality systems ignores the value and content of other quality systems.


Tools Versus Skills:

What do we mean by “skills” versus “tools,” and why is it misleading to focus on tools as part of the hiring process?  These days, “tools” are most often computer programs: Microsoft Project, Excel, Minitab, JMP, SAS, DOORS and so on.  Frequently, candidates are critically assessed on whether they have familiarity with a given piece of software.  The candidate may answer “yes” – they know the software.  This may mean they know how to access the menus and know what functional items are present in which menu.  But they may not know how to use the software effectively, which is what a “skill” is.

The hiring process is often reduced to keyword searches or quick questions identifying whether candidates have used a specific “tool.”  Yet, internally to an organization people can easily, and derogatorily, become labeled as a “tool jockey.”  Such labeling occurs because of the perception, one that is often correct, that the tool being used does not add value to the overall effort because it is not being used effectively.  The reasons for this are related to the arguments we have made previously regarding too much data (see especially: Is This Really a Requirement, and It’s the Destination – Not the Journey).  The fundamental issue is then to focus on what is essential to be done.  Unfortunately, many “tools,” and using too many tools in total, make it extremely easy to lose that focus.

For example, take requirements management tools like DOORS or Cognition Cockpit.  With these software packages, it becomes easy to enter a requirement and then create a link to a lower level requirement or to a design output (often involving several “layers” of requirements).  It therefore becomes tempting to just “throw it all in there” and let the software keep track of everything.  But when we take that approach, we are not exercising the critical thought we argue for in the article Is This Really a Requirement.  “Just throwing it all in there” usually creates a complexity of interactions that results in a tangle of information that is either logically wrong, or so complex that it cannot be understood and communicated!

Or in another example, take tools that easily enable Statistical Process Control such as Minitab, JMP, or SAS.  Keep in mind that when Statistical Process Control was created by Walter Shewhart in the 1920’s, calculators or computers did not exist.  Because of this, he created a process that was easy to execute using only a pencil, graph paper, and look-up tables (check out Deming’s book Out of the Crisis: many of the control chart examples given therein are photocopies of hand-drawn control charts).

With the computer-based software available today, creating control charts is a near mindless activity.  The result is that too often control charts are created without understanding the underlying principles.   This lead to incorrect or inapplicable results, one family of which is described in:  Equally damaging is the temptation to apply control charts to everything.  The result is so much data that there are not enough resources to review it, and thus none of the data are actionable.  As we’ve argued in our article, Is this Really a Requirement, effective control charts should provide immediately actionable data associated with critical design outputs.  Moreover, they should be used thoughtfully and with a specific “question” being asked of the analysis.  To do otherwise is not an effective use the tool.

Finally, let’s take a look the very popular Microsoft Project.  Project is a wonderful tool: it allows the project manager to understand and communicate the time frame of a project, determine interactions between tasks, assign resources, determine costs, determine budgets, and track adherence, or non-adherence, to the project plan.  Yet, the ease with which those data can be entered into the program, down to the minutest of detail in sub-tasks, frequently leads to “bloat.”  How many of us have seen Project output printed on a poster printer hung to cover entire walls?  More than a few of us!  But, if the object of software such as this is to aid understanding and communication of a project plan and its execution status, such detail is, at best, obfuscatory.  At worst, it creates errors arising from the very complexity that is entered.

To repeat: knowing where the “buttons” on a program are is not the same as knowing how to effectively use the tool – and volume is definitely not the same as quality when it comes to the data entered in to such a program.

When we spoke earlier of the so-called “tool jockey” we were referring to the perception that arises when someone uses a tool ineffectively, thus yielding no benefit to the organization.  So, when it comes to evaluating a potential candidate, we should not evaluate them on whether they know how to use a specific tool.  Rather, we should evaluate them on whether they know how to effectively implement the underlying principles the tool is facilitating.  Any tool can be learned, usually rather quickly.  This is especially true if you find the right person, i.e. one who truly understands the underlying principles.


Do I Really Need Someone Who Has Done This Before?

Frequently a job posting will list a role, job title, or an activity or series of activities that an applicant must have done in the past.  With regard to roles, or titles, this can be extremely misleading.  First, different titles can be equivalent in different companies.  Secondly, several individuals’ interpretation of the meaning of a given title can differ widely.  Third, just because an individual has held a given title does not mean that they executed that position well and suitably absorbed the lessons any job will impart on a person.

Looking for and hiring someone who has “done this before” can lead to the so-called “Peter Principle.”  Past success does not predict future success and past failures do not necessarily condemn a viable candidate.  Someone who has held a position of “validation engineer” may not be good at it.  Someone who has held a position of “Systems Engineer” may not be good at it.  And, someone who has held a “supervisory” position (Manager, Director, etc.) may not be good at it either.   Conversely, someone who has never held any of these positions might well excel at one or all of them.

Therefore, we recommend that we identify someone who has shown adaptability and an understanding and historical execution of the underlying needs of the new position regardless of past titles.  A person possessing these skills is most likely to succeed in the new position.  We have all seen someone excelling in a position where they have not performed the activity or role before.  This point has been made by Claudio Fernandez-Araoz (21st-Century Talent Spotting, Harvard Business Review, June 2014).

There is a more general conundrum here: somewhere, sometime, someone does something for a first time.  In the extreme case, if everyone were to only hire people who have done a given activity before, then hiring managers will never find a person to perform their activity.  This is an unrealistically extreme example, but the point is this: we likely do not have the lack of experienced people to fill open positions we think we do.  Rather, we are not effectively evaluating candidates on the appropriate criteria.  We don’t need people who have “done this before.”  Rather, we need people who have demonstrated the flexibility and capability to do the job the opening requires!


Calling All Quality Systems:

The job description that we re-visited at the beginning of this article stipulates that the applicant have:

  • Practical knowledge of FDA Quality Systems Regulations, ISO 13485 (medical device quality management systems), ISO 14971 (Risk Management), IEC 62366 (usability engineering)
  • Previous experience working in an FDA regulated environment

While working in the medical device field and Pharma fields, we place great emphasis on adhering to the regulations that govern us.  Indeed, we emplace an entire function, “Quality” to oversee this (though as we have discussed in earlier articles, “Quality” usually acts as a “Compliance” function – a practice that leads to great difficulties).  Because of this, it would appear to make great sense that we seek people with experience in our specific highly regulated environment.  In reality, this practice makes no sense at all.

The reasons for this last statement is threefold: first, there are a great many industries that are just as regulated as is the medical device industry many of which have requirements for quality systems; second, the quality systems those other industries follow, like ISO 9001and its kin for general manufacturing, Pharmaceuticals, Aerospace, Automotive, much of the food industry, etc., have far more in common with 21 CFR Part 820 than differences; third, many medical device companies “teach” their employees the regulations by way of having them follow the quality system and not by having them study the regulations directly.  Therefore, we find it surprising, perhaps even alarming, that many medical device company employees have not read the Parts 820 or 210/211 and related FDA regulations.

There are two implications flowing from the above points.  First, an employee coming to you from another medical device company may have a very different, and quite possibly incomplete or incorrect, “understanding” of the regulations compared to you and your company.  Second, an employee coming to you from another industry might well have an extremely good understanding of how to operate in a regulated environment: they will likely only need to become familiar with slight differences between their old quality system versus yours.

When we automatically exclude from our pool of applicants those who come from other industries, we artificially and inappropriately eliminate excellent candidates.  Also, we set too high an expectation on the regulatory knowledge of those coming from “within” the industry.  Both results do us and our organizations a great disservice.

Author Hamlen was quite heartened to see a recent job posting from a well-known medical device maker that simply asked that candidates come from a regulated industry (i.e. “Planes, Trains, and Automobiles”).  An executive at that company, when contacted to congratulate them on their openness to this approach, replied that they found great success in candidates from other regulated industries.  If more organizations would take that perspective, we will likely find that good people are not as hard to find as we would claim!

It’s the Thought That Counts:

The common thread in this article is, in broad stroke, one of looking for “understanding” versus having used a certain “tool.”  Software, in its various forms, is certainly a “tool”.  But so, arguably, are quality systems:  they are tools that we use to guide execution of the product development and deployment processes and the creation of associated documentation.  Likewise, job titles are a tool we use to guide us, unfortunately using a lot of hidden assumptions, to a belief about the core capabilities of a job candidate.

As we argued in the article A Quality System is Not Enough, when we do not truly understand the underlying principles of a system we are using, we are very open to mis-use of that system.  The same argument holds with any “tool” – especially those we have discussed here.  Software is extremely prone to over-use.  This over-use leads to complexity and obfuscation of the business and project insight the software is supposed to deliver to the user and to their audience.  Job titles are mis-used because they often are given great emphasis, but they mean different things to different people, and definitely do not reflect the fundamental capabilities and potential of an applicant.  Finally, believing that someone must have come from a 21 CFR 820 environment to understand and effectively execute the underlying principles of the associated quality system is not a valid belief.

As hiring managers, and supervisors of active employees, we need to stop relying on a few keywords to filter out and evaluate people.  Rather, we need to focus on their underlying understanding of the task at hand, whether it be running a piece of software, using a quality system, or supervising other employees.  As we have also argued several times in earlier articles, true fundamental understanding of a task or role usually leads to a reduction in complexity, reduction in confusion, and ultimately an increase in product quality.

© 2018 DPMInsight, LLC all rights reserved.

About the Authors:

Cushing Hamlen

Over 27 years of experience in industry, including 20 years with Medtronic, where he worked and consulted with many organizational functions, including research, systems engineering, product design, process design, manufacturing, and vendor management.  He has also worked with development, regulatory submission, and clinical trials of combination products using the pharma (IND) regulatory pathway.  He has been extensively involved with quality system (FDA and ISO) use and design, and is particularly concerned about effective understanding and use of product requirements and design controls.  He has formally taught elements of systems engineering, design for six sigma, Lean, and six sigma.  Cushing has degrees in chemistry and chemical engineering, is certified as a Project Management Professional, is certified as a Master Black Belt in Lean Sigma, and is the owner/member of DPMInsight, LLC (


Bob Parsons

Over 26 years of experience in leading Quality Assurance, Validation and remediation efforts in FDA regulated Medical Device and Pharmaceutical industry. Experience includes product development life cycle management from initial VOC through New Product Introductions (NPI), sustainable manufacturing, and end of life product management.  Technical expertise in quality system gap assessment, system enhancement, alignment and implementation of all quality elements including design controls, risk management, purchasing controls, change control and post-market surveillance.  Regulatory experience includes; ISO 13485, 9001 and 14971 certifications, providing guidance for FDA PMA/510K and CE clearance, designated Management Representative, company representative and lead during FDA and ISO audits, 483 and warning letter resolution with experience working within consent-decree environments.  Bob is currently Vice President at ProMed Molded Products, Inc.

Leave a Reply

Your email address will not be published. Required fields are marked *