If you’ve been in the design field for any length of time, you’ve probably experienced a particular kind of frustration.

People are solving for the wrong problem. They’re optimising for metrics that don’t matter. They’re ignoring systemic issues in favour of quick fixes. They’re talking past each other, using the same words to mean different things. They’re debating solutions without agreeing on the problem. They’re making assumptions without testing them.

You want to intervene, to reframe, to redirect. You can see the pattern they’re missing. You can see the question they should be asking. You can see the framework that would clarify everything. But there’s this nagging doubt: ‘Is it my place? I’m just the designer.’

Here’s what you need to understand: the skills that allow you to see what’s going wrong in that meeting (the pattern recognition, the systems thinking, the ability to synthesise complexity) are leadership skills. And they’re skills that often times, most people in that room, regardless of their title, don’t have.

This chapter explores a provocative idea. Designers are advantaged in organisational leadership, not disadvantaged. Our core practice develops the capabilities that effective leadership requires.

Example: The Product Roadmap Meeting

At a SaaS company serving small businesses, the executive team gathered for their quarterly roadmap planning. They had three hours to decide which features to prioritise for Q2. The atmosphere was tense. The previous quarter had seen declining growth. Churn was up. New signups were flat. Competitors were gaining ground. Something needed to change.

The Head of Sales, David, wanted CRM integrations. He came prepared with data. He showed that 40% of lost deals in Q1 cited lack of CRM integration as a reason. Prospects wanted the product to sync with Salesforce, HubSpot, and Pipedrive. Without these integrations, the sales team had to manually export data and import it into CRMs. Prospects saw this as a dealbreaker. David’s pitch was compelling: ‘We’re losing £200,000 in ARR every quarter because we can’t integrate with the tools our customers already use.’

The Head of Customer Success, Rachel, wanted better onboarding analytics. She had her own data. She showed that companies with poor onboarding scores (measured by feature adoption in the first 30 days) had 3x higher churn rates. But the team had no visibility into which users were struggling. By the time they noticed someone wasn’t engaging, it was too late to intervene. Rachel’s pitch was equally compelling: ‘We’re losing customers we’ve already won because we can’t identify and help struggling users in time.’

The CTO, Michael, wanted to rebuild the notification system. The current system was causing 60% of production incidents. It was built three years ago when the company had 100 customers. Now they had 10,000. The architecture couldn’t scale. Notifications were delayed, sometimes by hours. Users complained about missing critical alerts. The engineering team spent half their time firefighting notification issues instead of building new features. Michael’s pitch was urgent: ‘We can’t ship anything reliably until we fix this technical debt.’

All true. All important. All backed by solid evidence. Two hours in, they were stuck. The data seemed to support all three priorities equally. The discussion was going in circles. Each executive defended their priority with increasingly forceful arguments. Tension was rising. People were starting to talk over each other. The CFO kept asking ‘but which one actually moves revenue?’ Nobody had a clear answer that everyone could agree on.

Elena, a senior product designer, had been quietly observing. She wasn’t supposed to speak in executive meetings. She was only there to take notes for the design team so they’d know what to prepare for next quarter. This was her third quarterly planning meeting. The previous two had gone the same way: hours of debate, eventual compromise that left everyone slightly unhappy, priorities that changed again within weeks when new data emerged.

But Elena saw something the executives were missing. All three proposed features were symptoms of the same underlying problem. The product’s value proposition wasn’t clear to new users. They didn’t understand what the product did or why it mattered within the first week.

Sales needed CRM integration because users didn’t understand the product’s value quickly enough to commit without extensive hand-holding from sales reps. The sales team had to schedule multiple demos, create custom presentations, and walk prospects through every feature. This was time-consuming and didn’t scale. If the product’s value were obvious, prospects could self-serve.

Customer Success needed analytics because they couldn’t identify which users were struggling to see value. Users would sign up, poke around for a few days, not understand how to get value, and churn. By the time Customer Success reached out, the user had already mentally checked out. If the product made its value obvious upfront, users wouldn’t struggle silently.

Engineering needed better notifications because users weren’t engaging with the core features that would demonstrate value. They’d set up their account but never complete the workflows that would make the product indispensable. Notifications were supposed to re-engage them, but better notifications wouldn’t help if users didn’t understand why they should care in the first place.

Elena did something risky. She interrupted. ‘Can I share an observation?’ The room went quiet. The CEO, who’d been mediating the increasingly heated discussion, looked surprised but nodded. ‘Sure, go ahead.’

