If it were simply about the engineering or the science, it would make things so much easier. Effective medical device R&D leadership isn’t just about the data. It’s about bridging the communication gap between what needs to be done and why it matters to the company.
Sometimes the programs or projects are clear. But medium to large companies with broad portfolios often find themselves managing multiple small fires at once. These issues can coalesce into the proverbial burning platform, and it’s your job as the R&D leader to prevent that from happening.
Communication to the executive team and the R&D team needs to be clear, convincing, and simultaneous. Executives need to understand why investment matters. The R&D team needs to feel heard and understand the strategy driving the company. This is easier said than done when it takes at least 1.5 to 2 years to launch any new idea into the medtech marketplace.
Over the past several decades, I’ve spent my working life participating in and leading R&D teams across many geographies and company profiles. Success depends entirely on communication and teamwork. It doesn’t matter how difficult the engineering or science is. The team needs to coalesce to make it happen.
What’s Changed (and What’s Been Lost)
As a Generation X engineer, I feel privileged to have gone to school before having a lot of help from the internet. My contemporaries and I spent considerable time trying new ideas and failing. At the time, I didn’t appreciate that I was learning from each failure and finding my own path to success.
Now, in this new age where many questions are answered even as you think of them, something has been lost. The creativity and judgment of staring down a tough problem and finding a solution is lost when endless potential solutions might be served up directly to you without failing. There are countless tools that speed along innovation, and I’m excited to use them. But I’ve seen a gap in the effort made to figure out a solution, which leads to giving up too easily.
Here’s the thing about AI and other problem-solving tools: they’ve trained on data available to the internet or the source. Engineering and science are really about new ideas standing on the shoulders of the giants before you. These things are not found in the mix. They’re found at the interface. Discoveries are found as outliers or changepoints in the data. In engineering and science, you must build something and test something in the real world to create a new outcome. This won’t be found in existing data. It’s actually creating value with new data, new experiences, new outcomes.
The COVID Effect
I watched a transformation in engineering skillsets over the years that was exacerbated by COVID stay-at-home mandates. Now I watch the fallout and have been searching for ways to help as an R&D leader.
Every single company I speak to about R&D says the same thing: We have old devices that have been neglected (the chip crisis of 2021/22 is partially to blame). We need to get a next generation out into the field quickly, and it needs to be “connected,” but none of our devices meet the standards. When we submitted to FDA, there was a significant amount of data missing. Now we have to remediate.
Then there’s the worst scenario: My R&D team doesn’t understand how the product is used. This is because they were not trained to go to the hospitals. What do executives expect? Nobody was allowed into hospitals for a while, and budgets for travel were significantly slashed for a couple of years. This means an entire generation of R&D engineers was stuck at home searching online for answers but never generating new ideas or actually creating value.
Where We Are Now
Since the COVID crisis, we’re entering a new phase where R&D teams are generally back in the office and hopefully visiting customers to understand product use. The tools available are speeding along problem solving, but have you seen a hesitation to “draw outside the lines”?
I have. On more than one occasion, I’ve sat with engineers who can’t “meet the specs” but have no idea what the specifications were written for and don’t really know how to reset the right ones. This is a clear issue with problem solving. The new engineers don’t have enough mentorship to know how to push boundaries or reach out to another person to find a new way. Some of them want to know and are ready to push. Some of them are comfortable just searching the documents, getting test data, but don’t know how to interpret the data on their own if the answer isn’t coming clearly from the tool. Or worse yet, they’re waiting for R&D leadership to answer for them.
Where Do You Start?
So where do you start? How does the leader change behavior and get the R&D and cross-functional team back into solving problems creatively?
Let’s call it “the 4 Ps”: Planning (Strategy), People, Process, and Programs.
This takes you back to the beginning. With clear strategic and planning vision aligned with the executives, you can focus your engineering team on what skillsets you really want to cultivate within your workforce and what you just need to outsource.
Then you need to reflect that back to your engineering group so they know what you’re trying to build in the long term. After clear team communication, you can focus on your people: their skillsets and whether you have a deep enough bench to get it done (there are many tools to use here).
Next comes process and the tools you have. If the problem is requirements management, then get a tool in-house and train on it, for example. These tools can be turnkey and provide a focus for your staff to learn from.
Finally, programs. The heart of the growth strategy. Your teams need to know what their goals and timelines are within the spending constraints. Make sure you have solid project management on these. If you don’t deliver the programs on time, the executive leadership will become impatient and it will be harder to make the long-term change you need to sustain success.
In the coming articles, we can talk about motivation, how to identify it in your staff, and how to influence it for long-term gain.