About

I wrote my first program on an Apple IIe in the mid-1980s. I was eight or nine years old, and the thing that hooked me wasn't the computer itself — it was the feeling of making something happen that hadn't existed a minute before. A few lines of BASIC, and the screen did what I told it to. That feedback loop has never stopped being interesting to me.

By the time I was building software professionally, the industry had shifted from desktops to the web, and the problems I cared about shifted with it. I spent my early career learning how to build systems that didn't fall over — how to think about data models, concurrency, failure modes, the boring-but-essential architecture decisions that separate software that works from software that works until it doesn't.

Over the years, the scope grew. I went from writing code to designing systems, from designing systems to leading the teams that build them. I've scaled backend infrastructure to handle tens of thousands of concurrent users. I've built engineering organizations from a handful of developers to teams with real structure — hiring plans, delivery processes, technical roadmaps that aren't fiction. The common thread is that I've always stayed close to the work. I don't lead from a distance; I lead from inside the codebase.

The scale taught me something that took a while to internalize: the hardest problems in engineering aren't technical. They're organizational. They're about getting smart people aligned on the right problems, giving them the context they need to make good decisions, and then getting out of their way. The technical problems are solvable. The people problems require judgment.

For the past five-plus years, I've been deep in digital health — leading engineering for companies building products that touch real patients and real clinicians. Health tech is a domain where the stakes are genuinely high and the constraints are unforgiving. You're dealing with regulatory requirements that don't bend, data sensitivity that demands rigor, and users who are often under pressure and have zero patience for software that wastes their time. It sharpened every instinct I had about building reliable, well-considered systems.

Working in health tech also reinforced something I already believed: that the best engineering leaders are diagnostic before they're prescriptive. You don't walk into a new organization and start rearranging the furniture. You listen. You watch how information flows, where decisions get stuck, what the team knows that leadership hasn't heard yet. You form a view, and then you act on it. The pattern works whether you're debugging a production outage or rebuilding an engineering culture.

Today I work with founders and companies who need senior engineering leadership but don't need — or can't yet support — a full-time executive. Sometimes that means serving as a fractional CTO, embedded with the team several days a week, making the architectural and organizational decisions that will define what's possible in two years. Sometimes it means a focused engagement: integrating AI into a product, conducting technical due diligence for an investor, or helping a team navigate a hard scaling challenge.

Whatever the shape of the work, the approach is the same. Understand the real problem first. Bring the experience of having solved similar problems before, but hold it loosely — every context is different. Build things that are durable enough to outlast the current moment but not so over-engineered that they slow you down. And always stay close enough to the work that you can tell the difference between a plan that looks good on paper and one that will actually survive contact with production.