My Own Answers to the 10 Questions

Short answer. These are my own answers to the ten questions I published for vetting an operator. One answer is less impressive than the others: I have not personally owned a payer contract negotiation across Commercial, Medicare Advantage, and Dual populations. I say so directly, so a client does not find out later.

If I’m going to publish a list of questions I’d ask a candidate operator, it’s only fair to answer them myself first.

1. How long will it take you to sit in a regulatory or clinical conversation without me translating for you? Zero ramp time on the underlying science. My training is in bioengineering, I developed diagnostic instrumentation for cochlear implant patients at Massachusetts Eye and Ear, and I led health and life sciences engagements for Johnson & Johnson and Siemens Healthcare, including a large-scale digital health and enterprise IT implementation at J&J. What I don’t know on day one is your company’s specific regulatory posture, nobody could without doing the work, but I’m not learning clinical or scientific vocabulary while I do it.

2. What’s actually different about our reimbursement model compared to the SaaS or consumer businesses you’ve worked in before? This is the one I’d rather answer honestly than impressively. I understand healthtech financing and business models well, but I haven’t personally owned a payer contract negotiation across Commercial, Medicare Advantage, and Dual populations. If that’s the specific gap in your company, I’d tell you that directly rather than let you find out later.

3. What operational mistakes have you seen other healthtech companies make that a generalist wouldn’t catch? The most common one is treating compliance as something you bolt on before a raise instead of building in from the start. Close behind is letting headcount outpace org design, so a company ends up with more people and the same amount of actual structure.

4. If a customer or partner asks a technical question about how our product works clinically or scientifically, what happens next? In most cases, I can hold that conversation myself. My bioengineering and medical device background covers general clinical and scientific literacy; the only time I’d loop someone else in is for something proprietary to your specific product, like a detail of your own algorithm or IP that only your team would know.

5. Walk me through how you’d handle a request from compliance that conflicts with a shipping deadline. I’ve made this exact call as an operator, not just advised on it. As CEO of Seron Security I owned SOC 2 compliance and the full P&L at the same time, which means I’ve felt both sides of that tension directly. My default is that compliance wins when the exposure is real, and the job is figuring out fast whether it’s real risk or just deadline pressure dressed up as one.

6. What’s your plan for the first 30 days, and how much of it is learning our industry versus building anything? Almost all of it would be learning your company, not the industry. That’s the actual claim behind the “under 30 days” ramp I talk about: the science and regulatory context are already there, so the time gets spent on your people, your specific gaps, and your history, which is exactly what the Discover phase of the Operational Spine™ is built to do.

7. What healthtech-specific rules or frameworks do you already understand well enough to act on without researching them first? Data handling and privacy posture, SOC 2 and financial controls, and the regulatory landscape around medical devices and digital health. HIPAA is worth being precise about, because founders are often sold it as a legal specialty and it isn’t. What it actually requires is operational: access controls, audit logging, vendor and BAA management, breach response, and training. That’s the same work I built end-to-end for SOC 2 at Seron Security, and the same governance I ran over PII and regulated data at enterprise scale at Verizon. Counsel belongs where counsel belongs, on contract language and on interpreting a genuine edge case, not on building the thing.

8. Have you ever had to defend an operational or financial decision under real scrutiny, in court, to a regulator, or in a board meeting, and what did it teach you? Yes. Early in my career I evaluated a VR technology against its contract performance terms, built the financial damages model myself, and then defended both the science and the numbers in court. It taught me that composure under real scrutiny isn’t a personality trait; it’s a function of actually understanding the material well enough that the pressure doesn’t change your answer.

9. How would you build financial and compliance reporting that survives real investor diligence, not just reporting that looks good in a demo? The same way I built it at Seron Security, where compliance and financial reporting weren’t separate workstreams; they were both my direct responsibility as CEO. Reporting built by someone who’s actually been accountable for it looks different from reporting built to be shown once and never stress-tested.

10. If we’re wrong about something operationally and it surfaces during a diligence process or a customer audit, how much earlier could you have caught it? This is the actual purpose of the Diagnose phase of the Operational Spine™: a structured pass across people and structure, process and cadence, compliance and risk, and financial infrastructure, built to surface exactly this kind of gap before it becomes a diligence question or a customer escalation. Sold on its own it’s the Operational Assessment, five weeks start to finish, and you walk away with a written gap map either way.

None of these answers are meant to close the conversation, they’re meant to open one. If you’re evaluating me for an engagement, or evaluating anyone else against this same list, that’s exactly the point: ask, listen for what’s fluent versus what’s a promise to go find out, and start there.