An engineer who works across boundaries.

I started where most people start — writing code that had to ship. What changed the shape of my career was noticing how often the code wasn't the problem. A page was slow because a CDN rule cached the wrong variant. A login failed because two systems disagreed about who owned the session. A market disappeared from search results because a redirect and an hreflang tag were quietly contradicting each other.

So I learned to read the whole path. Browser, edge, cache, server, application, database, and every third-party service hanging off the side of it. Not because breadth is impressive, but because a problem that crosses layers cannot be solved from inside one of them.

That's the work now: architecture for platforms that have to survive years of change, troubleshooting when nobody can agree on the cause, and modernization that doesn't require betting the business on a rewrite. Often the most valuable thing I deliver is a smaller system than the one I found.

I also spend a lot of time translating. Between engineers and stakeholders, between an old platform's assumptions and a new platform's expectations, between what a system was designed to do and what it's now being asked to do. Technical leadership, in practice, is mostly making sure everyone is solving the same problem.