I take technical leadership of your medtech product — team, architecture, roadmap, compliance — for as long as it takes for the trajectory to hold without me afterwards.
When an interim CTO makes sense
Three situations come back again and again. Your engineering team is moving without direction: everyone does what they know how to do, nobody settles the architecture, and the trade-offs end up on the desk of a chief executive who does not have the information needed to decide. Or your CTO has left, or never existed, and you discover that the product roadmap and the regulatory file are running along two parallel tracks that never meet. Or you are preparing a raise, and the investor is looking for whoever carries the technical and regulatory credibility of the product. In all three cases, hiring a full-time CTO takes months and assumes you already know what you are looking for. An interim answers the urgency without freezing a long-term decision: you get operational technical leadership immediately, and you then hire knowing precisely which profile you need, because the role will have been held and documented. This engagement makes no sense if what you actually need is extra development capacity. I am not here to write features in place of your team. I am here to decide, to arbitrate, and to answer for the technical trajectory in front of your board as much as in front of your notified body.
What I take ownership of
I take technical responsibility for the product, not an observer’s role. In practice that covers four fronts. Architecture first: the structural choices in the software, the debt that has to be paid down and the debt we knowingly carry, the interfaces with the device, with hospital information systems and with the most safety-sensitive processing, and the verification strategy. The team next: who does what, what is missing, what we bring in-house and what we hand outside. Hiring, technical assessment of candidates, and building up competence in what medical work demands — an excellent developer who has never worked under IEC 62304 needs to be coached, not merely informed. The roadmap: what we ship, in what order, and above all what we do not ship. In medical software every added feature carries a regulatory cost; making trade-offs without that cost in mind is a way of arranging a nasty surprise at assessment time. Compliance last: software life cycle, requirements traceability, risk management, design history file. I do not hand this subject to regulatory affairs and pick it up at the end of the project — it is built in the code repository, at the pace of the product.
My place in your organisation
I sit where technical leadership sits: on the executive committee, in product reviews, in the team’s own rituals. The pace follows what is at stake — a few days a month to hold a course and unblock decisions, or a far heavier commitment through a critical phase such as preparing an assessment. We set it together at proposal stage, and we revise it when the situation changes rather than putting up with it. I work directly with your developers. I read the code, I review merge requests where that is useful, I write code myself when an architectural doubt has to be settled. This is not remote supervision: technical leadership that never looks at the code is told about the product instead of knowing it, and discovers the gap at the worst possible moment. Outward-facing, I carry the technical narrative in front of your investors, your hospital counterparts and your notified body. That is often what is missing most: someone who speaks the language of the board and the language of engineering without turning either one into an approximation of the other.
What remains after I leave
An interim engagement is judged on what holds without me. So I organise the exit from the start, not in the final quarter. Architecture decisions are written down, with their context and their consequences, and not merely taken in a meeting. The software life cycle is documented and owned by the team, rather than carried at arm’s length by one person. Requirements, tests and risks are linked in a system your developers maintain day to day, because traceability reconstructed after the fact survives neither a serious review nor the first version change. On the human side, I prepare your successor: either an internal profile I coach into the role, or an external hire for which I define the position, screen the candidates and hand over. Either way, the handover happens in overlap, with real decisions to make, and not through a document left on a table on the last day. I have no interest in making the engagement open-ended: an interim CTO who settles in permanently has failed to build what they were there to build.
Let’s talk about your product
A credible peer, in the boardroom and in the operating theatre.