-
NPI: A How To Guide for Engineers & Their Leaders
-
Leading from the Front
-
Marcel Tremblay: The Olympic Mindset & Engineering Leadership
-
Anurag Gupta: Framework to Accelerate NPI
-
Kyle Wiens on Why Design Repairability is Good for Business
-
Nathan Ackerman on NPI: Do The Hard Thing First
-
JDM Operational Excellence in NPI
-
Building the Team
-
Quality is Set in Development & Maintained in Production
-
3 Lessons from Tesla’s Former NPI Leader
-
Maik Duwensee: The Future of Hardware Integrity & Reliabilitypopular
-
Reject Fake NPI Schedules to Ship on Time
-
Leadership Guidance for Failure to Meet Exit Criteria
-
-
Screws & Glue: Getting Stuff Done
-
Choosing the best CAD software for product design
-
Screws vs Glues in Design, Assembly, & Repair
-
Best Practices for Glue in Electronics
-
A Practical Guide to Magnets
-
Inspection 101: Measurements
-
A Primer on Color Matching
-
OK2Fly Checklists
-
Developing Your Reliability Test Suite
-
Guide to DOEs (Design of Experiments)
-
Ten Chinese phrases for your next build
-
-
NPI Processes & Workflows
-
-
Production: A Primer for Operations, Quality, & Their Leaders
-
Leading for Scale
-
Proven Strategies for Collaborating with Contract Manufacturers
-
Greg Reichow’s Manufacturing Process Performance Quadrants
-
8D Problem Solving: Sam Bowen Describes the Power of Stopping
-
Cut Costs by Getting Your Engineers in the Field
-
Garrett Bastable on Building Your Own Factory
-
Oracle Supply Chain Leader Mitigates Risk with Better Relationships
-
Brendan Green on Working with Manufacturers
-
Surviving Disaster: A Lesson in Quality from Marcy Alstott
-
-
Ship It!
-
Production Processes & Workflows
-
Failure Analysis Methods for Product Design Engineers: Tools and Techniques
-
-
Thinking Ahead: How to Evaluate New Technologies
-
How to Buy Software (for Hardware Leaders who Usually Don’t)
-
Adopting AI in the Aerospace and Defense Electronics Space
-
Build vs Buy: A Guide to Implementing Smart Manufacturing Technology
-
Leonel Leal on How Engineers Should Frame a Business Case for Innovation
-
Saw through the Buzzwords
-
Managed Cloud vs Self-Hosted Cloud vs On-Premises for Manufacturing Data
-
AOI, Smart AOI, & Beyond: Keyence vs Cognex vs Instrumentalpopular
-
Visual Inspection AI: AWS Lookout, Landing AI, & Instrumental
-
Manual Inspection vs. AI Inspection with Instrumentalpopular
-
Electronics Assembly Automation Tipping Points
-
CTO of ASUS: Systems Integrators for Manufacturing Automation Don't Scale
-
-
ROI-Driven Business Cases & Realized Value
-
Being a product design engineer at Apple was about managing fear. The wrong design choice or decision could easily cost millions of dollars in units that had to be reworked or scrapped; an unexpected issue missed in a product failure analysis or not resolved early enough could delay a product launch enough to move global markets. In a small company, the ramifications are still severe — missing Christmas can kill a consumer electronic company, or a bad design decision can necessitate a 6-month hold while more funding is raised. Hardware engineers are heavily responsible for products and outcomes regardless of company size.
How fear motivates your engineers
The Apple I experienced did not have a blame culture — but with its famous DRI system (Directly Responsible Individual), it was always clear who was “on the hook” for a given part, feature, or solution. Before being given any real responsibility at Apple, I saw my peers go through a grueling late-development issue. It made an impression. From then on, I wanted to be sure that any decision I made was defensible — so much so that for years I had a folder on my desktop filled with “just in case” one-page Keynote slides summarizing the data that defended my decisions. That folder of Keynotes was all about managing my fear of blame.
Fear of blame can motivate design choices, but the most dangerous place it can play out is by clouding truth in the failure analysis process.
Fear of blame can motivate design choices, but the most dangerous place it can play out is by clouding truth in the failure analysis process. There are often costs associated with something going wrong or the changes needed to fix it — and those costs, combined with simple engineering pride, create conflicting motivations for the multi-party system (product company, manufacturer, parts suppliers) that can create significant delays in the failure analysis and corrective action process.
Three common problems
Development and mass production issues come in several flavors.
"Vanilla" problems are straightforward and often have straightforward solutions: fingers bend antenna elements, so a fixture to protect them eliminates the bending. Slightly more difficult are intermittent issues — where the same unit can pass and fail when it’s tested multiple times. The canonical example is a solder joint crack, where broken leads can sometimes be connected and other times not, especially during and after thermal testing.
Layered “Onion” problems are some of the worst because their true form is usually not discovered until late development. An Onion problem presents one way, but as you try to fix it, you realize there’s another underlying problem. Sometimes there could be four or five layers — and as a result, these can take weeks or even months to resolve fully.
The last type of problem is the “Enigma” problem — one that defies understanding and, therefore, cannot truly be fixed, only mitigated to reduce its impact. As an engineer, it pains me to admit that such a problem is even possible: everything has cause and effect, right? But there are limitations to what you can control and what you can measure in every process, creating the possibility of an enigma. In my seven years in this space, I’ve only experienced one enigma problem: a reliability issue on assemblies made from parts from certain cavities of certain injection molding tools. Try as I might, I could not correlate the failures to any of the hundreds of dimensions on the well-controlled part drawing. Ultimately, there was no root cause, only a mitigation: each cavity had to be qualified separately.
Getting lost in the root cause spiral
All of these issues stem from several standard root causes:
- Workmanship: human error, sloppiness, or poor training
- Part Quality: incoming cosmetic, dimensional, or functional defects
- Process: incorrect parameters, settings, or order of operations
- Design: even if all of the above are done well, it doesn’t work; often results from not taking process, quality, and/or workmanship variations into effect
Once a root cause is identified, its type determines who the DRI is to fix it (and often who pays for the remedy). Part quality issues are the responsibility of the upstream supplier; workmanship issues are (usually) the responsibility of the contract manufacturer; process issues can fall anywhere between the product company and the contract manufacturer; and design issues are the product company’s to resolve.
At this point, it’s not just about simple blame anymore: money is involved. The politics can get fierce, creating bias in the failure analysis process. If the engineer doing the analysis is from the product company, most likely, she will want to eliminate all potential root causes first before admitting a design issue (I think this is more human nature than politics). If a factory engineer does the failure analysis, the conclusion may be that the design makes a reliable mass production process infeasible. In this blame game, both sides lose: a lot of precious time is wasted trying to defend or push a politically motivated position instead of getting to the bottom of the issue.