Being an Engineer
Being an Engineer
S7E15 Mustafa Poonawala | Diagnostic Clinical Trials, Prioritization, & Decision Latency in Engineering
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Mustafa Poonawala is a globally recognized leader in medical device and diagnostics innovation, known for his ability to translate strategy into execution across R&D, clinical operations, and portfolio management. Over a career spanning more than two decades, he has built and led world-class engineering and program teams, guided products from early development through regulatory approval, and driven large-scale organizational transformation in highly regulated environments.
Currently, Mustafa is the CEO of DynaMill Research, a specialized Clinical Research Organization focused on helping diagnostics companies dramatically reduce cycle times and improve cost predictability. DynaMill’s approach blends agile program management, end-to-end digital clinical workflows, predictive enrollment strategies, and deep partnerships with multi-site clinical networks. The goal is simple but ambitious: help diagnostic innovations reach patients faster without sacrificing rigor or quality.
In parallel, Mustafa is Managing Partner at Steps Program Management, where he has spent nearly a decade advising organizations on agile transformation, PMO maturity, and portfolio optimization—particularly within medical device R&D. His work emphasizes lean, value-driven processes, difficult prioritization, and delivery predictability, all grounded in real-world execution rather than theory.
Previously, Mustafa held senior leadership roles at BD, Hospira, OBS Medical, and Boston Scientific. His experience spans implantable and disposable devices, complex electromechanical systems, software and cybersecurity for safety-critical systems, and large-scale diagnostics portfolios exceeding billions of dollars in revenue. With a PhD in Software Engineering focused on safety-critical systems, Mustafa brings a rare blend of deep technical rigor, business acumen, and servant leadership to every challenge he tackles.
LINKS:
Guest LinkedIn: https://www.linkedin.com/in/mustafap
Guest website: https://dynamillcro.com
Aaron Moncur, host
Subscribe to the show to get notified so you don't miss new episodes every Friday.
The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment like cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us at www.teampipeline.us
Watch the show on YouTube: www.youtube.com/@TeamPipelineus
I've always been fascinated by how complex systems behave and come together, right? And it's not so much how they're built, but what fascinated me, and then also what motivated me into my doctoral studies, was how they can fail and how we can make them resilient.
Aaron Moncur:Hello and welcome to the being an engineer podcast. Today's guest is Mustafa Poonawala, a seasoned engineering and business leader who has spent decades operating at the intersection of medical device R and D, diagnostics, clinical research and organizational transformation. Mustafa has led global teams, launched complex, regulated products, built high performing pMOS, and now serves as CEO of DynaMill Research, where he's focused on accelerating diagnostic innovation through agile, digitally enabled clinical trials. Mustafa, thank you so much for being with us today.
Mustafa Poonawala:Thank you, Aaron. I'm glad to be here.
Aaron Moncur:All right, we're going to go through a couple rapid fire questions, just so everyone can get to know you quickly, right at the beginning here, no need to spend a lot of time thinking about the answer. Just quickly respond with with which whatever comes to mind here, right? So here we go. The first one. What historical engineering failure do you find most fascinating?
Mustafa Poonawala:I would say the O rings on the owl.
Aaron Moncur:Yeah, yep, classic. Okay, great. Next one, meetings essential, or productivity killer,
Mustafa Poonawala:Essential, if done right,
Aaron Moncur:Good answer is technical debt ever acceptable?
Mustafa Poonawala:Yes,
Aaron Moncur:All right. And last, when we get into the details, okay, perfect. And last one, one technology that you think is overhyped?
Mustafa Poonawala:I would say miniaturization, miniaturization.
Aaron Moncur:Okay, great. All right. Well, thank you, Mustafa for going through through those with me. So now the question that that I always start with, What made you decide to become an engineer?
Mustafa Poonawala:Great question, right? And I think as I look back to my career, I've always been fascinated by how complex systems behave and come together, right? And it's not so much how they're built, but what fascinated me, and then also what motivated me into my doctoral studies, was how they can fail and how we can make them resilient, and especially when it comes to safety, critical systems, medical devices, nuclear power plants, etc, anything that can cause harm to an individual or to a society, that our ability to ensure that We make them feel safe, to make them resilient, is what fascinated me, and engineering gave me a language, right, if I may say so, by which we can understand these systems and make them better in how they're used and how they're accepted.
Aaron Moncur:I love that you call it a language, because it really is a different language, right, that engineers speak, and it's the way that we communicate ideas with that language. So you are, and have been, for some time, a leader, especially in the medical technology space. What aspect of your your background, your history, your experience, do you think most greatly affected your leadership style today? Was it? I mean, you've been in r, d, you've been in clinical operations, you've managed portfolios. What was it about your background? Do you think that has most significantly shaped your leadership style?
Mustafa Poonawala:Yeah, you know, look, very early in my career, I realized that good R and D requires very prudent and topical program management in order to move it from good to great. And so the intersection of RMB and program management as a craft to bring systems to market was an essential element. And then as I matured in my role, I also realized that it's engineering is not just about building a system, writing code or hardware, et cetera. It's about understanding the constraints and trade offs and how we especially when it comes to medical devices and medical products, how we can understand the clinical efficacy of these products in order to make them of true value, so that these three intersection points right developing R and D, from an engineering perspective, program management to ensure that it's developed right and timely, and then clinical execution to ensure that it makes a difference, is what comes together. And you know, understanding the intersection of those three has has really proved to be a turning point in my career.
Aaron Moncur:And the clinical outcomes are ultimately what what most greatly affects the business outcomes, right? If you have good clinical outcomes, then you have a successful product on your hands. And if you don't, then, well, it's back to the drawing board. It can be difficult for individual contributors, especially engineers, who are mired in the day to day details of engineering, to extrapolate what they're doing out to the business outcomes, right? Those portfolio level outcomes? How? What are some ways that you have helped the engineering individual contributors think a little bit more holistically to understand, like the business impacts, those portfolio level impacts of the work that they do.
Mustafa Poonawala:Yeah, you know, and look, don't want to, don't want it to sound cliched, but really understanding how what we are developing is going to ultimately affect the people that use it and the people that will make use of it is critical, right? You know, we have to put ourselves in the shoes of the patients of the healthcare providers. I'm going to lean on medical devices, right? Because that's been my focal area for the last 30 plus years. Is, is what it is, what matters, right? You know, I've seen many, many times a beauty, a beautifully designed system, fall apart because it's not able to meet the demands of either the people that use it or the people that would ultimately have benefited from it. So that that aspect right in, we've called it Clinical Center. We've called it patient simplicity, you know, human factors, etc, many different terms. That is ultimately what we have to keep in mind from the get go in designing and developing a system,
Aaron Moncur:Yeah, yeah. Are we developing the right thing? Not only does the thing work, but is it the right thing?
Mustafa Poonawala:Yes, it's not so much, you know. Are we developing the right thing, and then are we developing the thing right? Right? As a classic you know, agile practitioner would say, yeah.
Aaron Moncur:Okay, so you, one of the places at which you worked was BD Becton Dickinson, large global medical device company, and you were responsible for for predictability across a fairly large diagnostics portfolio. What were some of the leading indicators that you watched to know whether a program was on track or not, If your company helps engineers design, build or manufacture better products, we should talk at PDX, the product development Expo. Companies don't just exhibit. They teach practical training right at their booth. Engineers walk away with new skills, and companies build real relationships with the people who use their tools and services. The result is high quality connections built through real technical value. Pdx 2026 is October 20 and 21st in Phoenix and booth selection is first come first served. Many are already reserved to learn more about exhibiting. Email us at PDX, at Team pipeline.us,
Mustafa Poonawala:Yeah, you know, when we talk about predictability, many times we we talk about it in the from the perspective of schedules and budgets, right? Is a program on time and is a program on budget? Now, those are important factors, right? But they are lagging indicators when we want to think about leading indicators, as you asked, we need to think about our day to day aspects, the little things that we do every day that may be impacting the schedule, the budget, ultimate value, etc, of the product. These little things are things like decision quality. Right, the rate at which we make decisions, the rate at which we revisit decisions, decision stickiness as a means the stability and the maturity of interfaces and the handoffs between subsystems, between software and hardware, etc, and our ability to keep track of that, the focus on risk, and our ability to either accept risk and then develop mitigation plans around those, those risks, ensuring that risks are being surfaced early in a Development Program, not just hidden, right? It's not about risk avoidance. It's about ensuring that we're bringing to bringing forth risks and then doing something about, yeah, so keeping track of all of these elements on a regular basis and then acting on them, or is what is what leads to projects being on time, on budget and of value and
Aaron Moncur:quality from a really tactical standpoint, how have you kept track of some of those things? Have they been very sophisticated software applications that allow you to do so? Or is it an Excel spreadsheet where you just, you know, make a few notes each week?
Mustafa Poonawala:Yeah, look, you know, we don't have to get complex and esoteric in order to be effective, right? You know, one of my very early mentors told me that simplicity is the most complex thing in the medical space or in in the safety device space, and so it's using tools that are topical for the for the company, for the situation at hand, right? Whether it's Excel spreadsheets, whether it's, you know, our own home build trackers, it's also utilizing our, you know, in the current day and age, things like AI and, you know, and custom built data models to help keep track of those things, you know, in a lean manner.
Aaron Moncur:Yeah, yeah, touching on R and D again, you brought that up just a minute ago, oftentimes, the outcomes of R and D, whether those efforts were successful or not commercially, it might be years before you really know. Is there anything that you've done early on, you know, during during the R and D to assess whether the efforts being completed are really valuable, or, you know, at the end of the day, they're really not going to go anywhere,
Mustafa Poonawala:yeah, you know, I would like to think of value as optionality with the with intent, right? And what I mean by that is, you know, early R and D creates value when it is preserving our future choices. Right? Everything that we're doing early in a development cycle is going to eventually lead to a potential outcome. And whether it's technical aspects, whether it's clinical aspects, regulatory aspects, etc, we're reducing uncertainty every step that we take. We're mitigating risk. We're making decisions that are eventually narrowing down the optionality that we have in order to deliver the value that we're creating. Right? And that's what, that's what we would measure value from for a product, and maybe five years away, right? You know, look, I've never, I've yet, I've yet to see a business case that has stayed stagnant for five years from the time it was written, right when a product exits feasibility, to the time it's launches. That business case may have eroded multiple multiple times, but the product is still launched, because there is still value in in that product being delivered. Now, the other thing is, it's a little bit more nebulous, but from a from a personal perspective, I see value in the fact that if you're learning something by doing that's that's powerful, right? And that learning helps us do things better the next time we do them. Learning from our failures, learning from our successes, irrespective of whether we fail or succeed, it's irrelevant. It's what we've learned from from our doings.
Aaron Moncur:I really liked the way that you think about that. I don't think I've ever thought about R and D value in such a way. What you're saying is that the value, or one way to value R and D is its its ability to give you options in the future. That's a very profound way to think about. About R and D efforts,
Mustafa Poonawala:Yes, you know, trying to drive to one particular outcome, maybe trying to, you know, reach hit a hit a target that's a mile away with an inch of deviation from the time you start aiming at it, right, you're going to end up a mile away. But So rather than thinking of it in that terms, it's thinking of what optionality are we creating as part of our R and D efforts? Yeah, that's great.
Aaron Moncur:Very insightful. At Dynamill, you are the CEO. Did you start the company? Also?
Mustafa Poonawala:Yes
Aaron Moncur:Okay, great. Tell us a little bit about what what Dynamill Research is and what your focus is there?
Mustafa Poonawala:Yeah. So you know, over the over the course of the covid pandemic, I realized that there was a lot to be desired when it came to clinical execution for the med tech and diagnostic space, right? What we've, what we've, what we what we had been seeing with the with the clinical partners that we've been using, that we were using, were methods, techniques, tools that were not topical for this need of diagnostics and medtech, right? Most of the large portion of the CROs that we see cater to pharmaceutical clients and pharma products are very different from medtech and diagnostic products, the life cycles are much longer. The pockets may be much deeper. The the timelines are are much more forgiving. Many times, when it comes to class one, class two, class three, or phase one, phase two, phase three, clinical studies, etc, when it comes to med tech and diagnostics, the type of clinical execution, the type of clinical evidence, is very different. It focuses on safety and efficacy. It focuses on Cycle Time reductions. The cost structures are much more different, and that led to, you know, thinking about, there's got to be a better way to cater to this need. Right? The need for clinical evidence is not going to go away, and so it's a matter of figuring out, how do we get clinical evidence in a much more faster, much more effective man now that intersecting with the advances in AI and the advances in tooling development led to the formation of nine, right? So what we what we aim to provide, is lean clinical execution for for medtech and diagnostics utilizing a fully integrated and digital infrastructure, right from the from the start of a clinical trial execution to the time a CSR is written, we have a set of interconnected tools that have common API's and that can speak to one another. We use leading AI techniques to help reduce the timelines, the cost structure and the fatigue that goes with clinical execution, right? Things like predictive site enrollment, where we can track, you know, patient status, subject enrollment status, and then stand sites up and down as necessary. Um, where we can use natural language processing for reporting that that sponsors can utilize right giving them a level of transparency that they have not been used to with with traditional clinical execution. So this helps remove the manual aspects and the labor intensive aspects from the clinical execution lifecycle. So when we talk about, let's say, database stand up, or database close out, writing a CSR, you know, things that used to take weeks if not months, can now take hours if not days, right? And that's the transformative cycle time change, which then translates to costs and value that we can pass on to our sponsors.
Aaron Moncur:I know exactly what you're saying. We have a product that we developed recently here at my company, and we recently filed a patent on it. And for anyone who's ever gone through that patent process working with a patent attorney, IP law firm, it's kind of painful communicating all of the. Information that you have in your team to the the patent attorney so that they can write a comprehensive and accurate patent for you or application for you. And I was the one responsible for communicating directly with this, this firm that we worked with, and you know, they asked a lot of detailed questions help us understand and define the technical aspects of this product. And luckily, we had a chat GPT project that we'd created for this product, and we had fed the AI all of this knowledge about the product pretty comprehensively. So chatgpt, this project, knew our product very well, including all the technical details. And so I would literally take the questions from the IP attorney, put it into this chat GPT project, and say, you know, give me the answer that I can send an IP attorney, and format it and word it in such a way that it's useful for them. And it would just, you know, give me answer and answer and answer. And it was incredible to me. I mean, it would have taken me days, for sure, if I were to manually write out the answers for all these questions and and they would have been, you know, okay, probably, but using the AI, it took me a couple of hours if that and the answers were were better than what I would have come up with manually, so I understand what you're saying about, you Know, feeding the database and then using the AI to query the database and get relevant answers out of it. It's so powerful,
Mustafa Poonawala:yeah, yeah. And look, you know, there isn't, there is an aspect of data privacy, data integrity, etc. And so we actually develop sponsor specific language models that can maintain data privacy, data integrity for particular sponsors within their firewalls, etc. So we're learning from how things are done topically, from the intricacies of every particular company, etc, and building that into into the smarts that this this tool can then provide, yeah, but the technology is there. The technology is there at our fingertips. We just need to be able to use
Aaron Moncur:it, yeah, for, for teams out there who are listening to this and they're working on, you know, some kind of diagnostic clinical trial themselves. What? Where? Where do some of these companies lose time in these trials without even realizing it. What's a pro tip that you can share with them to save some of that time?
Mustafa Poonawala:Yeah, you know, look design, whether it's engineering design, whether it's clinical design, et cetera, the anticipated friction. Keep that in mind as you're creating the designs, right? So for example, clinical execution, for example, it's not, it's not downstream aspect, right? It's a design input. And think of it in that manner. So think of how can protocols be designed for success, what needs to hold true for as we're collecting the data, et cetera, and having that optionality again, having thought through that optionality, will lead to much, much more robust and smart trials, smart designs, whether we're talking about engineering execution or whether we're talking about clinical execution?
Aaron Moncur:Yeah, you you reference GEMBA and lean thinking regularly. How can engineers apply some of those principles in their day to day roles, even if they don't have formal responsibility? And do you have any any examples or stories that you can share where you know your team or a team that you were working with were able to apply these principles effectively.
Mustafa Poonawala:Yeah, look, Myanmar, at its heart is simple, right? Go see the work where it's happening. And you know, we don't need authority to observe in most cases, right? It's it's observing how things are being used, how evidence is being collected, where the pain points are, etc. And that leads to true invention, right? Without being at without being where the product is being used, where the product is being designed. Engineering falls apart, right? If you're trying to do it from a cubicle. Now, there is value to coming back and bringing it all together, but the real work happens where, where clinical input meets, how patients are using the product, how it's being used on patients, etc. Yeah, right.
Aaron Moncur:I've worked with a lot of engineers who are really good problem solvers. However, they. Struggle prioritizing their their work, their efforts. You know, they'll, they'll go down a rabbit hole probably 10 times further than than they should have in order to solve a problem, because they are good problem solvers, and they're very good at solving technical problems, but there probably wasn't, you know, business justification for spending that much time trying to solve that particular problem. Have you come up with any any pro tips or tricks or, you know, if you're working with technical leaders or their teams, how do you coach them to understand when good enough is good enough and and understand how to prioritize different different problems that they're trying to solve. Pipeline now offers procurement of custom machined parts at significantly lower costs without sacrificing speed or quality. We design and build custom machines ourselves, so we consume a lot of precision machined components. Over the past several years, we developed a proven overseas supply chain to support that work, and in 2025 we successfully piloted that capability with select customers. Now we're opening it up more broadly. If you'd like to see how our prices and lead times compare, send us a drawing or two for quote, visit team pipeline.us. Or message me directly on LinkedIn.
Mustafa Poonawala:Yeah. You know, look, there is no there's no science right in a way, to prioritization. It does become an art. Now, you know different types of prioritization require different approaches. Right? When we're talking about prioritizing a portfolio, it's a different approach. There can be a different set of analytics that can be used to drive positions, etc, when it comes to prioritizing work, it's ensuring that we do not forget that our jobs as an engineer is not to solve everything, it is to solve the right things and then choosing what is it that we're not doing in order to stay focused on what needs to be done. So there is an opportunity cost to spending too much time on perfecting something and understanding that trade off becomes a critical inflection point right to do the work that needs to be done and the focus that needs to be applied. Now, the way I would recommend people practice it is to constantly ask ourselves, and I at the point of diminishing returns, if I continue to proceed, and if, if we feel that's the case, then it's we've got to pause and rethink.
Aaron Moncur:I love the way you put that diminishing returns. I hope everyone heard that answer. I think that's a really great answer. Are there? Am I at the point of diminishing returns? And there is an opportunity cost to spending time perfecting a problem, a design process, whatever it is, right? Oftentimes, we don't need a perfect design and and even requirements don't dictate a perfect design, they just dictate what's good enough. And that can be a tough pill for an engineer to swallow, right? Because we love making things perfect, but, but from the business aspect that's really making things perfect is, is, is probably a good way to go out of business. It probably sounds silly to say it that way, but you just, like you said, there is a very significant opportunity cost. What are you not able to do that you should be because you're spending too much time on this one particular problem? Okay? Well, Mustafa, if you had magically 20 hours, an extra 20 hours per week that you could do whatever you wanted with and it's not going to negatively influence, you know, any of your other responsibilities. What would you do at that time?
Mustafa Poonawala:Yeah, you know, I would. I would choose to mentor and grow people with the time that I had, right? You know, I wouldn't say it's, it's mentoring, for the sake of, you know, addressing a particular question that that someone. Have, but it's mentoring from the perspective of multiplying value, right? If I can share my experiences, if I can motivate people to do things differently, to maybe start their own company, to try things out, right, not worry about failures, etc, that starts multiplying the value that we bring to the industry as a whole. And that's what mentorship for me is all about. It's it's about sharing my experiences, sharing the what I've learned from my failures, and then motivating people to be brave and take the next step into the unknown.
Aaron Moncur:I love that, and I agree so strongly with that. It is at the core of so many things that we're doing here at my company, pipeline, we've got this podcast. This is a perfect example, right? We speak with high performing engineers, leaders in the industry like you, tease out some best practices, some insights, and share it with the whole community, so that we can all learn and grow from it. Same thing with the wave dot engineering online community for engineers. We've got our in person PDX product development Expo that we do, we've got these webinars, we've got in person meetup, hardware meetups here locally, and they're all focused on helping engineers learn faster so they can impact not just our industry but but really our society more more successfully. So I love that, that you want to give back in that way, mentoring other engineers. Next question here, What? What is something that you've always wanted to do, but for whatever reason you haven't, doesn't need to be technical or job related. We're just we're getting to know Mustafa now,
Mustafa Poonawala:yeah, you know, I laugh because I think about this so often, right? Is that we've lost in in this electronic age where our keyboards are closer to us than our pens, I think we've lost our ability to write properly, and that's what I would love to do right is, is is right, and use that to express my thoughts, to jot down my ideas, etc. I've reflected back on, you know, when I use, you know, our use on your favorite AI prompt, right? And I, and I use that for it to write something for me. And I think back about, how would I have written? What I get back that that that thought process leads to so much learning from from my perspective, and, and that's something that I would like to do a lot more of, right? Is, is just right? Just the old fashioned way?
Aaron Moncur:Yeah, I think that's so powerful. I listened to this program a long time ago by this gentleman named Earl Nightingale. He was, he's passed away now, but I don't know, 10s of years ago he was in the personal development space, one of the early personal development gurus out there. And he has this program called Lead the Field, and it's so great. And one of the things he talks about when it comes to brainstorming and innovation, is sitting down in a quiet room with a pen and paper, or a pencil and paper, and just writing out 20 ideas, see if you can get to 20 ideas. Here's the problem, here's my objective, what I'm trying to accomplish, and just write out brainstorm 20 ideas that you think might solve that problem, and probably a lot of them are going to be bad ideas, but that's okay. The point is more volume than quality at this point, and then once you get down to 20 there are probably a couple of ideas in there that are pretty good. And there is something about writing with with pencil and paper, or pen and paper, that I don't know. It somehow triggers the brain to think differently. And you do you come up with with different ideas and better ideas. So anyway, the power of writing, I think it's, it's very real. Yeah, it does.
Mustafa Poonawala:It does, right? I personally felt it right when I start writing with a pen and paper or with my even with, even with an Electronic Writing Pad, yeah, right, but just writing is what makes me think about different things, make new connections, etc, that I would not have just thought about if I was just sitting and thinking or typing, yeah, on a key.
Aaron Moncur:Yeah. There's something about the motion of the hand and the focus something in there just triggers the brain to think differently. Okay, if you're comfortable, would Is there a life defining experience or moment that you've had and how it impacted you? If you're comfortable sharing that?
Mustafa Poonawala:Yeah. Yeah, you know, look, I won't get into the details, but I will say that I've had the honor of having the products that I've developed being used on my personal families, while members right across throughout my career, whether it's cardiac devices, whether it's injectables, diagnostic products, etc. And that taught me that at the end of what we do, our patients are people that rely on what we do. Yeah, and it's and that makes it so that makes it so real, right? It's it makes it, gives it a different meaning, and it it also helps me stay humble, right? That at the end of the day, it's these products are being used to make people's lives better, and not just in a cliche manner, right? It truly it's when it's when it hits you, personally, is when the realization happens, and that's that stayed with me all throughout my career.
Aaron Moncur:Yeah, that's beautiful. Thank you for sharing that engineering, I think, is such a noble profession, okay? Just a couple more questions here, and then we'll we'll wrap things up for this interview. What advice would you give to earlier or mid career engineer who wants to move into a more like leadership role, but but also doesn't want to lose their engineering identity,
Mustafa Poonawala:yeah, you know, think about elevating engineering, not abandoning it, when you move from an individual contributor to a team builder, right? And what I mean by that is, you know, as we move into leadership positions, as we move into mentoring people, etc, we are helping people solve problems faster and better, and that is how I personally stay connected with my engineering roots, right? Look, I don't write code anymore, right? But when I when I can sit down with my software team or my team and say, this is, let's, let's, let's brainstorm the solution to this, and I can constructively challenge them and we come up with a better solution, that's how I stay connected, and that's what I call elevating engineering, as opposed to abandoning, abandoning it right? The influence that we bring from the experience that we've gathered can go a long way, right? And that's, that's, that's what I would recommend, how engineers stay connected to engineering throughout their careers.
Aaron Moncur:Yeah, that's a great piece of advice. When you're mentoring your engineering teams like that. You know providing guidance that that in itself, is a fantastic way to accelerate the speed of engineering, right? Because you're you're no longer one on one, you're not the one writing all the code as an individual contributor. You're helping a team of people write code more quickly. Are there any any other examples that come to mind of a technique or a strategy or behavior that you feel has been very impactful in accelerating the speed of engineering?
Mustafa Poonawala:You know the one, I would say, the one major aspect is to help reduce decision latency, right? Look, I've seen that it's not that organizations move slowly because people are moving slowly. It's because decisions are not flowing through the organization and the speed at which they should that could be because the communication channels are lacking. It could be because the empowerment is lacking, the decision rights are not clear. There can be a variety of different causes, but irrespective of the irrespective of why that's happening, trying to drive decision speed and ensuring to and reducing the decision latency is key to building speed in an organization. That's great.
Aaron Moncur:Yeah, I love that. Thank you. All right, Mustafa, I think that brings us to the end of this episode of The being an engineer podcast. Thank you again, so much for sharing your valuable time with us and being on the show. How can people get in touch with you?
Mustafa Poonawala:Yeah, look, my cell phone is is the best. Great. And Aaron, if you don't have it, I can share it with you. Do you want me to stay say it aloud, or should I just shoot you a note,
Aaron Moncur:whatever you're comfortable with. You can say it if you'd like, or if you prefer, I can, you know, hold it privately, and people can reach out to me whatever you're comfortable with. We can put in the show notes, whatever you want. Yeah, I'll
Mustafa Poonawala:say it aloud. My cell phone and LinkedIn are the two best ways to get in touch with me. My cell phone is 651-343-5591, so shoot me a message and in, you know that's that's a quick enough way to get in touch with me, if not shoot me a message on LinkedIn.
Aaron Moncur:That's very generous of you. Mustafa, thank you so much. Again, is there anything else that we haven't talked about that you think we should before we sign off today?
Mustafa Poonawala:No, I think we covered a lot. Thank you, Aaron, for the excellent facilitation. It gave me a lot of food for thought, I must say, even as I go back and reflect on some things that I've said and how I've used that on a day to day basis, and some of the examples that I can share for future generations.
Aaron Moncur:Terrific. Well, there are a lot of people listening to this right now. I am positive who are taking so much from it and learning and growing as a result of you being willing to share. So thank you again for giving back to the community of engineers.
Mustafa Poonawala:Thank you so much.
Aaron Moncur:I'm Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode to learn how your team can leverage our team's expertise developing advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R and D services. Visit us at Team pipeline.us. To join a vibrant community of engineers online. Visit the wave. Dot, engineer, thank you for listening. Being an engineer has more than 300 episodes, and you don't have to listen to them in order. If you're dealing with a specific challenge right now, there's a good chance we've already interviewed an engineer who's been through it, you can jump around, search by topic and listen to what's most relevant to you see you on the next episode, you.
