In the previous articles, I argued that building a Design Team isn't about filling headcount, but about combining the right capabilities to serve the business strategy.
In this article, I want to use the word scale in a different sense. Scaling isn't just increasing the number of designers. To me, scale is first the maturing of an organisation's capabilities, and only then the size of the team. There are companies with hundreds of employees whose design team is still just a few people, and there's nothing unusual about that.
Most of the Design organisation models we know today came from technology and digital product companies around the world. In this article I draw partly on the framework from Org Design for Design Orgs by Peter Merholz and Kristin Skinner, and compare it with Peter's recent writing on Design Organizations. Still, I don't see it as a standard model to apply wholesale. Every business needs to adapt it to its own size, strategy and context.
In my view, the biggest change when Design starts to scale isn't the number of designers, but Design moving from solving the problems of individual products to building shared capability for the whole organisation.
Scale doesn't start with the number of designers
At one point in my time as a manager, when I saw overlapping work and inconsistent design quality across teams and individuals, my first instinct was to understand each person's abilities and compare them with what the product and organisation required.
And I realised the problem rarely lies with the people, but with how the existing designers are organised to work together effectively. Since then I've believed that when Design starts having problems, the first response shouldn't be to hire more people, but to review how the team is organised.
A common misconception is: the bigger the team, the more complex the organisation it needs.
That isn't quite true. I've seen teams of just 3–5 designers where coordination was already a mess. And I've seen organisations with dozens of designers running quite smoothly. The difference isn't headcount, but the complexity of the problems, the organisation's expectations and the cost of coordination.
Complexity appears when a business starts to expand:
- Serving many product teams at once instead of just one.
- Handling a product with dozens of experience flows and customer touchpoints.
- Many teams touching and changing the same Design System.
- One organisation containing teams with different competitive strategies (Defender, Reactor, Prospector or Analyzer).
As expectations grow, the number of connections grows faster than the number of people. That is when Design needs to think about scaling both its quality and its operating model.
Signs that Design needs to change how it's organised
In practice, businesses usually only realise they need to scale when operational “symptoms” start appearing again and again:
- At the organisation / product level: the product experience falls well behind competitors; the ROI of development and marketing doesn't improve; the product lacks user feedback, partly because designers aren't involved from the start; the product isn't updated or refreshed regularly.
- In day-to-day work: the same UI component is built differently by every team; teams waste time re-solving design decisions others already made; designers spend more time “managing stakeholder conflict” than solving user problems; developers adjust the UI themselves to hit deadlines; design reviews are slow for lack of shared standards; design has to chase the pace of the engineering team.
Once 3 or more of these signs appear, the organisation starts to see design as a “bottleneck”. The problem then rarely lies in individual designers' abilities, but in the organisation having no method to help the team work as a system.
Peter Merholz also suggests that an effective design team should usually have around 4–6 designers led directly by one Design Manager. Beyond that, the cost of coordination, coaching and decision-making starts to rise. That isn't yet a sign the business needs a more complex Design Organization, but it is the moment to revisit the team structure and how responsibilities are divided.
When a business no longer competes on features
Early on, startups compete mainly on speed: shipping features faster, finding Product-Market Fit first. At this point, a few flexible Product Generalists create more value than a complex design machine.
But as the market matures, competitive advantage shifts. A new feature can make a huge difference early on, but over time the feature gap between products narrows. Competitors can copy a feature in a few weeks or months.
What's harder to copy is how fast the organisation learns, the quality of the experience, consistency, and the ability to run the product at scale.
At this stage, the business no longer competes mainly on features. It competes on its ability to operate and grow the product sustainably. That is exactly why Design needs to scale — moving from “making individual screens” to “building capability for the whole organisation”.
3 organisational models from a practical view
I don't see these as three maturity levels. A business can move back and forth between models as its strategy changes.
Centralized ◄──► Embedded ◄──► Central Partnership
- Centralized: Designers belong to one Design Team led by a Design Leader. In practice: very good early on for building a shared culture, process and standards. The biggest drawback is that the team is easily seen as an internal service department, with an “us vs. them” mindset, distance from the product context and complaints from other teams about slow delivery.
- Embedded: Designers sit directly in, and report into, each product team. In practice: very fast execution — this model is very common in companies that build products with squads or cross-functional teams. But in the long run designers become fragmented, lack critique from peers and lack a career path. Without shared standards, the product quickly becomes disjointed and costly to maintain.
- Central Partnership (Matrix): Designers belong to the design organisation (for craft and people) but work day to day inside each product team. In practice: this is considered the best fit for large, complex products (Fintech, Banking, SaaS). Instead of splitting designers by scattered features, the Design team is organised around User Journeys — for example, teams serving the retail flow or the business flow in a bank. This model balances each team's execution speed with consistency across the whole customer experience.
At scale, a Capability should become its own Role
In other words, a role is only the outward expression of a capability. Don't create a title just because big companies have it. A capability should only become a separate position when it meets 4 conditions: important enough, complex enough, enough long-term workload, and impact across many teams.
Here are specialist roles that typically appear as a design organisation grows:
- Design Technologist / Design Engineer: Bridges design and technology. If the Design System standardises the interface, this group standardises how Design uses technology — from coded prototypes and syncing Figma with the codebase to applying AI and automating workflows to raise the whole team's productivity.
- UX Researcher: As the product and organisation grow, research becomes deeper and more continuous. UX Researchers plan research and collect and analyse qualitative and quantitative data, helping the team understand user needs correctly, reduce decision risk and make design iterations more effective.
- Service Designer: Not every business needs a Service Designer — someone who designs across the whole service rather than a single product or screen. They make the customer experience consistent across touchpoints such as apps, websites, stores, call centres and internal operations. This capability is only truly needed when the business has a complex enough Service Blueprint, as in banking, insurance, hospitals or logistics.
- Design Program Manager (DPM): Unlike a Product Owner responsible for one product, a Design Program Manager coordinates design initiatives that affect many products at once (Design System, Accessibility, Re-branding), making sure every strategy is rolled out consistently and on schedule.
- DesignOps: As the team grows, DesignOps standardises processes, tools, onboarding, resource planning and the operations of the design organisation. This capability lets designers spend more time solving design problems instead of coordinating.
(Depending on each organisation's size, these roles don't have to be separate hires right away; they can be specialist skill sets invested in existing staff.)
With the arrival of AI, from what I've seen, teams have shrunk by roughly 30–50%. But remember: teams can shrink because each role has become more productive, not because a role has been eliminated. In software production today, AI changes roles; it can't yet fully replace any position.
Scale isn't adding people
After all four articles, what I most want to stress is this: scale means building capabilities that can be repeated, shared and extended across the whole organisation. It's a shift in mindset:
Design as Execution → Design as Organizational Capability
Looking back across the series, Design is seen at progressively different levels:
- Part 1: Before hiring designers, understand what value the business really needs Design to create.
- Part 2: Once you understand the strategy, identify which capabilities the business needs instead of looking only at job titles.
- Part 3: When building the team, the goal isn't to gather the best designers, but to combine complementary capabilities.
- Part 4: As the business grows, the problem is no longer building a Design Team, but turning those capabilities into capabilities of the whole organisation.
Conclusion
Perhaps building a Design Organization isn't the final destination. Even with the right people, the right capabilities and the right structure, there's a harder question: how do those capabilities actually create impact for the business?
For me, everything shared across these four articles points to one goal: reducing friction so Design's capabilities can turn into business impact.
I really like Katie Dill's formula (VP of Design at Stripe, formerly Head of Design at Airbnb and Lyft):
Actual Product Capability = Design Team Potential − Organizational Bureaucracy
Design leadership isn't only about great craft or building a strong team, but about creating an environment where those capabilities can be heard, coordinated and turned into real value — by learning to get past operational barriers and organisational bureaucracy.
That is also the topic I'd like to keep sharing with you in an upcoming article!
