How I lead

Skim mode is on: just the key point of each paragraph, and the story behind each belief.

I set a clear direction for the product, and I build the environment where designers do the best work of their careers. In practice, that’s a shared picture of where we’re going, fewer things in the team’s way, and a few practices that stop a team from re-deciding the same things every week. These are the beliefs behind that work, each with the story that tested it.

I start with the people, the way I’d start any design problem

I listen before I change anything. I sit in 1:1s, watch how the work actually moves, and look for what gets in the team’s way: work no one can see, and knowledge that lives in one person’s head.

How much I direct depends on the task, not the title. Someone on new ground gets clear structure and frequent check-ins. As they build confidence, I move to coaching, then real delegation. The same designer can need direction on an unfamiliar device and full autonomy on their home surface.

Autonomy still has a bar. New ownership doesn’t land on day one. When we moved to journey squads, leads first read “accountable” as “do every task,” and designers on unfamiliar devices took longer than planned to get productive. I named both early, reset what the lead role meant, and owned the ramp-up miss instead of pulling the work back to me. Eight months in, I went back through it with the team: we fixed what was ours to fix, and I carried the rest upward.

The story: Giving a design team an operating model, and room to own it

I organize around the customer’s job, not the org chart

Products ship in the shape of the teams that build them. So I map the customer’s jobs first, set one shared measure of success, and organize the team around the journey instead of the surfaces.

Reorganizing design alone isn’t enough. Product and engineering have to share the same priority order, or the problems just move to their layer.

The stories: Turning three onboarding silos into one journey to a merchant’s first $500 and From a feature list to one model of the admin’s job

I give real ownership, and hold the standard

Ownership is written down, not implied. Leads own an outcome end to end, and the team maintains the systems it runs on, so nothing depends on me to stay alive.

A few rules everyone holds beat a stack of approvals. I’d rather agree on a handful of non-negotiables than add a review step for every risk.

I give away the work I start. My speed starts things; the team owns the win, and gets seen for it.

The story: Giving a design team an operating model, and room to own it

I run today’s commitments and tomorrow’s direction together

A roadmap that’s only a list of feature requests never catches up. I keep committed work shipping and run the longer-term direction beside it, both tied to one model of the customer’s job, so the team never starts from zero when the commitments run out.

The cost is a case I have to keep making. I make it with evidence, and I bring in the people who file the feature requests. They become the best allies for fixing the root problem.

The story: From a feature list to one model of the admin’s job

AI belongs in the product and in the practice, with a person accountable

In the product, AI should remove the customer’s work, not add features. The best AI work erases the unpaid hours around the critical moment, like setup, data entry and making sense of reports, and stays out of the moment itself.

Trust is the design constraint. AI drafts and suggests; the person decides anything that matters. It never asserts a number it can’t show the source for, and when it fails, it falls back to the path that already works.

In the practice, AI is part of how the whole team works. I run it like any other practice: shared foundations instead of individual tricks, a person accountable for every call, and honest measurement of what it actually changes.

The stories: Turning three onboarding silos into one journey to a merchant’s first $500 and Giving a design team an operating model, and room to own it

I tell the truth about the evidence

Every result I share says how I know it. Measured, early, projected or my estimate, in plain words. Projections are useful; presenting them as results isn’t. When a test comes back inconclusive, I say so and say what I’m changing.

Every trade-off names its cost. If a decision didn’t give anything up, it wasn’t a decision.

The story: Turning three onboarding silos into one journey to a merchant’s first $500

Get in touch

Want to talk about design leadership, AI in products, or any of this work? I'd like to hear from you.

Email me LinkedIn