In the fast-evolving MedTech world, all experts face the shared challenge of adapting to rapid technological advancements while navigating stringent regulations. Within this dynamic environment, professionals from different subfields – such as software engineers and regulatory specialists – bring unique perspectives that can enrich each other's ability to manage change effectively. As technologies advance and new products enter the market, regulatory frameworks struggle to evolve to keep pace. This creates a pressing need for agility: how can MedTech professionals balance the flexibility required to innovate with the responsibility to ensure compliance, maintain product safety, and ultimately deliver value to patients? Read on to get to know the ISS AG experts Matthias Leuenberger, Senior Software Engineer and Alicja Ritz, Senior Regulatory Affairs Manager, IVD.
From Code to Compliance: Insights on Navigating Change in MedTech
At first glance, the roles of a Regulatory Affairs Manager and a Software Engineer appear vastly different. The former focuses on ensuring compliance with global regulations, managing complex submission processes, and coordinating with stakeholders to secure market approvals. The latter dedicates their time to designing, coding, and debugging software, balancing technical problem-solving with collaboration to meet user and project requirements.
However, their intersection becomes evident in managing the complexity of product development and regulatory compliance. When examined more closely, a significant point of overlap is their shared need to handle constant change. Both operate in environments shaped by evolving customer needs, advancing technologies, and shifting regulations. Success in both disciplines hinges on flexibility, adaptability, and collaboration. Engineers require precise requirements alongside room to experiment and innovate, while regulatory professionals need to ensure compliance without stifling creativity, navigating the complexities of regulations, and balancing the need for practical, timely solutions. Ultimately, excellence in problem-solving, mastery of complexity, and embracing change are essential for both.
Alicja, what is the regulatory perspective on change, and how is it effectively navigated ?
– Stay Updated on Regulatory Changes: Monitor upcoming regulations to anticipate impacts.
– Assess Compliance Impact of Device Changes: Evaluate how changes affect safety and performance.
– Adhere to Non-Negotiable Requirements: Some regulatory standards cannot be altered.
The Risk vs. Reward Dilemma and The Role of Documentation
Both fields constantly face decisions where they must weigh risk against speed. Software engineers balance the technical risks of making changes to code against the need to deliver updates quickly. Regulatory Affairs, on the other hand, balances compliance risk with the speed of product approval.
Matthias offers a thoughtful approach to this balance: assess the worst-case scenario when in doubt. If the potential fallout from a change is manageable, engineers may move forward with minimal testing. However, more thorough analysis and validation are necessary if the risk is high. It’s a strategy that allows for flexibility while ensuring critical issues are not overlooked. Alicja agrees that while risk-based, pragmatic, and scientifically sound approaches are valuable and commonly used in regulatory affairs, she emphasises that, no matter the approach, compliance must never be compromised. While strategies can be adjusted to streamline processes – like entering a market with limited claims or splitting a product into smaller ones to be managed and released at different stages – safety and efficacy requirements always need to be met. But just like in software development, the planning phase is crucial. By anticipating regulatory requirements early on, companies can build products that comply with standards without needing to backtrack later. While there are both similarities and differences in how risk vs. reward is balanced, engineers and regulatory affairs professionals, working in different subfields, share this common challenge. Both agree that regular collaboration and exchange between the two disciplines are essential for navigating this balance and ensuring compliance. This need for cooperation arises partly from the fact that regulations are not entirely specific, relying instead on the expertise, knowledge, and best judgment of developers and regulatory affairs managers in their respective medical and technical fields.
One area where software engineers and regulatory managers find common ground as well is in the importance of documentation. Both fields require extensive record-keeping to track changes, ensure compliance, and justify decisions. For software engineers, maintaining thorough documentation of code changes is vital – not just for regulatory purposes but also for troubleshooting and future development. However, Matthias admits that while theory dictates that regulatory and technical requirements should be documented as changes occur, in practice quite often major polishing of the documentation is required at the end of the project. From a regulatory perspective, Alicja emphasises the importance of integrating documentation into the development process rather than treating it as an afterthought. In regulated industries, developers must allocate sufficient time for documentation to ensure their work is prepared for external review. Taking this proactive approach can save considerable time and effort later on. Regulatory teams can support developers by providing suitable templates and processes that align with engineering workflow. Regular retrospectives to evaluate what worked well and identify areas for improvement are a valuable starting point.
Matthias, how can change be effectively navigated using a software engineer's approach?
– Track Changes: Use source control systems to document every code update, including the rationale behind changes as far as possible.
– Understand System-wide Impact: Assess the potential ripple effects of each modification, as small changes can cause unexpected issues.
– Prioritise Testing: Implement rigorous testing to catch bugs and issues, knowing that no testing method is foolproof.
Timing Regulatory Involvement: Getting It Just Right
Ultimately, the success of any product development project depends on how effectively these two fields work together - ensuring that both the technical and regulatory aspects of product development evolve in parallel, to deliver a safe and effective product to market.
But when exactly should regulatory expertise be integrated into the product development cycle? Both Matthias and Alicja stress the importance of involving regulatory teams early - but not too early. When the concept is still fluid during the initial stages, focusing too heavily on detailed compliance requirements can be counterproductive. Instead, regulatory experts can provide guidance on broader aspects, such as the product's intended use, target market, and potential risks. For example, in the development of medical devices or software, there’s often an initial "feasibility stage" where prototypes are created and tested on a small scale. The primary goal at this stage is to establish whether the product has the technical potential to fulfil its intended purpose. Once this initial testing phase is completed, it's time to bring in regulatory experts to ensure the product will meet the necessary safety and performance standards and, later, for marketing approval. Alicja elaborates on this: regulatory managers are not just about adhering to rules; they offer strategic insights into bringing the product to the target market efficiently, balancing effort and outcomes. Understanding the “the state of the art”, the landscape of existing products, clinical risks, healthcare system needs, and both global and local requirements is essential for shaping the development process.
Considerations on Recurring Topics and Discussions
In any collaboration or specialised field, certain buzzwords can provoke mixed reactions or differing perspectives. Alicja and Matthias, for example, have distinct views on budget, review, and planning:
Budget
Alicja
Daily business involves managing budgets, and I appreciate it when people consider the budget and set a clear framework. However, the budget must be realistic – delivering something large with a very small budget is not feasible.
Matthias
Dealing with it can be frustrating, but it's part of the process. Estimating time is often difficult, as some tasks are unpredictable. The budget should be flexible, with a buffer or an easy way to secure more funds when needed.
Review
Alicja
Daily business…
Matthias
Code review is crucial for catching errors and improving quality, but it’s often overlooked in daily work. It helps others familiarise themselves with the code, making handovers easier. Despite its importance, it can be hard to keep up consistently.
Planning
Alicja
Planning is important to me, and I value the quote from the FDA's design control document: "There's never time to do things right, but there's always time to do things over."
Matthias
Planning is important, and often, you realise that more planning would have been beneficial. However, it’s also important not to overdo it. A good plan should be flexible enough to accommodate change.
The Additional Superpowered Teammates That Would Boost the Two Experts
While embracing change is a shared challenge for both, their choice for a superpowered or fictional teammate reflects a focus on abilities that would support them in their daily work. Matthias would opt for something a little unconventional - the rubber duck. Far from being just a quirky object, the "rubber duck debugging" technique is a well-known concept in the coding world. It suggests that when you're stuck on a coding problem, explaining it to a rubber duck (or any inanimate object) can help you find the solution. The simple act of articulating the problem often leads to a breakthrough, even without another person’s involvement. This playful yet effective strategy has been a part of programming culture for over two decades and continues to resonate in developer communities as a meme. On the other hand, Alicja would choose a teammate with more muscle - or mind control. Regulatory issues often face resistance, as they are frequently associated with additional work. To tackle this, Alicja jokingly suggests Professor X for his mind manipulation abilities, which could convince others of the importance of regulations. Alternatively, if transparency and leverage are key, she’d opt for the Incredible Hulk - after all, who wouldn’t listen to someone with that kind of power? In either case, Alicja’s superpowered teammate would help cut through resistance and get things done.
In the end, both agree that sharing a drink would be a great opportunity together to further explore and discuss challenges and similarities in their daily collaboration. What’s clear from this conversation is that both roles demand a deep understanding of how change impacts the product lifecycle – whether it involves software or physical devices. While the tools and strategies may differ, the fundamental principles of managing risk, adapting to change, and ensuring product integrity remain universal. The key takeaway? Mastering complexity and embracing change is not just a theoretical concept – it’s a practical reality for anyone involved in creating, developing, and bringing products to market. As industries continue to evolve, so too must the people behind them, constantly refining their processes and finding new ways to balance innovation with compliance. That’s where ISS AG’s integrated approach comes into play, fostering collaboration across disciplines, encouraging knowledge-sharing, and working together to discover the most effective solutions.
About The Experts


Author
Read Other Blogs Related to This Topic