Mike Hess is VP of Corporate Technology and Innovation at Medtronic. [Photo courtesy of Medtronic]
“Play small and play big” was one of CEO Geoff Martha’s mantras as he and his team reorganized Medtronic (NYSE:MDT), the largest medical device company.
The multi-year effort decentralized Medtronic’s three major groups — cardiology, neuroscience, and medical surgery — into 20 tightly focused operating units (OUs).
“OUs can maintain focus and accountability, execute faster, and make quicker decisions while retaining the benefits of size and scalability. … Play small and play big,” Martha said in an October 2020 communique.
Fast forward to today. Mike Hess, vice president 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 at the company, while not a large team in number, plays a significant role,” the 32-year-old Medtronic veteran said in an interview with DeviceTalks editorial director Tom Salemi. “We are the ones who define the program and the metrics and roll out all the programming from the center to the entire organization with some efficiency and consistency. And on the small side, all operating units have dedicated, embedded resources working for them [as] their trainers, part of their project teams.”
These coaches work alongside engineers as they advance their individual projects and interact with the company’s DRM team to share information that could be helpful across the organization.
What is Design for Reliability and Manufacturability (DRM)?
Hess describes DRM as “a collection of technical best practices that we believe, when applied extensively in a project, will result in better quality and better outcomes, and ultimately better performance for clients and patients.”
It starts at the very beginning of product development and continues through intensive development, manufacturing transfer and post-transfer.
“Right from the start, do you understand who your customer is and how they will use the product and what conditions the product will be exposed to?” said Hess. “And much later we’re talking about manufacturing and transferring to a factory and do we understand how it’s going to work and what equipment we’re going to need or what techniques or technologies are involved? And have we characterized and tested all this so well? In all of these process steps from idea to launch, there are different questions, different activities that you do at different points along the way, all of which are part of the DRM framework.”
The idea is to increase the chances that the team will build the right product, Hess said, while early identifying and addressing technical risks like NUDs, an acronym that stands for new, unique, or difficult technology.
“We bring in experts from across the company, other companies and other project teams familiar with these technologies to give the project team fresh eyes and objective assessments. And then from all that work, we put together plans that identify those risks early on…rather than letting them seep through the project and then come back later and surprise us,” Hess said.
Changes in Medtronic’s DRM program
The reorganization isn’t the only change for DRM at Medtronic over the past several decades.
“One thing that has changed with DRM is that the problems we solve have become much more complicated and much more diverse. … The demands we place on our project teams in terms of what they are building have increased quite a bit because we are now building on almost every business. We build complex systems with multiple parts that should fit together and work, sometimes for quite a long time.”
“A long time ago, we built much simpler systems that had a lot less to interact with and a lot less to go wrong,” he continued. “The stakes are higher as we build more complicated systems to address larger healthcare challenges.”
One of the biggest changes for Medtronic’s DRM team is the proliferation of software in medical devices.
“We actually built a kind of special DRM framework for software, if you will, because it’s different from a lot of our mechanical testing,” Hess said. … “In the software industry it is better to constantly test the software while working. We don’t want them testing heart valves all the time because they would be doing that all the time and making tiny changes to them.”
He expects the DRM program to continually adapt to keep up with the growth of AI, machine learning and algorithms powered by previously unthinkable amounts of data.
Comments are closed.