Residency Advisor
It’s 11:47 p.m. You’re post-call exhausted, sitting in the resident lounge or your tiny apartment, scrolling through LinkedIn. Another “Clinician-turned-CEO” announced a Series A. Another “physician founder” posting pictures of themselves at some accelerator demo day with lines like “So proud of our incredible engineering team.”
You zoom in on the photos.
You see MacBooks, Figma screens, graphs, people in Allbirds talking about cloud infrastructure and data pipelines. You see words like “LLM-powered,” “FHIR integration,” “Kubernetes,” “edge computing.”
And you think:
“I can barely get my VPN to work. Who do I think I am even considering leading a medtech company? I’m not technical. I’m just… a doctor.”
The uncomfortable truth you’re scared to say out loud
Let me just say what’s in your head:
- “I don’t code. At all. Like, not even ‘Hello World.’”
- “I don’t understand architecture diagrams or what a ‘stack’ is.”
- “Engineers intimidate me. I nod along, but half of it might as well be Greek.”
- “Investors are going to see right through me. They’ll ask one technical question and I’ll implode.”
- “I’m going to waste money, time, and people’s careers because I don’t know what I’m doing technically.”
And the worst one:
- “Real medtech CEOs are ex-Google, ex-Meta, MIT PhDs. I’m… a hospital employee who fights with Epic.”
Let me be blunt: those fears aren’t crazy. They’re not made up. There are specific ways lack of technical depth can absolutely screw a founder.
But here’s the part your anxiety conveniently ignores: a shocking number of successful medtech and digital health companies are led by people who cannot write a single line of production code and couldn’t design a PCIe board if their life depended on it.
And no, they’re not all just “visionary” hand-wavers. They’re doing specific things right that you can absolutely copy.
What “technical enough” actually means for a clinician founder
You’ve built this picture in your head where “technical enough” = “I can do every job on my team at an intermediate level.”
That’s fantasy. Even good CTOs can’t do every job on their team at an intermediate level.
Here’s what “technical enough to lead” actually looks like in medtech / digital health as a physician founder:
You can:
- Ask engineers and scientists intelligent questions without derailing the conversation.
- Smell BS when someone throws big words at you to hide confusion or incompetence.
- Understand what’s hard vs trivial, risky vs safe, fast vs 18-month slog.
- Translate clinical reality into specific, buildable requirements.
- Make tradeoff decisions (“v1 has X and Y, but not Z”) grounded in reality, not fantasy.
- Hold your technical leaders accountable without micromanaging implementation.
You do not need to:
- Write production code.
- Design the circuit board yourself.
- Optimize SQL queries at 2 a.m.
- Architect the cloud infrastructure.
- Be the smartest technical person in the room.
If you are the smartest technical person in the room, you hired wrong.
The three real risks of “not being technical” (that you should take seriously)
You’re not crazy to worry. There are real ways this can blow up. I’ve seen these three patterns hurt non-technical clinician founders over and over:
1. You become a hostage to your first technical hire
You hire “the tech person” and suddenly:
- Their word becomes law because you can’t evaluate alternatives.
- Timelines triple and you can’t tell if it’s real or laziness.
- They declare things “impossible” that are actually just annoying.
- You feel too insecure to push back, so you just… accept.
If they’re good and honest, maybe you get lucky. If they’re mediocre or misaligned, you’re stuck.
2. You waste time building the wrong thing
Non-technical founder pattern: spend 18 months building a beautiful, complex system… that doesn’t matter clinically or commercially.
Because you couldn’t distinguish:
- “Cool” from “critical”
- “Technically impressive” from “clinically impactful”
- “Engineer dream” from “actual buyer need”
This one’s brutal, because everyone worked hard. And it still fails.
3. You can’t earn credibility with technical hires or investors
Engineers can smell when a founder is faking it.
If your answers are:
- Vague (“we’ll use AI to optimize everything”)
- Buzzword soup (“we’ll be cloud-native microservices-first”)
- Unrealistic (“we’ll build an Epic replacement in a year”)
…you’ll repel the kind of senior technical people who actually could make you successful. And investors who know tech will quietly pass.
None of this requires you to become an engineer. It does require you to close a specific gap: technical literacy, not technical mastery.
What you already bring that most “technical” founders don’t
Here’s the part you’re severely under-valuing.
You already have abilities that engineers and MBAs envy and cannot fake in medtech:
- You deeply understand clinical workflows. Who touches what. When. Under what pressure.
- You can tell instantly when an idea is clinically useless even if it looks fancy in a slide deck.
- You know how hospitals really buy stuff, not the fantasy version people imagine.
- You have credibility with clinicians, which is absolutely non-negotiable in serious medtech.
- You can smell “this will never actually be used on a real ward” in 5 minutes.
And you’ve already done hard, insane things:
- Survived residency schedules.
- Managed crashing patients with incomplete information and conflicting priorities.
- Navigated hospital politics, EMR mess, and resource constraints daily.
Plenty of Stanford CS grads panic at the thought of calling a nurse, much less arguing with an ICU attending. You already operate in chaos. That’s founder training.
The missing piece is building a minimum “technical shell” around all of that so you’re not naked in those conversations.
How technical you actually need to be, for different medtech paths
Let’s make this less abstract. This is roughly how much technical depth you need depending on what you’re building:
| Type of Company | Technical Depth Needed by Founder |
|---|---|
| Simple digital health app / workflow | Low–Medium |
| AI/ML diagnostic tool | Medium–High |
| Regulated medical device (hardware) | Medium–High |
| Biotech / wet lab platform | Medium–High (but domain-specific) |
| Data platform / interoperability tool | Medium |
If you’re thinking:
- “Lightweight companion app for my specialty”
- “Better patient portal / care coordination / telehealth workflow”
You need to understand product, data privacy, integration basics, and how software is built in phases.
If you’re thinking:
- “ML model that reads CTs”
- “Implantable device”
- “Novel sensor tech”
You’ll need a strong technical and regulatory cofounder. And you’ll need enough technical literacy to understand validation, limitations, and real-world deployment.
You do not have to be the technical brain. But you can’t be a tourist either.
A brutally honest mini-roadmap to get “technical enough”
You’re probably thinking, “Okay but how? Do I need to go get a CS degree? Take a bootcamp? Quit medicine for a year?”
No. Please don’t do any of that.
Here’s what I’d actually do in your shoes over the next 3–6 months, while still working.
| Step | Description |
|---|---|
| Step 1 | Decide rough product type |
| Step 2 | Learn basic concepts |
| Step 3 | Shadow real product team |
| Step 4 | Practice specs with mock engineers |
| Step 5 | Ship tiny technical project |
| Step 6 | Recruit serious technical partner |
Step 1: Decide which bucket you’re in
You can’t learn “tech” in the abstract. It’s too broad. You need a lane.
Rough forced choice:
- Mostly software for workflows / patient engagement / analytics
- Mostly AI/ML (prediction, diagnosis, triage)
- Mostly device / hardware / sensors
Pick one. Your learning will be 10x more efficient.
Step 2: Learn the “board game rules,” not how to carve every piece
For software-ish medtech, you should be able to answer, in plain English:
- What’s an API?
- What’s a database vs a front-end?
- What’s the difference between a prototype and a production system?
- What’s technical debt?
- What’s the tradeoff between building custom vs using existing tools?
For AI/ML medtech:
- What’s the difference between training, validation, and test sets?
- What’s overfitting and why should you be terrified of it in healthcare?
- What is “data drift” and why will it come back to bite you?
- What’s sensitivity/specificity vs AUROC vs PPV/NPV in real clinical terms?
For device/hardware:
- Basic components: sensors, processing, power, communication.
- What’s a prototype vs a manufacturable design?
- What’s required pre-clinical vs clinical vs regulatory?
- Basic understanding of IEC/FDA classes, at least at the “am I building a Class II or III monster?” level.
You can get 80% of this from:
- 1–2 good books per area.
- Talking to 3–5 experienced people and asking focused questions.
- A short, targeted online course with practice, not binge-watching lectures.
Don’t chase certificates. Chase actual understanding.
Step 3: Sit in on real product/engineering meetings
If you can, find:
- A friendly digital health startup.
- Your hospital’s IT/innovation team.
- A local accelerator.
Ask to shadow product/engineering syncs. Not sales pitches. Internal meetings.
Your only job: listen for patterns.
- How do they talk about timelines?
- How do they decide what not to build?
- How do product and engineering disagree?
Do this a few times and your “I have no idea what they’re talking about” will shift to “I kind of follow 60–70% of this.” That’s enough to start.
Step 4: Practice writing “founder-level” specs
Non-technical founders screw this up constantly. They throw vague dreams at engineers like:
“Make it super intuitive and AI-powered and scalable and secure and integrate with everything.”
That’s how you burn money.
You need to practice writing:
- What problem are we solving?
- For who?
- In what context?
- What exactly should the system do, step by step?
- What won’t it do in v1?
Then have a technical friend tear it apart. Over and over.
You don’t need to code… but you probably should touch something small
Let me be clear: you do not need to become a real software engineer or hardware designer.
But building one tiny thing end-to-end will rewire your brain in a good way.
Options:
- No-code MVP: use Bubble, Glide, or similar to mock up a simple workflow.
- Tiny data project: use a Python notebook to clean a toy dataset and calculate something basic.
- Micro-automation: use Zapier/Make to glue together a simple patient or task flow.
Not because that will be your final product. It won’t.
But because after even one weekend doing this, conversations like:
- “Yeah, auth and data models will take longer than UI polish”
- “Integrating with that EMR isn’t a 2-week thing”
- “We need to think about logging/monitoring from day one”
…will stop sounding like alien noise.
And you’ll stop doing the worst thing non-technical founders do: drastically underestimate the cost and complexity of “just adding that feature.”
The cofounder problem you’re dreading
Let’s hit the big fear:
“I’ll never convince a real technical person to cofound with me because I’m not technical enough.”
Here’s the truth I’ve seen over and over:
Serious, senior technical people are constantly pitched garbage ideas by non-technical people who:
- Don’t understand the domain.
- Don’t understand users.
- Don’t understand constraints.
- Don’t understand tradeoffs.
You, as a clinician, already have a massive edge on domain and users. If you add even moderate technical literacy plus a clear, grounded problem, you become dramatically more attractive than 90% of the “idea guys” they meet.
What turns them off isn’t that you can’t code. It’s that you:
- Don’t ask good questions.
- Don’t listen when they explain constraints.
- Want to skip validation and jump to “let’s just build it.”
- Chase buzzwords instead of concrete problems.
Fix those, and your “I’m not technical” handicap shrinks fast.
| Category | Value |
|---|---|
| Vague problem definition | 80 |
| Unrealistic timelines | 70 |
| Buzzword-heavy pitch | 65 |
| No willingness to learn | 60 |
| No user validation | 55 |
How to avoid feeling like an idiot in technical conversations
You’re imagining a nightmare investor meeting:
They ask: “So what’s your stack?”
You: “…we’re using, uh, AI and the cloud.”
Here’s a simple rule: it’s completely fine to say “I don’t know,” but it’s not fine to sound like you don’t even know what you should know.
So you aim for something like:
- “On architecture specifics, my CTO can go much deeper. At a high level, we’re building on [XYZ] because [this clinical and business reason]. The important constraints for us clinically are A, B, and C, and the technical design is built around those.”
You own what you do know (clinical & product constraints) and confidently hand off the deep technical details. That’s what real CEOs do all the time.
You’re not trying to cosplay as your CTO. You’re trying to prove you:
- Understand the problem deeply.
- Understand how tech enables/limits that.
- Have the right people to execute.
When your anxiety might actually be right
There are situations where your “I’m not technical enough” fear might be more signal than noise.
Examples:
- You want to build a cutting-edge AI diagnostic tool, but you have zero interest in really understanding how ML validation works. You just want to “slap AI on it.”
- You want to build complex device hardware but can’t be bothered to learn the basics of device risk classes or testing.
- You resent needing a technical partner and just want to “hire some devs overseas” and be done with it.
If that’s where you are, I’d slow way down. Because those paths will eat you alive if you stay willfully ignorant.
You don’t need to love technology. But you do need to respect it enough to learn the rules of the game you’re trying to play.
Quick sanity check: are you actually too “non-technical” right now?
Run yourself through this:
- Can you explain your product idea without saying “AI,” “blockchain,” or “cloud” even once?
- Can you sketch out, on paper, what data gets captured, where it lives, and who touches it?
- Can you list 3 things that will be technically hard about your idea and why?
- Can you explain what “version 1” looks like in painful, limited detail?
If you’re at “no” on all of those, fine. That just means: step 1 is building that understanding before you spend money hiring anyone.
If you’re at “yes” on some of those, you’re already more “technical” than your brain will admit.
The part nobody tells you: “technical enough” is a moving target
Even senior engineers are constantly “not technical enough” for something.
- Backend devs feel lost in front-end frameworks.
- ML folks feel lost in low-level systems work.
- Hardware engineers feel lost in DevOps conversations.
You will always be “not technical enough” for some part of your company. The trick is choosing which part that is and hiring people you trust there.
Your job as a founder-CEO is not to be the universal expert. It’s to:
- Set a direction that’s clinically and commercially sane.
- Hire people who are better than you in their lane.
- Understand each lane well enough to detect nonsense.
- Make coherent tradeoff decisions between lanes.
You’re allowed to feel intimidated by the tech side. You’re not allowed to use that as a reason to stay permanently ignorant.
FAQ (exactly 5 questions)
1. Do I need to learn to code to be a credible medtech founder?
No. But touching something small—like a no-code prototype or a toy Python notebook—will massively help your intuition and credibility. You’re doing it for understanding, not to become the primary builder.
2. How technical should my first key technical hire or cofounder be?
Very. If you’re not technical, your first senior technical person should be strong enough to be a CTO in a Series A–B company, or at least on that trajectory. If you’re “training them up from junior,” you’re taking a massive risk.
3. What’s the fastest way to stop feeling lost in technical meetings?
Pick your product lane (software, AI/ML, device), learn core concepts for that lane, then sit in on 5–10 real product/engineering meetings (even as an observer). After that, start writing your own product specs and getting feedback from technical friends.
4. Won’t investors judge me harshly if I’m non-technical?
They will judge you harshly if you’re non-technical and vague, unrealistic, or dismissive of technical risk. If you’re clinically strong, clearly learning, and have a serious technical partner, most healthcare investors are fine with a non-technical CEO.
5. What if I’m already working full-time—how do I fit this technical learning in?
You don’t need 20 hours a week. Two focused 90-minute blocks per week beats random doomscrolling. One for concept learning, one for talking to technical people or practicing specs. Protect those blocks like call shifts.
Specific, actionable next step:
Tonight, grab a piece of paper and force yourself to draw your product idea as a simple diagram: boxes for users, arrows for data movement, a rough “where does stuff live” guess. Then send that sketch to one technical person you know and ask, “What’s stupid or missing here?” That’s your first real step toward being “technical enough.”
