UX Leadership

How to get your team in the room before decisions are made

Key Takeaways

UX teams lose influence not because of bad design – but because they’re involved too late, stay too quiet, and lead with control instead of trust. Changing that is mostly a leadership problem, not a craft problem.

I’ve worked with a lot of UX teams over the years. Some were genuinely excellent designers. Thoughtful researchers. People who understood users in ways that should have made them indispensable.

And yet, in meeting after meeting, their work arrived too late to change anything. Decisions had been made. Roadmaps locked. All that was left was putting a nicer face on something that probably shouldn’t have been built the way it was.

That’s not a craft failure. It’s a visibility and positioning problem. And fixing it falls on whoever leads the team.

I’ve thought about this kind of leadership since long before I worked in UX. I started playing basketball in 1994 – streetball first, then different clubs, league games, and at times coaching younger players over three decades. Along the way I watched a lot of teams be led badly: training styles that produced players who technically did what they were told and had quietly stopped wanting to improve. The best coaches I saw – and the approach I tried to carry into my own work with younger players – had one thing in common. They didn’t push people toward a goal. They made people want to get there themselves.

The UI Executor Trap

There’s a specific version of this I call the UI executor trap. UX gets brought in close to release – sometimes days before – and asked to review decisions that were made months ago. The brief is basically: can you make this look better without touching anything that would require more dev time?

That’s not UX. That’s graphic design with extra anxiety.

This dynamic has a parallel in basketball. When streetball culture started influencing the professional game, the formal structure resisted it. The style was too individual, too unpredictable – it didn’t fit the system. Then players like Allen Iverson – “The Answer” showed what those skills could actually do at the highest level, and the game changed permanently. Moves that were dismissed as ‘street’ became competitive advantages inside a structured team sport. UX is in a similar position in many organisations right now. Fast, creative methods – a one-day user interview, a rough prototype tested on five people, qualitative insight gathered before the roadmap locks – still get dismissed as ‘not rigorous enough.’ They earn their place the same way: by delivering results the slower, more formal approach doesn’t.

The trap forms gradually. An organisation that doesn’t really understand what UX is for uses the team for what it can see: deliverables, screens, visual polish. The team, trying to be helpful, provides those things. And over time, that’s what the relationship becomes. A service. Not a strategic function.

Breaking out of it requires being honest about what’s happening – and doing something about it before it gets comfortable.

If UX only arrives when the wireframes are due, the real decisions have already been made without you.

Get in the Room Earlier

The single highest-use thing a UX leader can do is move their team upstream.

Not to the sprint. Not to the design review. To the scoping phase – where problems are still being defined, where “do we even need to build this?” is still a valid question, where the shape of a solution hasn’t yet been assumed by a product manager who started their deck three weeks ago.

Getting there requires political work as much as design work. Building relationships before you’re needed. Showing up in planning conversations as a curious contributor, not just when there’s a design request attached. Making the cost of late UX involvement concrete rather than abstract – which means having a specific example, ideally from within the organisation, of what it cost to get UX involved on day 40 instead of day 4.

How early you can realistically get involved depends on the organisation’s UX maturity. In lower-maturity environments, the seat at the scoping table has to be earned, one relationship at a time. That’s slow work. But it’s the work.

Visibility Doesn’t Happen by Itself

Good work that nobody sees doesn’t build influence. And UX work is particularly prone to invisibility – research findings sit in a report, usability results get presented to the project team once and then archived, insights that should change the product direction disappear into a Confluence page nobody opens again.

Making impact visible is a leadership responsibility. Not vanity – professional responsibility.

That means sharing research findings beyond the project team. Presenting usability results in all-hands, not just in design reviews. Translating UX metrics into terms that land with stakeholders: not “users were confused at step three,” but “we’re losing 28% of users at the step before checkout – here’s why and here’s what we’d need to fix it.”

The framing matters. Design teams that speak in design language stay in design conversations. Teams that speak in outcomes get invited to business conversations.

Lead with Trust, Not Control

The last thing, and maybe the most important one.

A UX team where the lead controls every major decision isn’t a high-performing team. It’s a bottleneck with good taste.

The teams I’ve seen do their best work are ones where the lead has created the conditions for other people to make good decisions independently. Clear principles. Shared understanding of what “good” looks like. Enough psychological safety that someone can say “I’m not sure this is the right direction” without it feeling like a career risk.

That requires a specific kind of restraint. Letting work go out that you’d have done slightly differently. Coaching instead of correcting. Asking “what do you think?” before giving your own view.

I learned an early version of this on a basketball court. In streetball – 1v1, 2v2, 3v3 – individual skills develop fast because there’s no team structure to fall back on. Every gap is immediately visible. But I also watched how quickly people shut down when feedback came as criticism rather than as a next step. The players who improved fastest weren’t the ones who got corrected the most. They were the ones who were shown what they were already capable of – and then given room to go further. A designer who feels seen develops faster than one who feels monitored. The feedback that lands is the feedback that makes someone want to do better – not the feedback that tells them they weren’t good enough.

Something I noticed on streetball courts over the years: the players who earned the most respect weren’t the ones with the most attitude. They were the ones who clearly had real skills – and then treated everyone as an equal anyway. No posturing. No making others feel lesser. That combination made people curious. They started wanting to learn, not because they were told to, but because they’d seen something worth understanding and felt safe enough to ask. Hold your expertise without holding it over anyone – and people will come to you.

The moment you place your skills above someone else’s, you lose them.

Trust compounds. A team that’s trusted to make decisions gets better at making them. A team that’s constantly waiting for approval gets slower and less confident. Choose which one you want, and then lead accordingly.

Where UX Leadership Is Heading

Two data points from the OCTO 2026 Design Outlook worth knowing.

First: nearly 30% of senior UX leaders now report directly to the CEO. That’s not a coincidence – it reflects a structural shift in how organisations are treating user experience as a strategic function rather than a design sub-team. It also means the leadership skills that matter most are no longer about managing designers. They’re about operating at the executive level: translating UX findings into business risk, influencing roadmap decisions, and holding the line on user quality in conversations where the default is to move faster and worry about the experience later.

Second: AI fluency is becoming a leadership requirement, not a personal interest. UX leaders who understand how AI systems work – not at the engineering level, but at the level of what they optimise for, how they fail, and what they can’t replace – are better positioned to set direction for their teams and speak credibly in product strategy conversations. This isn’t about learning to prompt. It’s about understanding enough to ask the right questions.

What to Do Next

1. Create one visibility moment this month. Share a research finding, a usability result, or a team win in a meeting beyond your immediate team – in business language, not UX language.
2. Ask your team for feedback on your leadership – and mean it. A short, informal conversation is enough to start. The signal you send by asking matters as much as what you hear.
3. Identify one stakeholder relationship worth investing in. Not the most senior one, but the one where early trust would open the most doors for UX involvement upstream.

Sources & Further Reading

• UX Stakeholder Engagement 101 – Nielsen Norman Group
• UXers Need to Think Like Product Leaders – Nielsen Norman Group
• Rethinking the Role of Your UX Teams – Smashing Magazine
• How to Become a UX Leader – Smashing Magazine

René Manikofski is a Senior UX Designer with 10+ years of experience in e-commerce and digital product design across Europe. All articles are based on personal professional experience and supported by AI in writing.