“Play small and play big” was one of CEO Geoff Martha’s mantras as he and his team reorganized Medtronic (NYSE:MDT), the biggest corporation in medtech.

The multi-year effort decentralized Medtronic’s three big groups — cardiology, neuroscience and medical surgical — into 20 narrowly focused operating units (OUs).

“The OUs can maintain focus and accountability, execute faster and make quicker decisions, while retaining the advantages of size and scale. … Play small and play big,” Martha said in an October 2020 communique.

Fast forward to today. Mike Hess, VP of corporate technology and innovation, calls Medtronic’s Design for Reliability and Manufacturability (DRM) program a “great example of the play big, play small mindset.”

“The DRM team in corporate, while it’s not a large team by numbers, is a play big activity,” the 32-year Medtronic veteran said in an interview with DeviceTalks Editorial Director Tom Salemi. “We are the ones who are defining the program and the metrics and kind of rolling out all the programming to the whole corporation from the center with some efficiency and some kind of consistency. And then on the play small side, all the operating units have dedicated, embedded resources that work for them [as] their coaches, part of their project teams.”

Those coaches work with engineers as they advance their individual projects and interact with the corporate DRM team to share information that could be helpful across the wider organization.

What is Design for Reliability and Manufacturability (DRM)?

Hess describes DRM as “a collection of good engineering practices that when used comprehensively on a project, we believe leads to better quality and better outcomes and better performance, basically, for customers and patients.”

It starts at the very beginning of product development and continues through heavy development, manufacturing transfer and post-transfer.

“Early on, do you understand who your customer is and how they’re gonna use the product and what the product will be exposed to?” Hess said. “And then much later, we talk about manufacturing and transferring it to a factory and do we understand how it’s gonna perform and what equipment we’re going to need, or what techniques or technologies are involved? And do we have all that well characterized and tested? And so all these steps on the process from the idea to getting it to market there’s different questions, different activities you do at various points along the way that are all part of the DRM framework.”

The idea is to increase the odds that the team builds the right product, Hess said, while identifying and addressing technical risks early on, such as NUDs, an acronym that stands for new, unique or difficult technologies.

“We bring in experts from across the company, other businesses, other project teams that have familiarity with these technologies to help give the project team some fresh eyes and some objective assessments. And from all that work, then we put together plans that figure out those risks early … as opposed to letting them percolate through the project, then come back and surprise us later,” Hess said.

Changes in Medtronic’s DRM program

The reorganization is hardly the only change for DRM at Medtronic over the past decades.

“One thing that’s changed which is related to DRM is that the problems that we’re solving have just gotten much more complicated and much more diverse. … So the demands we’re putting on our project teams, as far as what they’re building, have gone up quite a lot because now we’re building on almost every business. We’re building complex systems with multiple pieces that ought to fit and work together, sometimes for quite a long time.”

“A long time ago, we were building much simpler systems that had a lot less to interact with and a lot less could go wrong,” he continued. “The stakes are higher as we build more complicated systems to tackle bigger healthcare challenges.”

One of the biggest changes for Medtronic’s DRM team is the proliferation of software in medical devices.

“We’ve actually created kind of special DRM frameworks, if you will, for software because it’s different than a lot of our mechanical testing,” Hess said. … “In software, it’s better just to be testing your software constantly as you’re going. We don’t want them to be constantly testing heart valves as they go, because that would be making them all the time and making tiny changes to them.”

He expects continued adjustments to the DRM program to keep up with the growth of AI, machine learning, and algorithms powered by previously unthinkable volumes of data.