What 20 Years in Healthcare Tech Taught Me About Building Systems That Matter
After twenty-plus years building software in healthcare and fintech, I've learned something that sounds obvious but isn't: the hardest part of building systems that matter isn't the technology. It's understanding the consequences of getting it wrong.
When Failure Isn't an Option
Early in my career, I worked on HL7 and DICOM integration engines at Philips Healthcare. These were systems that moved patient data between clinical devices — the kind of data that directly impacts care decisions. A dropped message or a malformed transformation isn't a bug report. It's a patient whose results don't show up when a doctor needs them.
That experience rewired how I think about software. Every architectural decision, every error handling path, every deployment strategy — they all carry weight when the system you're building operates in a domain where mistakes have real consequences.
The $73 Million Lesson
The project that crystallized this for me was a financial institution migration I led as a Solutions Architect. We needed to transfer 70,000 bank accounts and move $73 million through the Federal Reserve over a multi-week phased execution.
The technical challenge was significant — but the real challenge was building a system so reliable that we could guarantee zero financial discrepancies. Not "near zero." Zero.
That meant:
- Exhaustive reconciliation at every step of the pipeline
- Idempotent operations so any step could be safely retried
- Real-time monitoring with circuit breakers and alerting
- Phased execution so we could validate each batch before proceeding
We shipped it. Zero discrepancies. But the months of architecture work, edge case analysis, and paranoid testing that got us there — that's where the real engineering happened.
What I Look For in Systems (and Teams)
After two decades, I've developed strong opinions about what makes systems — and the teams that build them — successful:
Clarity over cleverness. The best architectures aren't the most sophisticated. They're the ones where any engineer on the team can look at a component and understand what it does, why it exists, and what happens when it fails.
Event-driven thinking. Most complex systems are really just streams of events that need to be processed reliably. Once you start thinking in events, a lot of architectural complexity melts away. RabbitMQ has been my go-to for years, and the patterns around event-driven architecture continue to prove themselves.
Domain expertise matters. You can't design a great healthcare platform without understanding healthcare workflows. You can't build reliable financial systems without understanding settlement, reconciliation, and regulatory constraints. The best technical leaders invest in understanding the domain as deeply as they understand the technology.
Mentorship compounds. The single highest-leverage thing I do as a leader isn't writing code or drawing architecture diagrams. It's helping other engineers level up. When you teach someone clean architecture or DDD, that knowledge multiplies across every system they build for the rest of their career.
Looking Ahead
After twenty years, what still excites me is the intersection of deep technical work and leadership — the kind of role where the engineering leader isn't just managing process, but actively shaping the technical direction and raising the bar for the entire team.
The best systems I've built weren't just technically sound. They were built by teams that understood the domain, cared about the outcome, and held each other to a high standard. That's the environment I always want to be part of — and the environment I try to create wherever I go.