A decade inside one of the largest healthcare companies in the country teaches you something the consulting playbooks miss: most enterprise problems aren't really technology problems. They're authority and adoption problems wrapped in technology clothing.

I spent ten years at CVS Health. I left in 2024 to do this — to build Nellson Associates the way my father built his practice in the nineties, except with the patterns I'd picked up from a decade of working inside a system you can't break.

People ask me whether I regret leaving. The honest answer is no, but it's a more interesting no than I expected. Let me tell you what I mean.

## What CVS gave me that no consulting bootcamp could have

The biggest gift wasn't technical. It was the discipline of working in a system where the cost of being wrong is paid by patients, not by quarterly revenue charts.

When you build software for a pharmacy, you cannot ship a bug that delays a prior authorization for a chemo patient. There is no "fail fast and iterate" version of that. There is "the system works correctly the first time, every time, for every patient, or you do not ship it." That constraint is everywhere in healthcare technology and it changes the way you think about architecture, about testing, about deployment, about everything.

I'd come out of that environment understanding why enterprise software is the way it is. Not because I'd read a book about it. Because I'd lived inside the constraints that produce it.

## The OCRXML testing tool

The thing I'm most proud of from my CVS years isn't a project anyone outside my team ever saw. It's a testing tool I built called OCRXML — a system that would take a stack of scanned medical documents, extract the structured data, and verify that downstream systems handled them correctly.

It 10x'd my team's testing speed. It also taught me something I still believe about enterprise software: the highest-leverage code in any large organization is usually invisible to the org chart. The systems that make everyone else's work possible don't show up in headcount discussions. They show up as "things that just work" and they get noticed only when they break.

I think a lot about that now. When clients hire me to look at their stack, the first question I ask is "what's the OCRXML in your system?" Meaning — what's the invisible piece of infrastructure that nobody owns, nobody talks about, and nobody knows how to replace? Because that's where the real risk lives.

## Prior authorization and the moment "data quality" stopped being abstract

Somewhere in year four or five I was working on a system that handled prior authorization data. The project was framed as a data quality initiative. We were going to clean up some upstream feeds, normalize some fields, deduplicate some records. Standard healthcare data work.

About six weeks in I realized that "data quality" in this system wasn't an abstraction. It was the difference between a patient getting their medication on time and a patient calling the pharmacy in tears because their script was hung up in a system that couldn't read the fields it had been given.

That was the day I stopped using the phrase "data quality" in client conversations. I started saying "patient outcomes with extra steps" instead. It lands differently. People who run healthcare operations understand what you mean immediately, and people who don't run healthcare operations finally understand what you actually do for a living.

## The eighteen months between knowing and going

I'd like to tell you that I made the decision to leave on a Tuesday and was independent by the end of the month. That's not what happened.

The decision took about six months to crystallize. Then it took another twelve to actually plan the exit — building up savings, talking to my wife about the trade-offs, sketching out what the first year of independent practice would look like, doing the math on what I'd need to charge to make it work.

If you're sitting in a corporate job right now wondering whether you should leave, the thing nobody tells you is that the planning phase is longer than the deciding phase, and the planning phase is where most people quit. Not because they fail. Because the planning gets boring and the corporate paycheck keeps showing up and the friction of staying becomes lower than the friction of leaving.

I almost talked myself out of it twice. The thing that kept me on track was a spreadsheet — a literal spreadsheet — that I updated every two weeks. It tracked savings runway, billable rate scenarios, client pipeline, and one metric I called "regret rate" which was just me writing down how I felt about staying versus going on a 1-10 scale. When the regret rate stayed above a 7 for three months in a row, I gave notice.

## Why I'm not bitter

I'm grateful, not nostalgic. There's a difference.

CVS bought me the patterns I now charge for. The discipline. The instinct for what's actually load-bearing in an enterprise system. The understanding of how regulated environments shape engineering culture in ways that don't show up in any architecture diagram. Ten years of working inside one of the largest healthcare technology operations in the country gave me a kind of knowledge that you cannot get any other way.

I'm not nostalgic because I don't want to go back. The work I'm doing now is more interesting, more direct, and more aligned with the kind of practitioner I want to be. The corporate years were the prerequisite, not the destination.

If you're considering the leap, here's what I'd tell you: don't leave because corporate is bad. Leave because independent is the version of the work you actually want to do. Those are different reasons and they produce different outcomes once you're out.