Elena stood and walked to the whiteboard. She drew three columns and labelled them ‘CRM Integration,’ ‘Onboarding Analytics,’ and ‘Notification Rebuild.’ Under each, she wrote what problem that feature was really trying to solve, based on the discussions she’d been hearing:

• CRM Integration: Users don’t understand value quickly enough for self-serve sales
• Onboarding Analytics: We can’t identify users who don’t understand value
• Notification Rebuild: Users don’t engage with features that would show value

She stepped back. ‘They all say the same thing. Users don’t understand the core value proposition within the first week. What if, instead of building three separate features that work around this problem, we focus on fixing the actual problem?’

She continued. ‘We could redesign the first-week experience to make the core value obvious. Run a design sprint next week with representatives from sales, customer success, and product. Prototype the new experience. Test it with 20 new signups the week after. Have validated solutions in three weeks. Compare that to three months of building features that might not solve the underlying issue.’

The room went quiet. People were looking at the whiteboard. David, the Head of Sales, broke the silence. ‘That’s actually true. Our top performing sales reps all do the same thing. They spend the first call just showing prospects the one core workflow that proves the product is valuable. Once prospects get that, everything else is easy. New reps try to show everything, and prospects get overwhelmed.’

Rachel, the Head of Customer Success, nodded. ‘Same with our customers who stick around. They all have one thing in common. They figured out the core use case in the first week. The ones who churn are the ones who signed up but never completed that core workflow. They’re just clicking around randomly.’

The CEO sat forwards. ‘Elena, you’ve been doing user research. What do users actually need to understand in that first week?’

Elena had anticipated this. She pulled up a synthesis document she’d created from her research. ‘Three things. First, what specific problem does this solve for me. Not what the product does, but what it does for me specifically. Second, how do I get my first win. What’s the shortest path to seeing value. Third, what happens next. Once I’ve seen that value, how do I build on it. Most users never get past step one because we assume they already know why they’re here.’

The CEO looked at the other executives. ‘This makes sense. If we solve the core value communication problem, does it address your concerns?’ Everyone nodded, some reluctantly but they all nodded. The decision was made. Q2 would focus on redesigning the first-week experience.

Three weeks later, the company had a completely redesigned onboarding flow. They tested it with 50 new signups, split testing the old experience against the new one. The results were dramatic. Activation rates (users who completed the core workflow in week one) went from 34% to 61%. Self-serve sales conversion improved by 28% because prospects could try the product and immediately understand its value. Customer Success ticket volume dropped by 41% because users weren’t confused about what to do. Engineering’s notification system issues decreased because users were actually engaging with the features that mattered.

One intervention. Three weeks. Solved all three problems better than three separate feature builds would have. And it came from a designer who ‘just took notes’ in executive meetings.

Six months later, Elena was promoted to Principal Designer with explicit responsibility for strategic product direction. But more importantly, she’d demonstrated something crucial. Design thinking isn’t separate from strategic thinking. It is strategic thinking.

This is the designer’s advantage. You’re not attached to any particular solution or defending any departmental interest. You can see the real problem because you’re trained to look for it.

Design Thinking as Leadership Thinking

Strip away the buzzwords and corporate workshops, and design thinking is fundamentally a problem-solving methodology built on a few core principles:

• Start with deep understanding of people and context
• Define the right problem before solving it
• Generate multiple possibilities before converging
• Make ideas tangible to test assumptions
• Iterate based on feedback

Now consider what effective leadership requires:

• Understanding the people you’re trying to move and the environment they’re operating in
• Identifying the actual challenge, not just surface symptoms
• Exploring strategic options before committing to a path
• Communicating vision in ways people can grasp
• Adapting based on results

These are the same capabilities. Design thinking is leadership thinking applied to product development. Which means when you practice design, you’re practicing leadership.

Elena’s intervention at the roadmap meeting wasn’t about design in the traditional sense. She didn’t talk about interfaces or user flows or visual design. She talked about problem framing. She synthesised three complex discussions into one clear insight. She reframed the conversation at a higher level of abstraction. She proposed a solution that aligned everyone’s interests. This is what leaders do.

But she could only do it because of her design training. Designers are taught to dig beneath surface requirements to understand underlying needs. We’re taught to question whether the brief is actually asking for the right thing. We’re taught to spot patterns across disparate data points. We’re taught to make complex trade-offs visible so groups can make better decisions. We’re taught to synthesise complexity into clarity.

