This week on the Being an Engineer Podcast, we highlight the episode with Mustafa Poonawala, CEO at DynaMill Research. Mustafa has spent 30+ years operating at the intersection of medtech R&D, program management, and clinical operations - most recently including portfolio-level predictability work at BD Becton Dickinson, where he tracked the leading indicators that actually tell you whether a program is on track before the schedule slips. What makes this conversation worth reading is that Mustafa thinks about engineering speed not as an output of individual effort, but as a property of how decisions flow through an organization.
It's not that organizations move slowly because people are moving slowly. It's because decisions are not flowing through the organization at the speed at which they should.
In this episode:
Why schedule and budget are lagging indicators and what the leading indicators (decision quality, decision stickiness, interface stability, risk surfacing) actually tell you about whether a program is on track
How to think about early R&D value as preserved optionality rather than a fixed target and why business cases written at feasibility rarely survive to launch unchanged
What DynaMill Research built and why: AI-enabled clinical execution that compresses database close and CSR writing from weeks/months → hours/days
Why decision latency - not individual effort - is the primary bottleneck in most engineering organizations, and what to do about it
What "elevating engineering" rather than abandoning it means for engineers moving into leadership roles
Bonus Content:
Engineering Systems Don't Break, They Drift
S7E15 Mustafa Poonawala | Diagnostic Clinical Trials, Prioritization, & Decision Latency in Engineering
Mustafa Poonawala is CEO of DynaMill Research, where he's applying AI and digital infrastructure to compress the time and cost of clinical trials for medtech and diagnostic companies. In this episode, he reflects on 30+ years leading programs across R&D, program management, and clinical operations and what he's learned about why engineering organizations struggle to move fast. He covers what leading indicators actually reveal about program health before the schedule slips (decision quality, decision stickiness, interface stability, and risk surfacing), how to think about early R&D value as preserved optionality rather than a linear path to a fixed outcome, what DynaMill built and why - an AI-enabled clinical execution platform that compresses database standup through CSR writing from weeks to hours - and why decision latency, not individual slowness, is the primary bottleneck in most engineering organizations. For engineering managers and R&D leaders working in regulated product development, this episode delivers a framework for thinking about program health and organizational speed that standard program management approaches almost never surface.
>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.
Decision Latency Is Why Programs Run Late. Not the People Running Them
When Aaron asked Mustafa what single technique most accelerates engineering speed, his answer wasn't about tools, methodology, or individual output. It was about where decisions get stuck.
It's not that organizations move slowly because people are moving slowly. It's because decisions are not flowing through the organization at the speed at which they should.
Mustafa listed several root causes - unclear communication channels, insufficient empowerment, ambiguous decision rights - but his point was that the specific cause almost doesn't matter. The priority is identifying and reducing decision latency itself, regardless of what's generating it.
There can be a variety of different causes, but irrespective of why that's happening, trying to drive decision speed and ensuring to reduce the decision latency is key to building speed in an organization.
This connects directly to the leading indicator framework he described from his time at BD. Mustafa tracked not just whether decisions were being made, but whether they were holding - what he called decision stickiness.
The rate at which we make decisions, the rate at which we revisit decisions, decision stickiness - the stability and maturity of interfaces and the handoffs between subsystems.
Decision latency is one of the most counterintuitive bottlenecks in engineering programs because it's invisible in the standard schedule. It doesn't show up directly - it surfaces as downstream delays, rework, and escalation that everyone assumes were caused by something else. Mustafa's framework gives you the right place to look first.
ENGINEERING SYSTEMS DON'T BREAK, THEY DRIFT
On seven separate flights before the Challenger disaster, NASA engineers documented anomalous O-ring erosion and treated each safe return as evidence the system was sound. Rasmussen's 1997 drift-into-failure framework explains the mechanism — and why most engineering safety monitoring is structurally blind to it. If your program is tracking pass/fail events but not margin trends, you're measuring the wrong thing.
Read the full article on The Wave.
When Your Machine Shop Says No
Last year, a customer couldn't find a shop willing to make their part. Difficult material, tight tolerances, small quantity.
We tested our internal supply chain. Made the parts ourselves. Sent them as a surprise.
They worked perfectly. That customer has ordered hundreds more since.
Now available: custom machined parts with Pipeline engineering oversight, pricing that outperforms domestic shops, and the same supply chain we trust for our own work.
Want to learn more? Contact us at the link below: