Why growing your design team doesn’t grow your impact

Every January, I see design leaders put together similar plans for the year ahead. More Impact. More strategic influence. Happier Teams. Maybe more headcount.

I’ve helped clients do this, and I’ve done it myself. I’ve written those business cases, made those arguments, genuinely believed that this would be the year things changed. And sometimes the headcount came through. But the problems I was trying to solve? They often persisted anyway.

Looking back at previous years, we’ve probably all tried setting some of these ambitions before. The team grew, but the impact didn’t grow proportionally. We’re still firefighting, still stretched across too many projects, still watching research insights gather dust. Still explaining design’s value in terms that don’t quite land with leadership.

This year, before planning what to do, I want us all to explore a different question: how does design capability actually function as a system? And what happens when parts of that system are missing or weak?

The scaling paradox

A diagram of a bar chart showing progression of design maturity, with it increasing over time. The left-most and lowest bar is “non-existent”, followed by “Design as visual polish”, “Design as a process”, Design as a capability”, and finally “design as strategy”, with each increasing compared to the previous.

You’ve probably seen diagrams about design maturity that look something like this, where you progress up a clear pathway to become a more mature design organisation.

When trying to develop a design capability, many organisations treat design like other business functions. Need more output? Add more people with the right skills. It works for sales teams and call centres, so why not design?

But design leaders and teams keep running into the same wall: the team grows, but the same problems persist.

Researchers generate insights that never reach decision-makers. Designers are stretched across projects with inconsistent ways of working, lurching from one urgent request to the next. Leadership sees design as a cost centre, something that makes things look nice, not a strategic asset that shapes what gets built and why. Designers feel reactive, not proactive, executing on decisions that were made without them.

Moving from “Design as a Capability” to “Design as Strategy” isn’t just about the people doing the work. It’s about how those people connect to each other, to the rest of the organisation, and to the strategic decisions that shape what gets built. The organisation and the design function are two sides of the same coin. You can’t fix one without understanding the other.

A different way to see the problem

Stafford Beer’s Viable System Model has heavily influenced how I think about organisations. It describes how any system, whether a whole organisation or just a function within it, needs to work to be effective and adaptable. Beer developed it in the 1970s for “organisational cybernetics”, but it maps surprisingly well onto the challenges design leaders face today.

The core idea: an organisation isn’t a single unit, but a collective of teams and people with their own goals that need to collaborate effectively so that the organisation can deliver today, while adapting to tomorrow.

When one of these functions is weak or missing, the whole system struggles. And in many design orgs, at least one of them is.

I could go into a lot of detail on how this works and what it means for designers and design teams, but today I want to provide a bit of an introduction, explain what it reveals about where your capability might be falling short, and how you can set your teams up for success.

I’ll be sharing more details in future posts, but if you want to start diving into the model in more detail in your own time, there’s a lot of material online and you can find a nice introduction on youtube here.

Five functions your design capability needs

A diagram that outlines the different systems within the viable system model and how they connect to each other. This is explained at a high-level below.

Before we walk through these, there’s one key thing to keep in mind: these are functions , not teams.

It’s tempting to read about a function and think “we need a team for that.” But that’s not how this works. Each function might be performed by multiple teams, or spread across roles, or partly owned by people outside design entirely. “Direction setting” might involve your C-suite, a strategy team, a transformation team, and your own design leadership all contributing. “Setting Operational standards” might involve heads of design, product management, programme managers, and more.

This is actually what makes the model useful. Frustratingly, org charts (the bread and butter of organisational mapping) only show you who reports to whom and ignore a lot of context. This approach shows you whether the essential functions are actually happening, where, and how well. You’ll often find functions that are neglected because everyone assumes someone else owns them, or duplicated in ways that create confusion rather than clarity.

With that in mind, here are the five functions:

Delivery teams (System 1) This is where people are doing the work of delivery; designers and researchers embedded in product teams, delivering value day to day. This is where most attention goes, but even brilliant people in these roles hit limits if the surrounding system isn’t working.

Coordination (System 2) How delivery teams stay aware of each other. In practice, this might mean coordinating research sessions so you’re not over-recruiting the same customers, sharing insights across squads, or aligning on end-to-end journeys so work in one area doesn’t create friction elsewhere. Service designers often operate in this space, helping connect the dots. Without it, teams operate in silos, with the same problems getting solved repeatedly in different corners of the organisation, while other problems fall through the gaps entirely.

Operational standards and resources (System 3) The structures that help teams work consistently and effectively. This includes things like customer journey and persona templates that give teams a shared starting point, agreed best practices, and rules of engagement with other disciplines. It also includes resource allocation that can provide additional support to projects under pressure, rather than leaving teams to sink or swim alone. Done well, this creates clarity and consistency that actually enables and encourages team autonomy. Done poorly, it becomes bureaucratic control that stifles the judgment of the smart people you hired to make decisions.

Strategic sensing (System 4) Looking outward and ahead. Improving our understanding of customer trends, market shifts, emerging risks. Not just for a single product, but for the organisation as a whole. This is where a lot of design and research insight could go, but it often doesn’t because there’s no clear path from insight to strategic decision. Research teams might be generating valuable foresight, but if it’s trapped in delivery-focused workflows, it never reaches the people shaping strategy.

Direction setting (System 5) The function that sets vision, principles, and policy for the whole. This isn’t about senior leaders micromanaging, it’s about providing clear enough direction that teams can operate autonomously while staying aligned. Design can play a crucial role here: helping leadership make informed decisions based on real insights, developing compelling ways to visualise strategy, and communicating direction in ways the whole organisation can understand and act on.

