I came to engineering sideways.

I build for the people inside the system.

Most of my career has been technical work where the outcome depends on trust, judgment, and whether another person can actually use what you give them. EMS taught me to communicate clearly when the stakes are high and the person in front of me is having one of the worst days of their life. Financial advising taught me that the mathematically optimal answer is not always the best answer for the person who has to live with it. Those are engineering lessons now.

They shape the requirements I write, the defaults and failure modes I choose, and what I automate in the first place. I think about the person inside every system: what they know, what they'll do under pressure, what incentives the design creates, and whether the tool makes their job easier without asking them to become a technologist. Goodhart's law is a useful warning here: once a measure becomes a target, behavior bends around it. If a system is harder to use than doing the job by hand, it isn't a good system, no matter how clever the engineering is.

Now I build the platform.

I'm the Business Systems Lead at Valeo Financial Advisors. I own the internal platform end to end and set the technical direction for the team building it: production apps, data, infrastructure, CI/CD, and the standards every project inherits. Much of that work now involves AI agents—not just using them, but building the shared context, guardrails, and review systems that make them useful to a team. Building CARL taught me where autonomy loses; the design and ownership stay human.

I build the environment around the work.

My scope extends beyond individual applications. I define shared patterns for architecture, delivery, and review, then encode them in versioned tooling and context used across repositories. When work crosses system boundaries, I connect technical decisions back to the financial-services domain and their production consequences.

I still implement directly when my context or technical depth is useful. But the broader goal is to make good engineering practice easier to repeat: give contributors useful context, catch problems early, and keep production responsibility clear.