Earlier this week, I ran into an investor seeking words of encouragement on behalf of a talented team working through multiple layers of issues on an already delayed product. “Is there some story you could tell me, that could help them not get discouraged?” he asked.
It’s these very stories, about catastrophes, that make up a hardware engineer’s mythology. They are told in hushed voices and with grim laughter in darkened factory vans speeding down highways or over late-night hotel dinners. I have heard so many and have lived my fair share — and yet, in the secretive world of hardware where all anyone sees is perfection, these are stories I cannot tell.
Instead, I suggested a different view: a long issues list is better than no issues list. The engineers who trained me entered each early build with a distinct goal in mind: as a team we are going to make a list of 100 issues with the product. It was called the MIL, the Main Issues List. Every day I was at a build, I would stand on the assembly line for hours with a small notebook in hand to write down whatever I could find:
Operator having difficulty removing pull tab from right to left
Most buttons feel mushy on 0.5mm shim config
Cosmetic gap is larger on the left than the right
Oily stain found on three units at finished good inspection
Four displays that passed functional incoming test failed after assembly
At the end of each day, I would proudly add a handful of new issues to the MIL, along with actions and updates for old ones. When we dedicated ourselves to looking for flaws, we found them. And that made fixing them possible.
For the teams that are toiling away this weekend, foregoing turkey for Peking duck and family for the factory floor — remember that finding issues with part quality, process, design, and workmanship is progress. Once found, they can be solved. A long issues list is encouraging. It means that your team and the process you’ve setup is actually catching what is bad. It means that the product you are building is meaningful enough that it couldn’t be done perfectly in the first try — no matter how experienced your engineers are. And most importantly, it means you have a list of exactly what is standing between you and getting your product to your customers.
And while I’d love to tell you how I saved Christmas by solving a software problem with a sticker five days before mass production, that is just the bravado in front of what really matters: that we had a process that found the issue (just barely) early enough that we were able to do something about it.
Thank you from everyone at Instrumental for building something meaningful enough to be hard. Help spread the gratitude by sending this to an engineer who needs a little encouragement this holiday.