Tech Founder Justin Fulcher spent more than a decade building RingMD's telehealth services across fifty countries before stepping into public service as a founding member of the Department of Government Efficiency. He first lead DOGE efforts at the Department of Veterans Affairs, then at the Defense Department, before being promoted to Senior Advisor to Defense Secretary Pete Hegseth.
The trajectory is intriguing. Most people move from institutions into the private sector, not the other way around. We spoke with him about what travels in the other direction: what the experience of building a company under genuine constraints teaches you about the way public institutions work.
Q: Founders who've worked inside government often describe the experience as a kind of culture shock. Did you find that to be true?
A: Less than you might expect. What surprised me wasn't how different the government was – it was how familiar the underlying problems felt. The same gap I'd spent years working on in healthcare – the gap between what the technology could do and what the system would actually allow – was present in both agencies I worked with. The inefficiency looks different on the surface. The structure underneath it is usually the same: an institution that still works the way it was designed to work decades ago, in conditions that no longer exist. That's not a government problem specifically. That's an organizational problem, and I'd seen it before.
Q: You've spoken about institutional drag as the real bottleneck in both healthcare and government. What does that actually look like when you're inside it?
A: It looks like a capability that exists but struggles to reach the people who need it. You have the technology, you have the systems and infrastructure, and you have a clear enough picture of what needs to happen. But the procurement process, the approval chain, or the workflow assumptions built into the system create a lag that has nothing to do with whether the solution is sound. In healthcare, a notoriously regulated environment, we saw it with clinicians and regulatory bodies that were organized around in-person attendance as a default condition. Remote care wasn't forbidden; it just wasn't what the system was built to accommodate.
Government IT has the same structure. The technology available to federal agencies is often genuinely capable. What constrains it is the layer of outdated process sitting between the tool and the outcome it's supposed to produce. That's the drag. It's not malicious, and it's usually not even visible to the people inside it. It's just the accumulated weight of decisions that made sense at the time and were never revisited.
Q: The obvious objection to bringing a startup mindset into government is pace – startups move fast, government moves slowly by design. How do you respond to that?
A: I think that framing misidentifies what's actually useful about startup experience. The lesson isn't moving faster. The government shouldn't necessarily move fast in the way a seed-stage company moves fast. The stakes are different, the constituencies are different, and the consequences of getting it wrong are different.
The real lesson is about making decisions with incomplete information and not using incompleteness as a permanent excuse for inaction. That's a discipline founders develop because they have no choice. The resources aren't there to wait for certainty. What I've seen in large institutions (public and private) is that the availability of process can become a substitute for judgment.
You can follow every step correctly and still produce an outcome that doesn't work. Founders learn to ship imperfect solutions and correct in motion, because a functioning system at eighty percent is more useful than a slightly better one that arrives two years late. The instinct isn't recklessness. It's a preference for a live problem you can fix over a theoretical one you're still designing around.
Q: At the VA, you were described as taking a notably methodical approach – interviewing staff, reviewing programs, asking questions before drawing any conclusions. Was that a deliberate choice?
A: It was the only approach that made sense given what I was there to do. If the goal is to understand where a system is failing, the worst thing you can do is arrive with the answer already written. The people who work inside these institutions every day carry knowledge that no briefing document captures. Most are incredibly hard working and mission-driven. They know where the real bottlenecks are; they know which processes exist on paper and which ones actually govern how decisions get made. That's not something you learn from the outside. You have to go find it. The conclusions I drew at the VA were grounded in what I actually found there, not in what I expected to find. I think that's the minimum standard for any reform effort that intends to produce something durable rather than just something visible.
Q: Based on what you've seen in healthcare and the defense department, what do governments consistently get wrong about technology adoption?
A: Premature and prescriptive specification processes. Government tends to procure technology by describing what it wants in exhaustive detail before it fully understands the problem it's solving. By the time a contract is awarded, the requirements document reflects the system as it existed when the process started, not the system as it actually operates.
The vendor delivers exactly what was asked for, and it still doesn't solve the problem because the problem is seldom interrogated with the necessary diligence. What works better is building the specification around the constraint rather than the ideal.
At RingMD, the most demanding deployments we had – rural India, remote Alaska Native communities with minimal connectivity – forced us to build for the most constrained environment first. Everything else became easier by comparison. Government procurement tends to work in the opposite direction: optimize for the standard case and treat the hard case as a special project. That's where the gaps compound.
Q: If you could import one startup operating principle into government wholesale, what would it be?
A: Comfort with revision. Startups survive by treating a bad result as information rather than a verdict. You ship something, it doesn't work the way you expected, you find out why and you adjust. That cycle (build, test, correct) is so fundamental to how founders operate that it barely registers as a principle.
Inside government, it's genuinely difficult. Revision reads as failure. Changing course invites criticism. The incentive structure pushes institutions toward defending decisions rather than interrogating them. The result is that core systems operate inefficiently but get protected rather than fixed, because fixing them requires admitting they were wrong. A government that could build in that same tolerance for revision – not as an admission of incompetence but as a standard operating mode – would be able to move through problems that currently just accumulate. That's the one I'd import.
The Adjustment That Matters Most
For Fulcher, the question that connects everything – a telehealth platform scaled across fifty countries, reform work inside two federal agencies, and a focus on defense technology – has always been the same: why do institutions with the right people and the right resources still fall short of what they're capable of? His answer, consistent across every context, is that the gap is rarely technical. It's structural. And structure, unlike technology, can be changed by the people willing to work inside it.
Government doesn't face the same pressure, but Justin Fulcher's argument is that it could choose to apply the same standard anyway. That choice, more than any specific technology or policy, is what he believes separates institutions that improve from ones that don't.
Copyright © 2026 California Business Journal. All Rights Reserved.
For California Business Journal Disclaimers, go to /terms-conditions/.
