Small is the norm for design-system teams. Despite the reach and stakes of the work they do, design-system teams stay lean. While being small is often seen as a constraint, it is also what enables design-system teams to operate so effectively — when this setup is a deliberate operating choice rather than a resourcing default.
Design Systems Stay Small
Design-system teams don't scale proportionally with company size. According to Zeroheight’s annual design system reports over the past 5 years, most design-system teams consist of just 2–5 people, often balancing system work with product responsibilities. Even in large organizations with 5,000+ employees, teams average around 9–11 people — far from a proportional increase in headcount to match the increase in organization size. Design-system teams rarely exceed 20–25 people regardless of organization size.
This pattern suggests that the lean setup is more than a resourcing constraint. Small, integrated design-system teams may be better positioned to build effective systems. Our conversations with practitioners confirmed this hypothesis: many pointed to the small-team setup as a factor in their success. Smaller teams are more cohesive, easier to coordinate, and better able to maintain a clear vision for the system than larger teams.
Fewer People, Fewer Bottlenecks
On small design-system teams, context doesn’t need to be passed around; it’s visible and shared by the whole team. The same people who scoped a component are the ones implementing and supporting it. The team moves at the same pace, and everyone is present for the key decisions — team members are aligned on why a component was scoped a certain way, which product teams are waiting on it, and what technical constraints shaped the implementation. There’s little need for formal handoffs, status syncing, or reexplaining past decisions, because no one is out of the loop.
This shared understanding is what makes small teams move fast. When a conflict arises, it gets resolved faster — fewer people means fewer opinions to reconcile and fewer approvals to gather before a decision can move forward.
One design-system product owner we spoke to pointed to team size as a factor in their success:
“The great thing about this team was that we actually convinced the company that this team was to work as one integrated pod. And that was the game changer for how fast we could get things out, how easily we could get things done. We caught edge cases earlier and better than we would have on our own… Me, being so close to the technical architect, and the developers speaking up when they had questions about design, and design speaking up. Being able to have those conversations in a single room every other day together kept us moving very fast.”
Practitioners who have worked with a small design-system team that later scaled up also reflected on the benefit of a small team retroactively. When their team was small, decisions were faster, the work felt more productive, and less time was spent on coordination overhead. As design-system teams scale, managing a larger team requires more ceremonies, more consensus seeking, and the work of managing the team begins to compete with the work the team was supposed to do.
Blurred Roles Enable Better Collaboration
Most product teams beyond a certain size operate through specialization. Designers design. Engineers implement. Product managers prioritize. Content strategists write. Each discipline has its own workflows and review cycles. Work moves between these specialists through handoffs — requirements from product, specifications from design, implementation from engineering. The more people involved, the more transitions exist, and the more effort goes into making sure everyone stays on the same page.
In contrast, when 3-5 people support an organization of hundreds or thousands, the volume of incoming work often demands that everyone pitch in beyond their primary discipline: designers craft component API, developers critique designs, product owners engage in hands-on work.
When people naturally expand beyond their job descriptions, they develop a working understanding of adjacent disciplines that helps them become better collaborators. A developer who has participated in design critiques understands not only what is being proposed, but why certain constraints exist. A designer who has contributed to implementation documentation gains a clearer sense of feasibility, system boundaries, and technical cost.
This crosspollination gives team members broader contexts, speeds up feedback loops across disciplines, and fosters a shared understanding of the whole system that specialists in larger teams rarely develop.
Forced Prioritization Creates Strategic Focus
A small team cannot do everything, and this constraint is a compass that helps design-system teams define strategic focus and prevent overcommitment.
When resources are scarce, every decision about what to build is implicitly a decision about what not to build. This focus keeps the design system aligned with the product roadmap and tied to real business impact. The team builds fewer components, but the ones it builds are the ones product teams actually need. It writes less documentation, but what it writes is essential and precise.
Design systems naturally attract a high volume of requests, often exceeding what any team could realistically support. Being small makes prioritization visible and defensible. It creates a shared understanding that capacity is limited, which, in turn, makes deprioritization easier to justify.
In practice, the small size helps reduce friction. Product teams are more likely to accept “not now” or even a hard “no” when constraints are clear. The result is a focused system that avoids overextension and maintains coherence, rather than one that tries to accommodate everything and loses focus.
Scaling Through Contribution and Championship
Small teams learn, out of necessity, to extend their impact through people outside the team. Effective design-system teams shift their role from producers to enablers — extending their reach through champions, contributors, and collaborators from the rest of the organization, who become active participants in the design system's growth. This model often produces stronger design-system adoption than centralized ownership, because the people using the system also helped build it. A self-selecting community is more sustainable than a leadership mandate to use the system, because it runs on intrinsic motivation.
One solo practitioner described crafting roadmaps that were designed from the start to be executed with partners. They launched champion programs that gave product teams ownership over specific system contributions and worked to get design-system priorities onto other teams' roadmaps. The result was threefold: work got distributed without adding headcount, leadership saw the system as intrinsically linked to product efforts across the company, and informal goodwill became formal allocation — product teams had legitimate reasons to spend time on design-system work because it was on their roadmap too.
As the system matures, small teams may shift in how they spend their time. For high-priority work, they stay hands-on. For everything else, they move to an advisory capacity — providing guidance, reviewing contributions, and maintaining quality standards without absorbing delivery responsibility. This approach lets the team maintain influence across a wider area than they could if they were building everything themselves.
The Reality of Being Small
It’s important to draw a clear line between empowering a small team to operate effectively and expecting an understaffed team to absorb unlimited demand. While we celebrate the wins of lean design-system teams, we should also acknowledge the challenges they face.
Small teams operate with little slack in the system. When one person is out, a significant share of the team's capacity goes with them. When someone leaves, they often take undocumented institutional knowledge with them because there was never enough time to externalize what was shared informally. The same trait that makes small teams fast — context living in people’s heads — also makes them fragile.
There's also a distinction between healthy role flexibility and unsustainable overload. A designer who picks up enough code to push their own token or color fix is crosspollinating. A designer who's become the third engineer on the team because no one else has time to ship is stretched thin. Small teams operate closer to this line than larger ones, and the balance can shift quickly with a single change in scope or staffing.
Capacity constraints also shape what work gets done — and what doesn’t. Sometimes, that means that valuable projects are deprioritized. Comprehensive support efforts, (such as robust documentation, one-on-one support for consuming teams, and multiplatform scaling) are harder to sustain in a small-team model. Yet these are the very investments that allow a design system to scale and deliver consistent value across teams.
Small by Design vs. Small by Default
Maintaining a small, central design-system team should be a deliberate design-ops strategy, not a staffing compromise. The advantages discussed in this article don't come from the small size alone. They come from a small team operating under specific conditions: defined system scope, executive buy-in, and expectations calibrated to what the team can realistically absorb. The small size is what makes cohesion possible, but the rest of the scaffolding needs to be in place for that cohesion to translate into impact.
In many organizations, small isn't a deliberate choice but an unfortunate default. Teams remain lean because the work is undervalued or lacks executive sponsorship. "Lean," "scrappy," and "doing more with less" become flattering vocabulary for underinvestment. In those cases, limitations outweigh the benefits: burnout, slow delivery, growing maintenance debt, and uneven support.
The bottom line is, if an organization wants to scale the support a design system offers, it needs to start by properly resourcing the team and treating its work as a priority. That means pairing a small team with realistic expectations, organizational sponsorship, and a willingness to add real capacity when the system's reach outgrows the team's bandwidth — not just through contributors and champions, but through real headcount.
Conclusion
Design-system teams can be small and still deliver meaningful impact. This is not an excuse for organizations to understaff a design-system team, but an opportunity to recognize small teams as a stable operating model, and preserve what makes small teams effective while finding ways to scale the system without losing those advantages.
The most resilient design-system teams don't try to do everything themselves. They use their collaborative advantage to build systems, documentation, and a community of advocates.
A small team can’t build everything. But a team that works fluidly across disciplines, prioritizes ruthlessly, and enables others to contribute effectively can sustain a system that scales far beyond its own headcount.
