How I lead
I don't always have the official title. I don't always even have the authority. But I've noticed a pattern in my work: I tend to show up in spaces where people are still figuring things out, and I leave them with something more structured than when I found them.
People who've worked with me describe it in different ways. A Customer Success lead said I take complex, technical topics and distill them into easy-to-understand language, visuals, and analogies. A Design Manager said I turn ambiguous problems into crisp, high-impact guidance. A Content Designer said I help people see the shape of the forest.
What they're all pointing at is the same thing: I don't just solve a problem. I try to solve the category of problem. Here are a few recent examples.
Within my team
When I started designing the Employee Self-Service (ESS) agent, there was no shared framework for how to approach designing an agent in our studio. Different, and sometimes unknown teams, were making various decisions about agent identity, behavior, and context without considering the human experience.
I ran three working sessions with my team to change that. Together, we mapped five agents across three dimensions: identity, core behaviors, and knowledge and context. The questions were simple. The decisions behind them were not. What qualities and behaviors does this agent need to demonstrate to reach its value proposition? What should it always do? What should it never do? What does it need to know?
By the time we finished, the team had a framework they didn't have before. Content Designers on my team said it helped them get clearer on the decisions they needed to make and the questions they needed to ask. One colleague described it as turning something we'd been guessing at into something we could actually trust to make decisions.
That's the goal — not to come up with all the answers myself, but to create the conditions where others can find them and own them.
In my discipline
Content Designers working with AI face a real problem: their expertise is harder to see, harder to scale, and harder to hand off than it's ever been. The work is increasingly embedded in systems (in prompts, in evaluation rubrics, in model behavior) and the organization is still catching up to what that means.
One effort that's driving the evolution of content design at Microsoft is a language system project. I drove the strategy for two core pillars of the language system - evaluations and prompt engineering. Starting with a brainstorm that identified the four biggest challenges content designers face in AI work, I built a Jobs To Be Done framework organized around two questions: how do we consistently shape model behavior through prompt engineering, and how do we evaluate output quality as models and products evolve?
A Content Design manager described what I was doing as systematizing a probabilistic experience by taking something that felt impossible to make consistent and giving it structure. That's exactly what I was trying to do.
To validate the strategy, I ran a workshop with 40+ content designers at the company. The response confirmed the direction and did something more valuable: it surfaced the subject matter experts who would help write the guidance.
The language system is currently being built and tested, and is expected to launch later this summer,
A thumbs up reaction means CDs agree it's needed. A +1 reaction means they are also working on these kinds of tasks. This helped us prioritize and find subject matter experts.
Across the design community
I was nominated to be part of the leadership committee that organizes Microsoft Design Week, the largest internal celebration of design culture at the company. I owned the event portal work stream which includes the website, the content architecture, the attendee experience, and the CMS effort that got 150 speaker profiles and 75 session entries live before the event opened.
There was no hierarchy. No one told me what to do or held me accountable if I didn't. The only way to move things forward was to earn trust, stay organized, and keep showing up.
Attendees noticed too, not just that the event was good, but that they could feel the community coming together. That they left with things they could use in their work and their careers. Those outcomes don't happen by accident. They happen when someone treats the infrastructure as seriously as the content.
The portal was reused the following year. The community the portal helped build is still active.
The pattern of leadership
When I look at these three examples of practicing leadership, I see the themes: an ambiguous space, a missing framework, and a group of people who needed to operate with more clarity than the organization had given them.
My instinct is this: understand the problem, build the structure, teach people to use it, and make sure it doesn't leave with me.
I think what people comment on the most about my leadership style is that I'm not trying to be the answer. I'm trying to make sure the answer exists, is documented, is teachable, and outlasts my involvement.