Part 5 – Lets Gather a Few Good Friends

In previous articles we focused on quality systems and design controls: how they relate to each other in practice; how they embody established best practices that are not taught in engineering schools; and how they should be burned in to, taught, and propagated within the culture of any engineering organization.  In this article we start to focus more on organizational structure and organizational issues that are critical to effectively producing high-quality product.  As we have noted earlier, just having a quality system is not enough!

Frequently a project for a medical device, combination device, or a pharmaceutical, starts with the vision and drive of an individual.  That individual is able to “sell”[1] their concept to a like-minded group of others.  In doing so, they form the nucleus of a team which then grows to carry the concept forward[2].  Often this process of project growth is the same regardless of whether that initial individual resides within a tiny start-up, a small, or a large organization.  There is great power in the ability of an individual to sell their concepts and to crystalize a team around that person’s vision.  Hargadon’s insight in this regard is remarkable.  But this process can be risky if it is not managed carefully.

Consider the fundamental teachings of Design Controls: they hold that the development/discovery team strives first to understand the needs of the stakeholders (users, patients, payers, the business, regulatory agencies, etc.).  Those needs are then translated in to requirements statements.  Nowhere, at that initial stage, is there any mention of designs. The reality is that frequently a project starts with a design concept pitched to the business and development team.  This reality is often driven by the experience that funding or support from investors or corporate leaders seldom comes from just words delivered:  some kind of semi-functional prototype that people can touch and feel and have faith in is needed.  The authors recognize and support the role prototypes play in building understanding and support.  The critical difference is in the needed level of complexity and completeness of that prototype.  As engineers, we often have a predilection to drive prototypes to a “final” design.  However, a quickly and cheaply made 3-D print, or a paper mock-up of a display screen (thus avoiding time spent writing software) can be very effective in telling a story.  We also need to set appropriate expectations with investors and supporters.  Change the story from “this is what I will build” to “this is an example of what I can build.”  This can be a fine line to walk – but we must learn to do it.

Learning to walk this line is critical: the risks of starting with an embedded design concept are multiple and specifically contradict both adherence to design controls and to designing  high-quality product. If the individuals involved, and the organization itself, become overly invested in the design concept, it can be, and frequently is, defended and pushed forward, even in the face of significantly increasing hurdles in technical problems, cost, and time.  Often this occurs to the death of the project and the detriment of the organization.  All of this is seen in the vignette posed in Part 1 of this series of articles.  In the vignette, the design team is not allowed to settle on the true requirements of their product; they are overruled by the champion and are pushed forward with the design originally pitched to the organization.  The result in the vignette is a design that is difficult to manufacture (high scrap rate) and with parts that are becoming obsolete.  The outcome is a higher-than-projected cost of the product, a product that does not meet the needs of the customers and stakeholders, a product that fails at an unacceptable rate, and unacceptably high customer support costs.  The costs created by a rocky design process do not stop when the design process is finished.

As humans we look at the sunk cost of the project, and want desperately for that investment not to have been wasted: we are all susceptible to this “loss aversion”[3].  Make no mistake: this is a powerful and unconscious drive that can subvert data-driven decision making.  We sacrifice quality for the sake of “getting the project done.”  We justify design requirements after the fact, and defend the project despite its hurdles and costs – until everything falls apart.

Does this sound like a familiar experience to you?

Clearly, a dynamic leader around whom a team can crystalize is needed, or at least is greatly beneficial.  But, how do we resolve the conflict between the leader’s vision and design flexibility?  First, we need to recognize that none of us sees the world as it truly is.  Rather, we see the world nearly completely through the lens of our own expectations. This important concept is well described, from Kahneman’s descriptions of cognitive bias, to Benjamin Zanders’ Rule # 1: “It’s all made up.[4]”  Truly internalizing this concept is important: it is a critical first step that empowers the leader and team to recognize that that an initial design concept likely sprang from such biases.  Internalizing this concept will also aid the team’s understanding that the initial concept may well not be able to achieve acceptable quality.

How can a team avoid falling in to the trap of devotion to an initial design concept?  After all, it is natural that we might become enamored with a unique, personal, design.  Fortunately, there is a completely mechanistic method to help us avoid our personal biases … from that method derives the title of this article.

The leader, the originator of the product idea, will typically reach out to people known to be of like mind to herself (or himself).  These people are more likely to get “on board” with the project, work on it, and help “sell” it to others.  In short, we naturally “gather a few good friends.”  Right?

Not so fast.  This is exactly what we do not want to do. What we do need to do is … uncomfortable (but powerful).  To describe why and what this more effective approach is, lets present a teaching tool that author Hamlen has used in teaching design methodologies.

Consider that we have a design goal, and are seeking to understand the greatest breadth of design options that will achieve those goals.  The square below is meant to represent the entire breadth of human knowledge pertinent to our design problem:

