The machine can be complicated. The experience can't be.
I work on the part of the system where that gets decided: the moment a person has to look at what a machine is telling them and decide whether to believe it.

The question
Why does software keep failing the humans it's supposed to serve?
It took me to Human-Computer Interaction at Carnegie Mellon, and to learning to code, because you can't see how a system fails without knowing how it's built.
Then it stopped being a question about software. An accident left my partner with a traumatic brain injury. I put the building down and started studying the system it's all supposed to serve: the human mind.
The lab
I trained as a coach. Hundreds of hours in rooms where the only tool is language, watching in real time what a person can take in, where trust breaks, and which question moves someone instead of proving I'm smart.
Then large language models arrived, and language became the primary material of AI systems. The thing I had been studying turned out to be the interface.
What it produced
NIH-funded research infrastructure serving a 700-household cohort study. Paloma AI, a coaching companion built to close the gap between who someone is and who they want to be, with 83% of beta users returning weekly. A machine-state interface kit built on a five-state model with colorblind-safe encoding and a three-tier treatment for stale data, because a system that reports on itself has to be honest about what it doesn't know.
Why it matters to a team
Coaching is a communication discipline, and it does most of its work before anything gets designed.
With engineers, I ask about constraints before I bring solutions, so we start from what's real. With stakeholders, I look for the concern under the request, which is rarely the one being stated. With operators and users, I hear the problem behind the problem. In a room where people disagree, I can hold the tension long enough for the real decision to surface instead of smoothing it over.
Teams are systems too. The same practice that unsticks a client is what surfaces the unspoken objection in a roadmap review, gives a quiet designer room to be heard, and makes critique something people want to show up for.
What I bring
01. I think in systems. How machines, data, and people connect to produce an outcome, and where it will break before it does.
02. I design for behavior. What people can take in under pressure, what breaks their trust, and what sustains confidence over time.
03. I build and ship. Take the ambiguity, hypothesize, build, test, iterate. I measure success by what changes, not what launches.
04. I move work through people. Translating across engineering, product, and leadership. Growing designers through mentorship and critique.
What's next
Physical AI. Systems that move through the world and report back on what they found, where a person has to act on that report with real consequences attached. Setting design direction for that work, building the team that delivers it, and making the case for it where it gets funded.
If you're building autonomy that has to work in someone's hands, not just perform on a benchmark, that's the problem I'm built for.