In this week's newsletter, Aaron Moncur has a conversation with Michael Hadley, Engineering Manager at Pipeline, whose 20-year detour through human development and business management fundamentally shaped his approach to engineering problem-solving.
We often stop when we think we're used up, or when we think we've got the right answer. We stop too soon. We all stop too soon.
In this episode:
How a 20-year detour through human development and business management shaped an unconventional engineering approach
Why designing an "impossible" bite block airway required reading 1940s injection molding textbooks
How Warren Starnes taught him that finding 50 right answers beats stopping at the first one
Why broad cross-discipline knowledge creates more value than deep specialization in one area
Bonus Content:
Taking Technical Expertise to the Next Level: Curiosity as a Superpower
S6E7 Michael Hadley | A Thirst for Learning: Becoming An Engineer 20 years After Graduating
Michael Hadley's path to engineering management went through an unexpected 20-year detour as a seminar leader and business manager for Tony Robbins. When he returned to engineering after two decades, he brought with him a philosophy that challenges how most engineers approach problems: don't stop at the first right answer. Whether it was designing a bite block airway that experts said couldn't be injection molded, or learning from a poetry professor who always asked "what else?", Hadley built a career on the idea that specialization limits value. His advice to engineers cuts against corporate culture: corporations encourage cube farms and narrow expertise, but the engineers who create the most value are those who keep expanding their knowledge across disciplines. The lesson isn't just about being a generalist, it's about recognizing that when you think you've found the answer, you've probably stopped too soon.
>If YouTube isn’t your thing, check out this episode and all of our past episodes on Apple, Spotify, and all the rest.
Quick! When your automation fails, what gets protected first? Humans, the machine, or the product?
Most teams design backwards. They optimize for product quality, then machine uptime, then (maybe) add safety guards.
Pipeline Design & Engineering's order of protection:
Humans first. Always.
Machine second.
Product last.
Why? No humans = can't run machine. No machine = can't make product. Your responsibility is handing operators a system they trust won't hurt them.
We follow ANSI B11.0 standards and conduct risk assessments before finalizing any design.
Designing safe automation systems? Pipeline Design & Engineering follows safety-first protocols on every project.
Finding 50 Right Answers: Why Engineers Stop Too Soon
Most engineers are taught that the goal is to get the right answer. But what if that mindset is fundamentally limiting?
We're taught in school to get the right answer right. That's the whole point of school for many of us. And the problem with that is it teaches us two things that are incorrect. One is that there is a right answer, and number two is that there is one right answer.
Hadley learned a different approach from Warren Starnes, who refused to accept a single solution to any problem.
He was never satisfied with the right answer. He wanted 10 right answers, or better, 50 right answers. And then choose, then he would choose the best of those right answers to move forward.
This philosophy originated from an unlikely source: a poetry writing course at Vanderbilt taught by a one-eyed poet with hair to his shoulders.
Poetry forces one to really condense an idea into just a few syllables, and to get it so that you convey the whole of it in just a few words rather than many paragraphs. It's a tremendous discipline. And one of the things he would almost always write on my poems when he turned them back to me was, 'This is interesting, Michael, but what else?
That question - "what else?" - became the foundation for how Hadley approaches engineering problems. When he designed a bite block airway that experts said couldn't be injection molded, he didn't stop at their assessment. When oil prices collapsed and killed a technically successful 72-foot solar dish project, the lesson wasn't about the engineering - it was about not anticipating market conditions fast enough. The pattern repeats: stopping too soon is the consistent failure mode.
You go to China, they treat customers like God. In fact, like I've walked up stairwells, and on the front face of the stair, it says customer is God. Big signs to say customer is God because you're bringing money, right? Money's God in Vietnam, nobody's God.
I think it's taking the easy way out to stop at the first right answer.
Taking Technical Expertise to the Next Level: Curiosity as a Superpower
Most engineering leaders focus on vision, decisiveness, and technical expertise. Satya Nadella took a different approach. When he became CEO of Microsoft, he shifted the company from a "know-it-all" culture to a "learn-it-all" culture and that distinction turned the company around. Research from Todd Kashdan and Carol Dweck shows curiosity produces measurable improvements in problem-solving and team performance, yet it rarely appears in leadership development discussions. Einstein once said he had no special talents beyond passionate curiosity. For engineers moving into leadership roles, this matters more than most training programs acknowledge. This article explores how curiosity manifests in engineering leadership - from asking better questions to seeking diverse perspectives to handling uncertainty differently - and why technical mastery alone leaves critical leadership capabilities underdeveloped.
Read the full article on The Wave.
Did you know that our team at The Wave and Pipeline Media Lab is building a database of high quality vendors across various disciplines? Have a company you really like working with? Are you a company looking to expand your reach?
Visit the vendor page on The Wave now and submit your company for review!