These skills transfer directly to organisational leadership. When executives are debating three different priorities, they need someone who can identify the common thread. When teams are stuck in implementation details, they need someone who can step back and question the framing. When stakeholders have competing interests, they need someone who can find the alignment. Designers do this naturally because it’s core to our practice.

The Five Leadership Capabilities Designers Develop

Let’s be specific about the leadership capabilities that design practice builds. They’re the fundamental mechanisms through which leadership actually happens. They’re the core competencies that determine whether you can move groups towards better outcomes.

1. Empathy: Understanding People Deeply

Every designer knows that empathy is foundational to the practice. You can’t design good experiences without understanding users. Their mental models, their contexts, their needs, their pain points, their constraints, their goals, their fears, their aspirations.

But empathy is equally foundational to leadership. You can’t move people towards a vision if you don’t understand what motivates them, what they fear, what they value, what constraints they’re operating under, what success looks like from their perspective, what would make them feel threatened by change.

What makes designer empathy particularly powerful is that it’s methodological, not just emotional. You’re trained to go beyond assumptions and intuition. You do actual research. You develop frameworks for understanding different user segments. You separate what people say from what they do. You identify unspoken needs through observation. You create models of user behaviour based on evidence, not guesswork.

These same techniques apply to understanding stakeholders, teammates, and organisational dynamics. When you conduct user interviews, you’re practicing the same skill you need to understand a resistant stakeholder. When you create personas, you’re practicing the same segmentation thinking you need to tailor messages to different audiences. When you map user journeys, you’re practicing the same systems thinking you need to understand how decisions flow through an organisation.

Elena’s roadmap intervention worked because she understood each executive’s perspective deeply. She knew David, the Head of Sales, cared about deal velocity and sales efficiency. She knew Rachel, the Head of Customer Success, cared about retention metrics and team capacity. She knew Michael, the CTO, cared about system stability and engineering productivity. Her solution addressed all three concerns because she’d taken time to understand what each person actually cared about, not just what they said they wanted.

This is empathy as a strategic tool. Listening isn’t just about being nice or making people feel heard (though those matter). It’s about gathering the intelligence you need to craft solutions that multiple stakeholders will support. It’s about understanding the hidden constraints and unstated fears that drive behaviour. It’s about seeing the system from multiple perspectives simultaneously.

2. Synthesis: Making Sense of Complexity

One of the most underrated designer skills is synthesis. The ability to take disparate, messy information and distil it into coherent insights. After user research, you don’t just present raw data. You synthesise findings into themes, patterns, and implications. You connect dots that others miss. You create frameworks that organise complexity. You extract signal from noise.

This is a core leadership capability. Leaders constantly face information overload. Conflicting priorities, incomplete data, competing perspectives, ambiguous situations, fast-changing contexts, multiple stakeholders with different views. The ability to synthesise this complexity into clarity is what allows groups to make progress.

Think about the last time you were in a confused meeting where everyone was talking past each other. What that situation needed was synthesis. Someone to step back, identify the underlying dimensions of disagreement, create a framework that helped everyone see the same picture. The situation needed more synthesis than it needed more information or more opinions.

Designers do this constantly. It’s such a natural part of our practice that we often don’t recognise it as leadership. But it is. When you’re the person who can take three hours of rambling discussion and summarise it into three clear options with trade-offs, you’re leading. When you can look at months of research data and identify the two insights that actually matter, you’re leading. When you can translate technical constraints into user impact, you’re leading.

Elena’s whiteboard moment was synthesis in action. She took three complex proposals with extensive supporting data and reduced them to their essence: they’re all trying to solve the same problem. That clarity allowed the group to make a decision they couldn’t make when drowning in detail. She found the pattern that connected everything.

The power of synthesis is that it creates leverage. When you can make complex things simple, you make decisions easier. When you can show how seemingly unrelated problems are actually connected, you open up solutions that weren’t visible before. When you can articulate what everyone is thinking but nobody has said clearly, you give the group permission to move forwards.

3. Facilitation: Moving Groups Forwards

Design is inherently collaborative. You’re constantly facilitating. Running workshops, leading critiques, guiding ideation sessions, mediating between stakeholders. You’ve learnt how to structure conversations, manage group dynamics, draw out quieter voices, redirect unproductive discussions, and drive towards decisions.

Facilitation is leadership in action. When you run a design sprint, you’re creating an environment where a group can do their best thinking together. When you lead a critique, you’re establishing the conditions for productive feedback. When you mediate between product and engineering, you’re helping them find alignment they couldn’t reach alone.

