An engineer who measures by outcomes.

I think before I type. The best technical decisions I've made were the ones where I spent more time understanding the problem than writing the code. Most “engineering problems” turn out to be unclear requirements wearing a costume.

I see things through. From the first discovery call through to production deployment — scoping the problem, designing the system, writing the code, owning the outcome. I don't hand things off halfway.

I measure work by what changed. Users onboarded, infrastructure costs reduced, products shipped on time, junior engineers leveled up. Not lines of code or frameworks used.

I default to leverage. Tooling for the team, playbooks for hiring, structured mentorship, reusable components, AI-assisted workflows — anything that makes the next problem cheaper and faster to solve than the last one.

I'm drawn to infrastructure automation, authentication protocols, and making complex systems accessible to people who shouldn't need to understand the complexity underneath.

Outside of work I read widely — engineering and distributed systems, technology news, economics, business, personal finance, and health. The best ideas almost always come from outside the immediate problem.