I've led design across global teams, mentored designers at every career stage, and built the structures — onboarding programs, career tracks, contribution frameworks — that make teams better after I'm in the room and when I'm not.
I think of leadership as infrastructure: put the right structures in place and the team ships better work with less friction, even without you in every room. That means onboarding programs that ramp designers in days instead of weeks, career tracks that give people a clear path rather than a vague promise, and contribution models that turn individual expertise into team-level capability.
I established design-engineering pairing practices that cut handoff friction and improved implementation quality. I'm in the room from ideation to ship — in the Figma file during PR review, not emailing a PDF after the sprint.
I built onboarding programs that reduced ramp time for new design hires. New designers should be productive in their first week, not spending it reverse-engineering decisions made six sprints ago.
I helped establish both individual contributor and management career tracks — so a designer who wants to go deep on craft has a path that doesn't dead-end, and a designer who wants to lead teams isn't pressured into management before they're ready.
When Orbit was required across 6 teams, I didn't treat that as a rollout problem. I ran weekly design reviews during each team's onboarding, tracked adoption as a signal of where the system needed to grow, and built a contribution pathway so teams felt invested — not subjected to something built without them.
I've mentored designers across career levels — in systems thinking, stakeholder communication, and technical depth. Here's what that actually looked like in practice.
Story 1 — Technical credibility
Before: A mid-level designer was getting consistent pushback in engineering reviews — not because their designs were wrong, but because they couldn't speak to edge cases, states, or token decisions. Engineers were filling in gaps themselves, and the implemented product kept drifting from intent.
After: We worked on how they specced components — every state documented, token references visible in the handoff file, error and empty states non-negotiable. Within two sprints, engineering review became a conversation instead of a correction session. That designer was promoted to senior six months later.
Story 2 — Stakeholder communication
Before: A junior designer was designing good interfaces but couldn't get traction in reviews. Their work was presented as a finished artifact — "here's what I made" — with no framing of the problem, the decision points, or what they'd ruled out.
After: I coached them to lead reviews with the problem statement, walk through two or three considered directions, and arrive at a recommendation — not a reveal. Reviews stopped being approval sessions and started being alignment conversations. They started getting buy-in on the first pass instead of the third.
Story 3 — Career path clarity
Before: A senior designer was being nudged toward a team lead role they weren't sure they wanted. They were deeply effective as an IC — principled, systematic, fast — and worried that taking a management path meant leaving the craft behind.
After: We worked through what the IC track actually looked like at senior and principal levels — the influence, the scope, the kind of craft it required — and they chose to stay IC with a clear sense of what growing meant. They stopped hedging and started owning the direction of their work.
I also mentor on ADPList — 1:1 sessions on portfolio strategy, career transitions, and navigating enterprise product design. Book a session
Most of my work is in enterprise products where one bad pattern creates a hundred downstream problems. The thing I look for first isn't "does this screen work" — it's "what decision does this encode, and what happens when we apply it everywhere."
That applies to components, to onboarding programs, to career tracks, to governance models. The question is always: does this scale, and what happens when it breaks?
6 teams
Across 8 countries using Orbit
8+
Designers mentored across career levels
2 tracks
IC and management paths established
Clarity is the job.
Enterprise AI products fail users when they're technically correct but cognitively overwhelming. My job is to take something that's genuinely complex and make it feel navigable — not by hiding the complexity, but by structuring it so it doesn't hit all at once.
Good design is in the states you didn't show in the mockup.
Empty states, error states, loading states, disabled states — these are where the product earns or loses user trust. If it's not specced, it's not designed.
A spec nobody implements is not a design.
I'm embedded with engineering because the work isn't done when I hand off a Figma file. It's done when the right thing ships. That means I care about what's practical, not just what's ideal.
Mentoring is leadership work, not a side activity.
The designers I've worked with are better — at writing specs, at running reviews, at building careers — because we invested real time in it. Making the people around me better is as important as the product I'm shipping.
Structure enables speed.
Design systems, contribution models, onboarding programs — these feel like overhead until they're in place. Then they're the reason teams can ship in days what used to take weeks.
Measure what you design.
I track adoption rates, handoff friction, ramp time for new hires. Design decisions are hypotheses. You don't know if they worked until you look.
The Orbit case study shows how I built, governed, and scaled a design system across a global organisation.