Before we get started, did you know about this?
PML has a free webinar coming up that distills over 2 decades of project management lessons into a single hour.
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!
In this week's newsletter, Aaron Moncur has a conversation with Lisa Ho, Project Manager at Menlo Innovations, and Andrew Muyanja, Senior High Tech Anthropologist at Menlo Innovations.
We want to really pump fear out of the room. If I was to say, Well, why are you going over your estimate? Why is this taking so long? What's going to happen the next time the developers scope or estimate there, they're not going to tell me.
In this episode:
How paired programming creates workforce flexibility without costing twice as much by spreading knowledge and reducing project failure risk
Why high tech anthropology prevents expensive late-stage failures like the $2M insurance system that was built, deployed for two years, then killed
How "making mistakes faster" and pumping fear out of the room leads to better outcomes than traditional accountability-based management
Why optimizing individual efficiency fails compared to systems thinking that treats the entire team as a unit
Bonus Content:
Product Safety Failures & Engineering Priorities from 2025 Data
S7E1 A Joyful Approach to Product Development | Lisa Ho & Andrew Muyanja (Menlo Innovations)
Most software projects suffer from towers of knowledge, fear-based management, and systems built by programmers for programmers rather than end users. Menlo Innovations takes a different approach: every team member pairs with a partner throughout the workday, mistakes are encouraged rather than punished, and high tech anthropologists study end users before a single line of code gets written. The result? Teams that work 40-hour weeks with no nights or weekends, projects that avoid the fate of expensive systems that get built only to be abandoned, and a culture where kindergarten skills like sharing and taking turns become legitimate competitive advantages. Lisa Ho and Andrew Muyanja walk through how their unconventional methods solve the problems that conventional software development creates.
>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.
Paired Programming: Why Two Developers Don't Cost Twice as Much
The most common objection to paired programming is immediate: if two developers work on the same task simultaneously, doesn't that mean projects cost twice as much? Menlo's experience over years of pairing suggests that question misframes the actual cost of software development.
It depends on how you're measuring, right? Imagine if I had a project, it has three components to it, this database guy who is the best in the world, there's a front end designer who is the best in the world, and then there is a front end engineer. The three of them working together all independently, they make the greatest product ever, but then one of them just doesn't show up for a month he gets COVID-19. Instead of even moving slowly, you can't really roll out the product because there's a key component that you cannot ship the product without.
Traditional efficiency metrics focus on individual output, but software projects fail when key team members leave, get sick, or win the lottery. The real cost isn't in the daily rate multiplied by hours, it's in the total time from project start to successful deployment, including all the delays, rework, and abandonments that happen when knowledge lives in one person's head.
We work with a company down in Tennessee who are applying high tech anthropology to process change. They have a huge business directive from their headquarters out in Asia, that you have to grow twice as much in the next three or four years. And you have to grow twice as much in profitability. They can't scale up their current processes, because then they're growing the cost. They have to be able to do more work, and increase their profitability with less people.
Workforce flexibility matters more than individual programmer productivity. When every team member can work on any project because knowledge spreads through pairing, project managers don't face the bottleneck of waiting for the one person who understands a particular system. Teams can shift resources based on actual priorities rather than being constrained by who happens to know what.
It costs more, but it's not twice as expensive. The solution that we get through pairing is a lot more robust and of higher quality. Your pair partner is there, noticing, Hey, you forgot about this edge case, or helping you think about the problem in a different way. A lot of the work that the programmers and designers are doing is problem solving—the programming is not just sitting at the computer clicking away at the keyboard, it's how are we going to tackle this problem? Having somebody else there to work on that problem with you, instead of spinning your wheels for a long time trying to figure it out, makes a huge difference.
The pairing premium gets paid upfront during development. The return comes from fewer bugs, faster problem-solving, built-in code review, and zero project delays when team members take vacation or leave the company. Projects ship on time because there's no single point of failure in the knowledge base.
Product Safety Failures & Engineering Priorities from 2025 Data
A September 2025 analysis revealed something alarming about consumer product engineering: recalls surged 40% over five years, with 312 recalls affecting 24 million products in just seven months. Fire and thermal hazards account for more than half of all failures. BowFlex recalled 3.8 million dumbbells that broke apart during use, causing 337 injuries. SharkNinja recalled 1.85 million pressure cookers that opened under pressure, leading to 50+ severe burns and 26 lawsuits. LG recalled 500,000 ranges that turned on by themselves, linked to 28 house fires. These weren't exotic edge cases - they were predictable failures that proper testing would have caught. A 2024 study found that 68% of mechanical failures resulted from conditions that passed static testing but failed under real-world dynamic loads. The article examines what these failure modes reveal about where engineering discipline breaks down under schedule pressure, and the specific validation changes that prevent products from joining next year's recall list.
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!