The best facilitators create space for others to contribute. They ask questions that unlock new thinking. They redirect energy when discussions get stuck. They know when to let conversations breathe and when to push for closure. They lead from the side, enabling rather than dominating.

This is what adaptive leadership looks like. The traditional model of leadership is the person at the front of the room telling everyone what to do. But that model fails in knowledge work, where the best answers come from collective intelligence rather than individual genius. Modern leadership is more about creating the conditions for good decisions than making all the decisions yourself.

Designers are natural facilitators because we have to be. You can’t design in a vacuum. You need input from users, engineers, product managers, customer support, sales, marketing. You need to synthesise diverse perspectives into coherent solutions. You need to build consensus without having authority to mandate it.

These facilitation muscles you’ve developed transfer directly to organisational leadership. The same skills you use to run a productive design critique can be used to facilitate a strategic planning session. The same techniques you use to align stakeholders on a feature can be used to align executives on company direction. The same questions you ask to clarify user needs can be used to clarify strategic priorities.

4. Systems Thinking: Seeing Connections

Good designers think in systems. You understand that every interface is part of a larger experience. Every interaction has upstream causes and downstream effects. Every design decision ripples through the product ecosystem. You can’t optimise one part without considering its impact on the whole.

This systems perspective is crucial for leadership. Most organisational problems are symptoms of systemic issues, not isolated incidents. The team that consistently misses deadlines might have an unclear prioritisation process rather than a time management problem. The feature that users don’t adopt might be solving the wrong problem rather than needing better marketing. The support team that’s overwhelmed might be receiving poor handoffs from product rather than being understaffed.

Leaders who can see systems (who can trace problems to their roots, anticipate second-order effects, design interventions that address causes rather than symptoms) are dramatically more effective than those who only see surface issues. They solve problems once instead of repeatedly. They prevent issues instead of just reacting to them.

As a designer, you’re trained to think this way. You know how to map systems. You know how to identify leverage points. You know how to intervene strategically. You understand that changing one element requires considering all the elements it connects to. These skills transfer directly to organisational leadership.

Elena’s insight about the three features was systems thinking. She saw that CRM integration, onboarding analytics, and notification improvements were all downstream effects of an upstream problem: users not understanding the value proposition. Solving the upstream problem solved all three downstream issues. This is systems thinking applied to strategy.

5. Communication Through Making: Showing, Not Just Telling

Designers have a unique advantage in communication: we make things. We don’t just describe ideas. We prototype them, visualise them, make them tangible. We show more than we tell.

This ability to communicate through artefacts is a powerful form of leadership. When you create a prototype, you’re creating a shared reference point that aligns understanding. When you visualise a process, you make invisible dynamics visible. When you storyboard a user journey, you make an abstract experience concrete.

Words are slippery. People can nod along to the same description whilst imagining completely different things. But artefacts create shared understanding. They turn abstract discussions into concrete conversations. They move groups from debate to decision. They make assumptions visible and testable.

This is why design artefacts often have disproportionate influence in organisations. A well-crafted prototype can shift a strategic conversation more effectively than a dozen PowerPoint decks. A clear service blueprint can resolve stakeholder disagreements that have festered for months. A simple diagram can clarify a complex system better than pages of documentation. Making is a form of leading.

When Elena drew three columns on the whiteboard, she was using this capability. She made the pattern visible. She created a shared artefact that everyone could reference. The conversation shifted from abstract debate about priorities to concrete discussion about the underlying problem. The whiteboard made her thinking visible and allowed others to build on it.

Why Formal Leaders Often Lack These Capabilities

Here’s an uncomfortable truth: many people in formal leadership positions never developed the capabilities we’ve just described. They were promoted for their technical expertise, their tenure, their relationships, or their ability to execute within their function. They were promoted for reasons other than their ability to empathise, synthesise, facilitate, think systemically, or communicate through artefacts.

This creates a gap. Organisations need leaders who can navigate complexity, build alignment, and drive collaborative problem-solving. But many people with ‘leader’ in their title were never trained in these capabilities. They know how to manage budgets, set goals, and hold people accountable. They don’t know how to facilitate difficult conversations, synthesise ambiguous information, or help groups make sense of complexity.

Designers, on the other hand, are trained in exactly these capabilities from day one. Every design programme, every design role, every design project develops these skills. You might lack the title, but you have the toolkit. You might lack the formal authority, but you have the practical capabilities. You might not be invited to lead, but you can lead anyway.

This is your advantage. And once you recognise it, you can leverage it deliberately.