The connective tissue: Communication channels

None of this works if information can’t flow. The right stakeholders need to receive relevant information, at the right time, in forms they can understand and can act on.

But here’s the trap that catches out so many teams: Effort and time put into communication can easily become a burden that pulls teams away from the work itself. The goal isn’t to add rituals and reporting for their own sake, it’s to find methods that make sharing easier, not harder.

That might mean: short showcase sessions where teams share what they’re learning as a natural part of their workflow, not a separate presentation to prepare. Research repositories that capture insights as a byproduct of doing the work, rather than requiring a separate write-up afterwards. Dashboards that pull data automatically rather than needing manual updates. Quarterly reviews that replace scattered ad-hoc check-ins rather than adding to them. Even format choices matter, a two-minute video walkthrough recorded during the work might get acted on where a polished 40-page report gets ignored and takes days to produce.

The test is simple: does this communication method reduce friction across the system, or does it just create more work for people already under pressure? There’s a cognitive load question here. Every reporting requirement, every ritual, every template is asking for someone’s attention. Attention is finite. The best communication methods work with how people actually think and work, not against it.

Where most design orgs struggle

In most design functions, the first three functions get the most attention. Delivery teams are visible. Coordination happens, even if informally. Standards and templates exist, even if inconsistently applied.

But strategic sensing and direction setting are often weak or missing entirely.

Research generates insight, but there’s no channel to strategy. The findings sit in a repository, maybe get presented once, then fade. Design leadership advocates for more influence, but lacks the connection points to where decisions actually get made. The team is busy, but the work isn’t shaping the organisation’s direction.

This is why your insights aren’t landing. It’s not a quality problem, it’s not a presentation problem, it’s a system problem. The function that connects design intelligence to organisational decision-making either doesn’t exist or isn’t working.

This isn’t because design leaders don’t care about strategy (if anything, they’re often craving to do more of it). It’s often because they’re rewarded for delivery, measured on output, and not given the time or the organisational access to do the strategic work. The system we’re operating within often doesn’t value or enable those functions, so they don’t happen.

What this unlocks

When your design system is working, when all five functions are healthy and connected, two things change.

First, designers can actually do more meaningful work. They’re not drowning in reactive requests or duplicating effort. They have the context to make good decisions and the channels to ensure those decisions matter. They can see how their work connects to something larger. That’s not a soft benefit. That’s the difference between a team that’s engaged and one that’s burning out.

Second, the organisation gains access to strengths of research and design that it couldn’t see before.

A mature design capability helps the organisation see more clearly. When research connects to strategy, when insights flow to decision-makers, when design has a voice in direction setting, you start to surface what actually drives long-term success: trust, relevance, experience quality. The things that nurture lasting customer relationships rather than just reacting to competitors and chasing satisfaction scores.

This provides more specific and actionable insights than relying on customer satisfaction and growth alone, which can be a blunt instrument: it identifies there is a problem, but rarely explains what actually needs to change.

This is how design earns its seat at the table. Not by asking for it, but by becoming essential to how the organisation sees and responds to the world.

What’s coming in this series

This post is an introduction that gives you the map. In the rest of this series, I’ll be unpacking ways that you can use it.

Post 2: Why your insights aren’t landing The gap between research and action. How to connect design intelligence to strategic decisions.

Post 3: Coordination Exhaustion Why your team is exhausted from context-switching. How to create alignment without bottlenecks.

Post 4: The shape of your teams A closer look at delivery teams, the different types you need and how they should work together.

Post 5: Why ‘speaking the language of the business’ is both necessary and insufficient. How to articulate design’s value in terms leadership actually cares about.

Post 6: Designing for autonomy What a mature, viable design capability looks like, and how to get there.

This is my current plan, but as I respond to questions and unpack ideas more I may adjust this or add other posts in future.

Before you plan: Diagnosing your design function

Remember: these functions don’t map neatly to teams or job titles. That’s the point. The diagnostic below isn’t asking “do you have the right teams?”, it’s asking “are these functions actually happening, and happening well?”

So before you finalise your plans for this year, ask yourself:

Delivery (System 1): Are our embedded designers and researchers set up to succeed, or are they stretched too thin and working inconsistently?

Coordination (System 2): Do our delivery teams know what each other are doing? Are we duplicating research, missing connections across journeys, or letting insights slip between the cracks?

Operational standards (System 3): Do teams have the templates, practices, and support they need? Are we sharing learnings, identifying what works well and evolving best practice?

Strategic sensing (System 4): Is anyone looking ahead, at trends, risks, or opportunities beyond the current roadmap? And if they are, does that insight have a clear path to influence decisions?

Direction setting (System 5): Is there a clear enough vision and set of principles that teams can operate autonomously without constant escalation? Does design have a voice in shaping that direction?

And one more, perhaps the most important: How are your people? Are designers energised by their work or exhausted by it? Do they feel like they’re making a difference or just treading water? The health of your system shows up in the wellbeing of the people within it.

You don’t need to, and probably can’t, fix everything at once. Knowing which function is weakest gives you a different starting point than “we need more headcount” or “we need a better process.”

The rest of this series will help you strengthen each of these functions, but the diagnostic starts now, and so does your planning for a more effective design capability in 2026. If nothing else, I hope this offers a different starting point for your planning. Not “what do we need?” but “what’s actually working, and what isn’t?”

If any of this resonates, or if you’re wrestling with these challenges in your own organisation, I’d love to hear from you.