Consider that author Hamlen, trained as a Chemical Engineer with experience in computational modeling of designs, brings to bear his background and knowledge to solve this design problem.  Of the total available knowledge, his knowledge might be represented as the blue circle in the diagram below:

To build the team, Hamlen reaches out to a good friend from the same Chemical Engineering program.  Call that person, “Joe”.  On the diagram below, Joe’s likely scope of knowledge is indicated by the circle in red.  Hamlen also reaches out to “Sue,” a mechanical engineer with whom he has worked closely, specifically on computational modeling of designs.  “Sue’s” available knowledge on this subject is indicated by the circle in green on the diagram below:

The problem becomes clear: by reaching out to only those who are “like me” –  those with whom I work well and who I expect (or want!) to “confirm my perspective” – I do not avail myself of different perspectives that will challenge the inviolability of my initial personal design idea.

There is an important concept to understand here known as the Strength of Weak Ties[5].  A fun, more current-day example demonstrating this concept arises from a global, WWW-enabled, study of the “small-world” phenomenon.  This phenomenon is otherwise known as the “six degrees of separation” theory that has been popularized through the “six degrees of Kevin Bacon” game.  The WWW-enabled demonstration[6] defined 18 “target” persons in 13 countries, and challenged more than 60,000 e-mail users to get a message to one of the “targets.”  The study’s findings showed that successful attempts to reach the target primarily used intermediate-to-weak “social” ties.   Further, they found that only 5 – 7 “steps” were needed to reach the target – a small world indeed!

The strength of weak ties holds that the collection of those whom I know “just a little” has access to much more information than do I and my close associates.

So, in trying to determine potential design options for his product, ChemE author Hamlen, should not reach out to ChemE “Joe,” but perhaps should reach out to author Parsons (with training in Microbiology, and extensive experience in Quality System deployment), and also to an acquaintance of Parsons, “Barb”, who is a EE, and also to a friend of Barb’s, “Peter,” who is in marketing, etc.  By doing so, the breadth of human knowledge pertinent to our design problem that is actually available to the team is significantly increased, as is illustrated in the diagram below:

By taking this approach to building the team – accessing people you “know a little,” and who have knowledge and perspective different from your own – you make available to the team a greater breadth of knowledge and experience.  The result is an increase in the likelihood of: 1) detecting deficiencies and pitfalls in that first “pet” design concept, and 2) identifying alternate design concepts that both avoid the pitfalls of the first, and that better meet  the stakeholders’ needs.  As Kahneman (Thinking Fast and Slow) would state: “other people have a superior ability to detect the flaws in our own logical arguments than we do ourselves.”

Note that taking this approach is a purely mechanical and conscious activity – no “learning” or additional “skills” are needed.  Simply enforce the choice not to bring your “friends” on board to the team, and be open to challenges to the initial design concept.  There is an apparent price to pay when taking this approach: friction in the team.  Imagine what is bound to happen when author Hamlen assembles the team, and presents the bright, shiny, initial design concept that he is convinced is the best idea ever.  Peter, who arrives at this project with a very different set of experiences and preconceptions from Hamlen, will say something like “that is a stupid idea … it will never work”; or, “I think this other idea that I have is better.”

Likely, most of you have seen this happen before.

Friction is uncomfortable – so we avoid it.  That avoidance is why we tend to build teams with people we know we have worked “well” with in the past.  However, a certain degree of friction is exactly what a development team should expect, create, and embrace.  That friction, and the discussion that goes with it, uncovers the hidden flaws that reduce quality in a design, while identifying alternative designs that arise from the greater body of available knowledge.  This process leads to a high-quality product.  Creating, capturing, and nursing disagreement is the secret the team and its leaders need to master.  Patrick Lencioni[7] addresses this as the need to erase “fear of conflict,” embracing healthy conflict through candid debate.

Actually accomplishing this is not easy, but it can be done.  It starts with the team leader setting the stage for conflict by assembling a diverse team.  It is further fostered by enforcing the team norm that candid debate is expected, and that alternative views will be listened to and incorporated into the team decision.  The initiator of the project idea must be willing to “let go” of his/her initial design concept.  Doing so does not make the time spent on the initial concept a “waste” – rather it becomes the critical “seed” that sparks meaningful discussion by the team.

Another point to strongly consider in nurturing and managing constructive conflict is one made in one of our earlier articles: many of the decision-making “tools” taught in Six Sigma and Design for Six Sigma are actually methodologies to build consensus in a team or organization.  Organizations should learn to use the disciplines’ methodologies, at the right time and place, to build consensus around design decisions.  When this is not enough, and a team is not able to work constructively through differing perspectives, consider using a trained and experienced facilitator.  Using a facilitator is nothing to fear, as doing so is really just continued embracement of the value constructive conflict.

Further Thoughts: On Stakeholder Needs and Requirements, not Designs:

