Representation before automation
I like working on systems where the hard part is not feature code alone, but making the underlying reality legible enough for software and teams to reason about well.
[ ABOUT ] - operating context
I do my best work when the problem is messy, the stakes are real, and the team needs clearer structure.
At OkCupid, that meant helping a dating product represent identity and fit more carefully. At WeWork, it meant building mobile platform foundations as the team grew. At Pier, it means owning the product and technical shape of a small AI company.
The pattern underneath is consistent: I look for the model the product depends on, the signals teams use to make decisions, and the structure that lets people keep moving without losing judgment.
My background spans scaled consumer systems, organizational leadership, and early-stage AI product building with very small teams.
[ WORKING PRINCIPLES ]
Feedback over static instruction
The strongest systems learn. I tend to care more about the loops that preserve quality and improve judgment over time than about short-lived bursts of output.
Architecture as leverage
I treat platform boundaries, workflows, playbooks, and documentation as system components that shape what a team can become.
Human judgment stays near consequence
In AI systems especially, I want people near the decisions that are still cheap to change and far from the repetitive work that systems should absorb.
[ BEST FIT ]
- Principal or staff-plus product engineering for complex product systems
- Architecture and workflow design in AI companies
- Platform design where reuse and adaptability matter
- Small teams that need both technical leadership and hands-on delivery