In this week's newsletter, Aaron Moncur has a conversation with Samuel Feller, mechanical engineer and founder of awkwardEngineer.com, who has worked across structural, aerospace, medical, and consumer product development before transitioning into product management and consulting.
What do I get? When do I get it? You can answer all those questions in about two tweets - 280 characters is enough to provide all that information."
In this episode:
How asking "What do I get? When do I get it?" eliminates status meeting chaos and focuses teams on deliverables instead of process details
Why learning CAD tools deeply teaches systems architecture and interface design that engineering classes never cover
How talking to machinists about stock sizes and fixturing reduces costs more than negotiating quotes ever could
Why Kickstarter success depends on audience building before launch, not product quality alone and why ongoing distribution is harder than the campaign
Bonus Content:
The Birth of Modern Project Management: The Polaris Program and the inception of PERT
Samuel Feller | Product & Project management, Kickstarter, & DIY Product Launch
Samuel Feller spent three years being unbillable 85% of the time at a consulting firm - a period that pushed him to bootstrap products, learn manufacturing from scratch, and eventually build a philosophy that cuts through project chaos. His approach strips status meetings down to two questions that can be answered in 280 characters, treats tool mastery as essential as first principles, and recognizes that making products is rarely the problem, distribution is. From pressure vessels fizzing watermelon to voltmeter clocks on Kickstarter, Feller learned that talking to machinists about their stock suppliers matters more than arguing over quotes, and that the real education happens when you understand how the people actually doing the work think about your designs.
>If YouTube isn’t your thing, check out this episode and all of our past episodes on Apple, Spotify, and all the rest.
Stop. Before you automate that manual process step-by-step, read this.
In the 1890s, inventors tried to ease the transition from horses to automobiles by building "horseless carriages" - mechanical contraptions with articulated metal legs, rein-based steering, and fake horse heads housing lamps. They were solving the wrong problem. The answer wasn't replicating a horse. It was rethinking transportation entirely.
Modern automation projects make the same mistake. Your manual process evolved around human capabilities. Operators compensate for variation, use visual judgment, make micro-adjustments. Automating these workarounds directly creates complex, unreliable systems.
Pipeline Design & Engineering’s focus? Solving for the optimal outcome. Clear, reliable, effective.
Don't automate the workaround. Solve the actual problem.
Evaluating automation? Pipeline has solved this puzzle 100+ times.
Status Systems That Scale: Why "What Are We Doing?" Misses the Point
Most status meetings devolve into engineers explaining their process while managers try to figure out if the project is on track. Feller encountered this problem at scale and learned to ask different questions.
One person said something to me, like, Sam, you're running around talking to all these engineers, and you're really cross disciplinary, and you're talking to them face to face, which is great, but it doesn't scale. You need to build a system so that information flows to you.
The insight came from combining two pieces of advice: build a system for information flow, and focus only on what matters. The result was a framework that eliminates the noise.
I just want people to distill the information down. I just want to know, like, what do I get, and when do I get it? And I think a lot of engineers, and managers for that matter, because there are a lot of poorly run projects out there have never been trained to think or communicate important pieces of information in that fashion.
The difference becomes clear when you compare it to the traditional "what are you doing?" approach. That question invites detail about process, which changes constantly and obscures the actual outcome.
If you say what are you doing? Well, I'm spreading the peanut butter on the bread. Okay, like that's according to plan. But the thing that I care about is, am I going to have a peanut butter and jelly sandwich ready for snack time when the kids come home from school.
The peanut butter jar can shatter on the floor, requiring cleanup and a grocery store trip. "What are you doing?" now gets an answer about cleaning and shopping, not sandwich assembly. But the sandwich deadline hasn't changed and that's what actually matters for planning.
What do I get? When do I get it? And you can answer all those questions in about two tweets, like 280 characters is enough to provide all that information.
The Birth of Modern Project Management: The Polaris Program and the inception of PERT
In October 1957, the Soviet Union launched Sputnik into orbit, triggering an immediate reassessment of U.S. strategic capabilities. The U.S. Navy was already developing a submarine-launched ballistic missile, but Sputnik transformed the effort from a long-term program into a national priority. Leadership pressed for an operational system to be ready around 1960 - years earlier than many earlier planning assumptions. The responsibility for delivering that capability fell to the Navy’s Special Projects Office, led by Rear Admiral William F. “Red” Raborn. What the office faced was not merely a coordination challenge, but a fundamental technology gap. No solid-fuel missile had ever been launched underwater from a moving platform while carrying a nuclear warhead. Reliable guidance systems for such a missile did not yet exist. Submarine inertial navigation was still undeveloped. Lightweight thermonuclear warheads suitable for submarine launch had yet to be fielded. Each of these technologies had to be invented, matured, and integrated, simultaneously, into a single, operational weapons system in less than three years.
To read the full article, visit the full article on The Wave.
This Month’s Webinar Features: “Practical Project Management for Engineering Teams”
Mike Landis, Director of Engineering at Pipeline Design & Engineering, will share the actual project management framework Pipeline uses every day to manage dozens of concurrent engineering development projects, where budgets are significant, schedules matter, and scope creep can quickly derail outcomes.
A central focus of this webinar is a project budget and schedule tracking tool that Pipeline has refined (the Pipeline “Traveler”), iterated, and improved over literally decades of real-world use by multiple engineers across multiple companies. This is not a template pulled from a book or software tool - it is a battle-tested spreadsheet built specifically for the realities of engineering development work.
Used properly, this tool helps teams:
Proactively identify budget and schedule risk early, before problems become expensive
Detect scope creep as it happens, not after the damage is done
Make informed decisions sooner, allowing teams to pivot or course-correct
Maintain visibility into labor, material costs, and overall project health
For teams managing expensive engineering projects, the ability to surface issues early can easily save tens or hundreds of thousands of dollars. And in this session, Pipeline is simply giving this tool away.
Every attendee will receive a FREE copy of Pipeline’s Traveler spreadsheet, along with the context needed to understand how - and why - it works. Register at the link below. Space is limited!