What do Medical Device Software Engineering Leaders want?
What would help them become more effective & productive?
As a provider of software development solutions, this is an excellent question – and it’s one I’ve been asking myself for over 20 years.
Today seems as good a day as any to share what I’ve learned, after conversations with leaders around this very topic. We discussed issues ranging from finding (and keeping) great talent, to desired engineering processes, and the types of outsource partners they’d be willing to engage.
In order to preserve anonymity, I’m going to share what I’ve learned from local leaders…in their words…because I feel it’s more important to benefit from their knowledge, than become distracted by their name, title or employer.
“What’s the one thing that attracts me…?’
‘High quality, reliable, predictable engineers who create resilient software applications (software that can recover on its own without human intervention/correction to a variety of situations) where I can stretch my constrained budget to increase capacity.’ ‘(Since most R&D teams and IT Team rarely have the staff or annual budget to effectively execute on KTLO (Keep the lights on) and new development concurrently).‘
‘From the medical side, I would want to work with software partners that have a proven track record in helping their clients gets products cleared through FDA and released to market.’
‘Reliable time to market where I can show how “great I can be” (inclusive of high quality, and resilient software of course) would be the only key driver that I would be interested in taking an unsolicited call by someone that I don’t know.’”
There is another position to consider, and that’s what type of solution leaders may seek, now that we’re living in the age of pandemic.
From a software quality engineering leader, regarding new requirements caused by the Covid-19 impact:
“Think about the current issues with corona virus, I would assume that temporary resourcing would be beneficial once companies get back to business.’ ‘I assume they will want to recoup some of their lost time, maybe adding additional resources to help in targeted areas.’”
When you consider the importance of medical devices, especially products like ventilators which can save a human life, it’s almost impossible to describe the importance of reliability, usability and patient safety. Medical professionals on the front lines of this pandemic, don’t have time to wait on machines that operate poorly, aren’t intuitive, or break down frequently.
Reliability & usability are key.
Let’s take a look at why this (seemingly important) aspect of medical devices is so difficult to achieve.
What Problems do software engineering teams face?
I sent this question to several very senior, experienced, medical device software engineers; some of their responses are particularly revealing:
“Even in a company where current medical software was being written, determining and establishing new process for new types of medical oriented software is difficult.’ ‘For example, service-oriented tools, remote diagnostics, training materials, …’
‘When in crunch time, every team player is overwhelmed with tasks and responsibilities.’ ‘The first tasks to suffer are process oriented tasks.’ ‘This is because people tend to be good at what they are good at. Developers are good developers.’ ‘Process people are good at process.’ ‘IMHO, it is hard to find a mixture of the two since if there is a hybrid person, they will favor one skill over the other, especially under stress.’
‘Serviceability is hardly ever addressed in software design.’ ‘Yet, the quality of the product from the client point of view is what the company is graded on over time.’ ‘An excellently designed serviceability platform reduces the client support frustrations and helps the development team solve it easier.’ ‘Without serviceability data, developers tend to feel the issue is with the client.’ ‘They don’t actively think out of the box to how a client actually uses their product.’ ‘Serviceability data will show exactly how a client uses their product.’”
Additionally, critical team interactions are important topics of conversation…here’s another quote from our highly experienced software engineer:
“The interaction between test and developments teams is very tricky. Test spending too much time with development makes them think like developers. At a glance this seems like a great idea, but it is not. The testing team must test like users, not developers. But without interaction with development, testers don’t always know what to test. So, what I have found to be good is the use of an intermediary. This intermediary is the one to communicate with both teams. This intermediary should understand testing needs and understand development. This allows all bases to be covered the best they can.”
This article began with ‘what do software engineering leaders want’, and transitioned to the challenges they face (every day) when designing & building medical devices…that they hope end users will benefit from.
This is no small task, given the reality of limited budgets, ever shrinking time-to-market, and increased requirements changes when customers ask for more features…than they originally requested.
Add in things like key people leaving the project (regardless of reason) and you get a better understanding of the pressures these leaders face on a daily basis. They’ve had to sacrifice time with their families in order to meet the stringent demands of the job…so their employer can compete in the marketplace and remain viable.
It appears to me, that for software engineering leaders to provide maximum contributions to their employers/businesses, and ultimately their customers, their ‘needs’ being met are a crucial element in this equation.
As long as they have the tools & resources necessary to deliver on their promises, and their teams have the appropriate skills & experience, then (they believe) they have everything they need to succeed.
What do you think?
I’d love to hear your feedback on this – please feel free to send me a note and share your thoughts & concerns…I will be happy to respond to you. 😊
After all, we’re in this together.