On UX Management
Learnings from five years in product leadership.
I started in product at a startup with about six other people. I didn’t have a manager or reports. We built, tested, and repeated. In March 2022, I moved into a leadership role in a larger org with no playbook for the role. I started with Andy Grove’s High Output Management, and one idea stuck: a manager’s output is their people's output. I read it twice during my first 30 days. Everything here is built on that.
I manage four designers directly, and I coach and direct the day-to-day work of four more across our ATS and design system teams.
On outcomes
A manager's value is the team's collective development. Career architecture is how to measure it. “Conversion” here is a report that consistently operates at the next level of their role definition, and it is easy to see when each role is defined by its responsibilities, competencies, influence, and behaviors. It also lets development conversations happen without anyone feeling attacked.
When I started my current role, none of that existed. I wrote the manager levels and, with our UX director, co-wrote the designer levels, mapping them to product and research roles. We leaned heavily on Intercom’s design team career architecture and tweaked it for our enterprise org. We piloted it in UX first because product’s roles were less formal than ours. Product later restructured its roles to the same level structure: Associate Product Manager, Product Manager, and Manager of Product, equivalent to UX Designer, Senior UX Designer, and UX Manager. UXR used the same levels to set autonomy, scope, and ownership expectations for our 2025 intern, who is now full-time!
What it looks like in practice. One designer pushed for a senior promotion. They were reliable, passionate, and opinionated, but they worked as an order taker. Our senior level expects active involvement in roadmapping and strategy conversations for their team, and that was the gap. Each conversation turned into “when will the promotion happen?”, so we kept returning to the level behaviors instead.
For a year, the designer set one goal per quarter: influence a product decision. They logged each decision, the alternatives, and who opposed it. That log became the evidence in their promotion case. At the end of the year they presented the product team with ten opportunities, small to large. That list is still part of the team’s planning discussions.
On work language
Yeah, like love language but for work. Understanding someone’s work language unlocks their best work. The four I see most:
Safety. We fail as a team, and a manager provides cover. A designer who worries about making a mistake, or saying something a higher-paid opinion might not like, won’t bring their best self (Maslow hierarchy of needs). I’ve had designers with brilliant ideas and strong storytelling who held back for exactly that reason. Their development plans can be direct and explicit. They thrive with clear goals and intended outcomes.
Quality time. These designers thrive on collaboration and experimentation. They invite criticism, challenge ideas, and need real-time validation and critique. They tend to excel in user research interactions like 1:1 interviews and shadow sessions. This is the designer I send in to put a participant at ease so we can observe real behaviors and struggles.
Acts of service. Sometimes a designer just needs something off their plate. I can take it, or help deprioritize it. They need a few hours uninterrupted in their domain.
Words of affirmation. I’ve had a designer who would rather I fire them than handle something from their to-do list. These people need recognition for their work, engaging and meaningful projects, and stretches of time to sit and untangle complex problems. Development plans can be less structured.
On decision-making
Decisions are the most common bottleneck for operations. Add subjective topics like layout or a hover interaction, and they can block a team entirely. Teams need a decision framework:
What does a good decision look like?
Which downside outcomes are we okay with, and which do we need to protect against?
When do we elevate a decision, and to whom?
Which role can make which decisions, and when do we need consensus?
Who needs to know about a decision once it’s made?
On vision
If you’re sick of restating the vision for the team, you’re probably on track. People have a hundred things on their minds, and they forget the deck you built at the start of Q1 by Valentine’s Day. Tell the story repeatedly, and understand how it affects the people around you. Vision is communicated every day, then worked backward tactically. Continuous delivery and discovery happen inside that path.
Uncertainty is certain. Strategy and vision mean planning for different outcomes, not sticking to a single plan.
On users
UX teaches us to obsess over users, those who experience the workflows we create. Yes, and… engineering is the user. Product is the user. Stakeholders are the users. Ironically, everyone except the end user consumes the artifacts that UX creates. Management builds the environment for design to communicate the value of the work to peers and stakeholders, and to empathize with the goals of all design consumers, not just the end user. Durable business value depends on user value.