The work I'm proudest of came from a team. This is how I try to lead one.
Culture comes from leadership. It's built day to day, in how you show up, not in a policy or a ritual.
My current team spans design, writing, development, and QA. Four disciplines, four sets of instincts about what "done" looks like, four different vocabularies for the same problem. What holds that together isn't a process document. It's whether people trust each other enough to say when something isn't working.
I'm always honest with my team, and I let them into my own life so they know there's room for theirs. In practice that means meeting people at their skill level, adapting to how each person works best, and respecting that they have outside lives.
People do their best work when they feel seen and supported where they actually are.
As the Veneer documentation team grew to 8–10 people, someone needed to own how the team actually worked, not just what it shipped. That responsibility fell to me.
I run the team's internal process end to end: leading sprint planning and retros, setting how work gets prioritized and tracked, and communicating our roadmap to the broader Veneer team so our work stays aligned with a design system used by 80+ projects across HP.
This isn't a one-time process I set up and left. Every sprint, I'm responsible for making sure a cross-functional team with genuinely different workflows has a shared rhythm and a roadmap the wider Veneer org can plan around.
I also defined the governance process for how the broader Veneer team requests new component documentation, submits feature requests, and contributes to global documentation, turning what used to be ad hoc asks into a process people can actually follow. And as one of 8 design leads across Veneer, I help influence decisions at the level of the whole design system, not just the documentation team.
The biggest risk on a cross-functional team usually isn't any individual's output. It's misalignment, which is why owning the process and the roadmap matters more than it might sound.
A design system only works if people know it exists and understand why it matters. A lot of that comes down to showing up and making the case, over and over, to audiences who don't already agree with you.
I presented a talk to roughly 300 attendees on the importance of design consistency in software, delivered to HP's Customer Experience organization. I also regularly present at Veneer Huddles, recurring sessions for the broader user community, covering the latest updates and answering questions about the website and documentation directly.
Our content strategist and I also published Design Systems: We Have a Naming Problem on HP Design's Medium publication, on user research showing that "Foundations", a label used across nearly every design system, doesn't mean anything to the people reading it.
The other half of advocacy happens closer to home. I speak up for my team when their time needs protecting, when a request would pull them off what actually matters, or when doing right by them means pushing back. I'm their biggest champion, and I want the people I work with to know that someone is making their case in the rooms they're not in.
Making the case for your own team is the advocacy that matters most to the people doing the work.
Want to see what this looks like in practice?
See my work →