I build the systems people bet their business on — and I want to be in the room when they do.
Whether I'm designing software, leading a technical initiative, or exploring a new idea, I want to be close enough to see whether it actually works. That's why I'm moving from building the product to being in the room with the people who depend on it.
From shipping the system to standing behind it.
I spent five years as a software engineer and technical leader at Okta and Auth0, owning architecture for platforms that enterprise customers bet their business on. I built a status page they could trust during incidents, internal tooling that turned minutes of digging into seconds, and led migrations delivered at 100% on time.
But the part I kept gravitating toward was never the stack. It was the discovery session where I got three teams to finally agree on what we were building. It was translating a compliance requirement into a decision a room could actually act on. It was watching a support engineer's face when the tool I built handed them an answer in seconds instead of minutes.
That's the work of a solutions engineer: being fluent enough in the technology to earn trust, and human enough to make it land. I want to do it full-time — deep in a customer's problem, connecting what's technically true to what they actually need.
"The hard problems were never the technical ones. They were getting three teams to agree on what we were building."
Principles I bring to every room.
A demo isn't a performance. Say what the product can't do as clearly as what it can — that's what earns the next conversation.
Name the system, the metric, the outcome. Concrete detail builds credibility faster than any superlative.
Engineering, security, product, the customer — good technical work aligns them instead of forcing a trade-off.
Discovery first. Always.
The habits that made me a good engineer are the same ones that make a good solutions engineer.
I run structured discovery to surface architectural dependencies and unspoken constraints early — before they become the reason a deal or a project stalls.
Clear enough for a VP, precise enough for an engineer. I meet each stakeholder where they are without losing the technical truth.
A status page, a lookup tool, a working prototype — I'd rather show something real than describe it. Proof beats promise.
Incident response taught me the relationship is made after the sale — in how you show up when something breaks.
A few other things about me.
The relationships thread doesn't stop at the office. Ask me about any of these and I'll happily talk your ear off.
I genuinely love good docs. Migrating Auth0's was a highlight, not a chore.
Being Security Champion rewired how I weigh risk against velocity.
Seattle-based and remote-native, coffee and mountains non-negotiable.
Always poking at a new idea or side project on the weekend — from custom silversmithing jewelry to hosting community events to reading maps for my next adventure.