About

I've spent my career building software, and the last several years leading the people who build it. I was an engineer first, mostly backend and platform work in Python, and moved into management without ever really leaving the technical side. When I write about running engineering teams, it's grounded in having done the work, not just managed it.

The writing is mostly about engineering leadership: org design, platform strategy, and the decisions that don't have clean answers. I'm drawn to the judgment-call parts of the job, the ones that are hard to get right and easy to get wrong, more than the tidy frameworks.

A few convictions shape how I lead. High performance is the output of high expectations and high psychological safety, in that order, not the input. A team that owns the outcome will consistently outperform one that's only executing a plan handed to it. And most of what I manage, day to day, is expectations, up, down, and sideways. The rest is helping good engineers do the best work of their careers and then getting out of their way.

I've done most of that at startups, five of them so far. I've stayed in early-stage work for the genuinely novel products, the kind that break the mold instead of fitting it, and for the chance to shape them fundamentally before the direction is set. The case studies are where the detail lives; my resume has the short version.