I built a clinical research tool in a weekend, in a field I'd never worked in - and what it taught me about judgment, problem-solving, and who I hire.
A friend of mine is a stroke nurse at Cedars-Sinai. Last year he published research showing that majority-Black and majority-Hispanic communities in LA County face significantly longer travel times to comprehensive stroke centers. When a stroke hits, those minutes are brain cells. He wanted to take the analysis further but didn't have a way to scale it.
On a Saturday around 7pm, I started building. By Sunday night there was a live tool scoring all 1,802 California ZIP codes on proximity to certified stroke care: a data pipeline pulling CMS hospital data, Census demographics, and Google Maps drive times, an interactive map, a methodology page, and a public dataset. It was shocking how fast it came together.
That's the part that sounds impressive. It's not the interesting part.
Here's the part that is. I'm not a stroke expert. I'm not an epidemiologist or a GIS analyst, and I'd never touched clinical data in my life. My partner on the project is the clinician. It would be easy to call what happened picking up the subject matter quickly - that's not it. I didn't pick up the subject matter. I picked up the problem.
I had never built a backend. Never worked directly with an API. The speed came from AI doing the execution while I did the directing. But here's what actually happened inside that speed:
I trusted the wrong data source. The CMS dataset I started with classified hospitals using a quality-rating proxy. It looked authoritative. It was wrong in ways that mattered. When we checked it against the LA County EMS directory, the actual authority on which hospitals are certified stroke destinations, we found 63 hospitals with certifications that didn't exist, 5 hospitals listed that weren't certified at all, and 8 certified hospitals missing entirely.
I got fooled by a name. The dataset showed "Providence Queen of the Valley Medical Center" as a comprehensive stroke center. There is also an "Emanate Health Queen of the Valley Hospital" in West Covina. One is in Napa, 400 miles away. The data pipeline didn't know the difference, and for a while, neither did I. A ZIP code in the San Gabriel Valley was being told its nearest comprehensive stroke center was 37 minutes away when the real one was 4 minutes down the road, invisible because it wasn't in the source data.
I shipped a scoring model that erased the story. When my partner gave clinical guidance on how to weight the scoring, I implemented it, rescored the state, and pushed it live. Then I looked at the map. It was green. Almost all of LA County scored 75 or above. The earlier version had shown a county full of orange and red, of disparity. My first instinct was that I had broken something.
That instinct, "this map is too green," is a design instinct. Something about the artifact didn't match the truth I knew was underneath it. I stopped, pulled the distributions, and traced the scoring logic ZIP by ZIP.
The model wasn't broken. LA County genuinely is dense with comprehensive stroke centers. Nearly every urban ZIP is within 15 minutes of one, so nearly every ZIP maxed out the score. The model was working exactly as designed.
Which is the actual finding. My partner's earlier research proved racial disparities in stroke access exist in LA County. Our proximity model scored the same county as nearly uniform high access. Same county, same hospitals, opposite headline. The resolution: proximity-based access scores systematically understate urban inequity, because supply density saturates the metric while the real barriers, symptom recognition, 911 utilization, within-hospital disparities, concentrate in the same communities the map paints green.
What looked like a bug for an evening became the methods contribution of the paper we're now drafting. The ceiling isn't a defect in our model. It's evidence that the field's standard approach fails in dense cities.
I froze the scoring model that night. It doesn't change again until clinical review is done. Some decisions are data engineering. That one is clinical judgment, and knowing the difference is the job.
I lead a large design organization, and I'm in the middle of transforming it into a team of AI-native builders. This project clarified something I'd been circling for months: I have to coach in two opposite directions at once.
My younger designers iterate fast. AI has made them faster. But speed without problem framing is just expensive thrashing, and they can't yet find their own way out of the mess. They get the Queen of the Valley name collision and don't notice. For them, my coaching sounds traditional: slow down. Define the problem. Ask what data source is actually authoritative. Diagnose before you prescribe.
My seasoned principals have the opposite gap. They know process deeply, and process is exactly what they reach for when the ground shifts. For them, the coaching is the reverse: throw half of it out. Trust the gut you spent fifteen years tuning. Build the thing before the brief. Get into the mess on purpose, because the mess is where you learn that the map is too green.
Same destination, opposite pushes. Threading that needle is the hardest leadership problem I've had in years, and the most important one.
What I know from this weekend: the bottleneck has moved. Execution is no longer the constraint. Judgment is. Knowing which data source to trust, which anomaly is a bug versus a finding, when to ship and when to freeze. That was always the real job. AI just stripped away everything that was hiding it.
It's also how I think about who to bring onto a team. I don't hire for expertise in whatever we happen to be building this quarter. Subjects change. The next ambiguous problem won't look like the last one, and the person who memorized the current domain is rarely the one who navigates the next.
I look for the opposite: people who are experts in problems and ambiguity. Drop them into a field they've never seen and they find the real question underneath it, recognize which patterns from everywhere else apply, and know which instinct the moment calls for. Domain knowledge is rentable. Judgment in ambiguity is the thing that travels, and it's the thing I hire for.
The Stroke Access Score is a research collaboration with James Beavis RN BSN SCRN. The scoring model is under clinical review and the tool is not for clinical use. A methods paper is in progress.