For more than 19 years I’ve designed complex B2B platforms, and the work that pulls me in is always the same: a system too dense to take in at once, and the chance to make it simple, even elegant, without hiding what makes it powerful. Along the way I learned that building the team is as much a design problem as building the product.

Quiet leadership

Early in my career, a manager told me that if I wanted to move into leadership, I would need to change my personality. For a long time I believed it. I thought leadership meant being the loudest voice in the room, with the right answer on the spot, and I worked hard to fit that mold. It never felt right.

Years later, a different manager told me that leadership comes in all styles, and I just had to find mine. What I found is what I call quiet leadership: not the loudest voice or the center of attention (as you read this on an entire website about me, gasp!), but opinions that count, and confidence without arrogance.

People tell me I get up to speed fast in unfamiliar situations, untangling the technical details and getting to an elegant solution before I have the full picture. My teams tell me they appreciate the calm: they can be themselves and be honest with me, and they can see I’m pushing for great work.

Leading people

Hire for craft, not the pitch

I look for technical excellence and real craft, but I don’t need to be sold. Good work speaks for itself, and often it’s the quieter, more thoughtful designers who find the best solutions. Someone once made room for me to lead my own way, and I try to make that room for the people I hire: people who are hungry to solve problems, can take direction, and can have an honest conversation without taking it personally.

Critique the work, not the person

In critique I help people separate themselves from their work, so we can look at it objectively and see where it can get better. Weak work doesn’t make someone a weak designer. Usually the work isn’t even weak; it just needs more thought.

Nudge, don’t prescribe

I give people as much room as I reasonably can to reach a great solution instead of handing them mine. Sometimes they land where I pictured, and sometimes somewhere completely different and just as good.

Leading the work

Complexity is learnable

People can handle far more complexity than we give them credit for. Nobody expects to fly a 747 the first time they see the cockpit. So I’d rather test whether people can learn something than whether they get it at first glance, and design to bring them along, with an escape hatch when it’s too much. It’s the bet this site makes: a sky to explore, and a plain version to read for anyone who’d rather not.

Trust intuition, then test it

I value research; I’ve pushed for it and hired researchers more than once. But I have a strong sense of what will make sense to people, and I’ve seen research used to put off a decision. I’d rather start from a clear point of view and use research to sharpen it, or to prove it wrong.

Speed needs more thinking up front, not less

AI makes execution faster, and it’s tempting to treat that as permission to skip the thinking. It’s the opposite: faster execution is what makes the time to align affordable. And now that anyone can build a believable prototype in an afternoon, a polished one can end the conversation it was meant to start. I build in time for real discovery, even on a tight timeline.

How I work with AI

At Pax8 I helped rebuild the product lifecycle around agents. We started with the process, not the tools: I led a service blueprinting exercise where each function mapped its responsibilities, so we could see where agents could take on work and where people needed to stay in charge.

Then we ran a pilot: two delivery teams took on their existing work with AI-native and AI-assisted methods, and I worked with a designer on each. The process that came out of it used Figma as a sketchbook, Claude Code to automate tickets and deliverables, our design system served over MCP for consistency, and a round trip back to Figma as the source of truth. The pilot teams measured about 2.2 times their usual throughput, with quality holding, against a target of 4x.

From there we started building agents for parts of the process: design review against the system and existing pages, research that draws on our library and requests new studies when it can’t answer, and content that applies the Pax8 voice for people to review. We were also designing a shared console for project status and parallel work. All of it was in progress when I left. In every case we defined the human checkpoints first: people set the direction, review what the agents produce, approve what comes next, and own the status.

The org I’d build next works this way from the start: designers lead the strategic thinking, and automation takes on more of the execution. The open problem is shared understanding. When everyone designs in their own prototype or branch of code, the work ends up in silos, and the team loses the common place where it could see the whole product and work on it together. That’s what I’m working on now.

Outside of work

I’ve loved space since I was a kid, when I watched the stars through a telescope with my dad. I also grew up on Star Trek, dreaming of the day we could talk to the computer and explore the universe. Talking to the computer came true, and now I design for it. Until exploring the universe does, I’m exploring this planet: 18 countries so far, and about 35 of the 50 states. And at home there’s Lusi, my cat, who is keeping an eye on you from the bottom of this page.