Closely associated with the need for a team to look past and not get stuck in “initial” design ideas is the best practices teaching that a project should start with a definition of “requirements” for the product, not a design.  As stated in earlier articles, this teaching comes equally from the engineering disciplines of project management, systems engineering, Six Sigma, and design for Six Sigma.  By reducing the product concept to a high-level, generalized, statement involving neither design not testing elements, the team is freed from the fixation on an “initial” concept.  This opens their attention to alternate concepts that might be of higher quality.  This is also exactly the effect of taking the up-front time in the TRIZ[8] methodology to define the “Ideal Final Result” … which is really nothing more than a requirement statement.  When done correctly, the team members should experience an “Aha!” moment, with a thought of something like “Oh – that is what we are really trying to accomplish!”

Taking the time to work from design-free requirements, and using those requirements to guide the design selection, is key to achieving a high-quality design.  The power of that key step is lost when the team focuses on trying to make an initial design concept “work,” despite the obstacles encountered.

Further Thoughts: On the Power of Usability Engineering:

It is also important that the team members, sitting in their office or lab, understand the risk of conflating their own perception of a user’s need and that of the user’s actual need.  Surprisingly often the team members’ belief does not reflect the real user’s need or method of accomplishing a task.  This approach (call it “armchair engineering”) often leads to poor quality designs (at least one of the authors will admit to having learned this lesson the hard way).

A memorable image to drive this point home is the “Coffeepot for Masochists” image used by Don Norman, and introduced in his classic text “The Design of Everyday Things[9]”:

(Photo courtesy of Don Norman)

Don Norman is one of the pioneers of “human factors” engineering (today more commonly called “usability engineering”).  Norman’s original thesis basically held two points: 1) a design should be intuitively “obvious” as to how you use it (i.e. no manual should be needed), and 2) the design should meet the real needs of the user.  The Coffeepot example is exemplary as a counter-example: it is not clear how it should be used … and it certainly does not meet the needs of a user (unless the user is indeed a masochist)!

A better approach than sitting in the office or laboratory is to connect with potential users through Voice of the Customer (VOC) exercises, in which the purpose of a new device is described to them.  Let the users voice opinions regarding how they use a current device or would envision using the new device.  Sift through comments looking for what may eventually be adopted as requirements for the product.

For the purpose of the current series of articles, one cannot escape the reality that proper application of usability engineering is intimately tied to achieving high quality product: a user who views a product as “difficult to use” or “difficult to understand” will view the product as being of poor quality … regardless of the verification results of the design team.

© DPMInsight, LLC 2017 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 certification, 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 currently supports various organizations in remediation and compliance projects through Raland Compliance Partners (RCP) .

Michael B. Falkow

Michael Falkow is a Quality Specialist with Raland Compliance Partners. He has served as a regulatory compliance and quality assurance executive with multi-facility/international companies and was an FDA Compliance Officer and Senior Investigator/Drug Specialist.  Michael has subject matter expertise for quality and regulatory compliance, quality auditing, quality assurance, quality control, supplier evaluation and certification, and compliance remediation.  He has been approved by FDA as a GMP certifying authority and is qualified to provide Expert Witness testimony for GMPs.

Currently – Adjunct Professor at Mercer County Community College – teaching courses on Clinical Development for Certificate Program in Clinical Research as part of Drexel University’s Masters Degree in Clinical Development.


[1]The value of technical people being able to sell an idea within an organization, or to a broader audience, is worthy of in-depth discussion, but must be relegated to a later article.

[2] In his book “How Breakthroughs Happen,” Andrew Hargadon describes this near-spontaneous growth of successful energetic teams as akin to a “phase change” in a material.  A phase change is the result of a gathering of like material around a nucleation site, which causes a segregation of “like” material from “un-like” material.  In the same way, like-minded individuals associate with and gather around themselves, sparked by the vision and concepts of an individual.

[3] See “Thinking, Fast and Slow”, Daniel Kahneman, Farrar, Straus and Giroux, 2011.

[4] “The Art of Possibility: Transforming Professional and Personal Life,” Rosamund Zander and Benjamin Zander,” Penguin Books, 2002.  (those who have not seen Benjamin Zander present this material might want to search out videos of him on the Web.  Watching and listening to him is a special opportunity.)

[5] “The Strength of Weak Ties”. Granovetter, M. S. The American Journal of Sociology 78(6):1360-1380. 1973.

[6] “An Experimental Study of Search in Global Social Networks”. Dodds, P. S., Muhamad, R., and Watts, D. J. Science 301: 827-829. 2003.

[7] “The Five Dysfunctions of a Team: A Leadership Fable”. Patrick Lencioni. Jossey-Bass. 2002.

[8] TRIZ (“trees”) is a design and problem solving approach first developed by the Soviet inventor Genrich Altshuller.  See:

[9] “The Design of Everyday Things”. Donald A. Norman. Basic Books (reprint edition). 2002.

Leave a Reply

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