← HOME

[ ABOUT ] — operating context

I do my best work where the domain is ambiguous, the consequences are real, and the system model still needs to be invented.

I care about the layer beneath the product surface: how reality gets represented, what gets mistaken for signal, and how teams preserve good judgment as scale and delegation increase.

Across matching products, platform work, mobile architecture, founder work, QA systems, and agentic workflows, I keep returning to the same class of problem: environments where the real thing that matters is difficult to represent cleanly.

My background spans scaled consumer systems, organizational leadership, and early-stage product building: OkCupid, WeWork, and recent AI-native systems work with very small teams.

[ PUBLICATIONS ]

InfoQ presentation

Engineering Dumb: Modern Mobile Thin Clients

A talk on remotely configurable mobile layouts and behavior, drawn from complex product work at OkCupid.

read / watch →

OkCupid Tech Blog

Engineering Smart && Building Dumb

A technical write-up on building an Android thin client at OkCupid, separating product behavior from shipped mobile code.

read / watch →

[ WORKING PRINCIPLES ]

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.

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 seams, control surfaces, workflows, playbooks, and documentation as system components that shape what a team can become.

Human judgment stays near consequence

In agentic systems especially, I want operators near the decisions that are still cheap to change and far from the repetitive work that systems should absorb.

[ BEST FIT ]