How I Work

I work best in environments that value clarity, trust, and long-term thinking over constant urgency. My approach sits at the intersection of front-end engineering, accessibility, and systems thinking — with an emphasis on work that remains understandable and maintainable over time.

The basics

Primarily remote, happy to go into the office a day or two a week. I often have headphones on — always feel free to interrupt, I’m never not happy to chat.

I can be my own worst critic, and when things aren’t sitting right I’ll sometimes go quiet rather than say so. Don’t take it personally. If something’s off, it’s better to ask.

I’m a dad, which means there are occasional hard stops in the afternoon. I’m always available async, and I’ll always make my time up.

What I prefer

• Fewer meetings, clearer decisions
• Being prepared — for projects, for meetings, for conversations
• Pairing over mobbing; space to think over constant interruption
• Writing things down
• A clear answer to “why are we doing this”

How I collaborate

I work well across disciplines. I can talk to designers about implementation constraints without dismissing their intent, and I can talk to engineers about design decisions without losing the thread of what actually needs to be built.

I’m direct. I’ll tell you when I think something’s wrong, and I’ll try to explain why rather than just asserting it. I’d rather have a productive disagreement early than a quiet consensus that falls apart later.

I take documentation seriously — not as a bureaucratic obligation, but as a tool for building shared understanding and reducing the bus factor on decisions that should outlast any one person.

Workshops are my thing. If you’re running one, get me involved. If I’m running one, get stuck in.

Feedback

Face to face is best, or a call if not. Any format works — so long as it’s timely and specific. Vague feedback is hard to act on.

What I’m not

I’m not a full-stack generalist. I have opinions about backends and I’ll share them, but building them isn’t where I operate.

I’m not interested in complexity for its own sake. If the simple thing works, we should do the simple thing.

I don’t thrive in environments that mistake motion for progress — where the calendar is always full but the direction is always shifting. Too many video calls, too much context switching, too little room to actually think — that’s where I start to struggle.

Working patterns

I tend to be most effective in the mornings and again in the late afternoon. Midday is where my focus drifts. Async suits me well — I’ll read and reply at odd hours, but there’s never any expectation of a reply outside yours.

My superpowers

Proper front-end — HTML, CSS, the platform. Accessibility and inclusive design. Bridging the gap between design intent and engineering output. The unsexy infrastructure work that determines whether everything built on top of it holds together — naming conventions, token architecture, contribution models. I do some of my best work on the things nobody else wants to look at.