Design System as Leadership Style
Why leadership style decides whether your design system grows up or falls over.
The first thing most teams get wrong about design systems is treating them as an artefact instead of an organisation. The Figma library, the Storybook, the component kit. Those are the outputs. The system is the group of people, decisions, and rituals that produce them. Once you see it that way, the leadership style you bring to it decides whether the thing lives or dies.
I have built and maintained design systems through two very different stages of a company. A startup at zero to one. A multinational moving towards IPO. The further I went, the more obvious it became that running a design system is less about Figma craft and more about choosing the right leadership mode for the moment.
The seven leadership styles, in a paragraph each
Most leadership frameworks split into the same seven styles. Here is the short version.
Affiliative. Leaders prioritise harmony, trust, and morale, especially during change or stress.
Autocratic. Centralised decisions. The leader holds full control and sets clear expectations. Useful in high-risk or time-critical moments.
Democratic. Shared decision-making. Input is gathered before decisions are finalised. The most common style in modern orgs.
Laissez-faire. High autonomy, minimal supervision. The leader provides resources and direction, then steps back. The opposite end of the spectrum from autocratic.
Transformational. Inspires through a clear, compelling vision. Drives innovation and long-term growth.
Transactional. Structured processes, defined roles, performance-based rewards and penalties.
Servant. Prioritises the team’s growth and removes their barriers. Builds trust through service.
If you have ever pushed for design system adoption inside a company, you have almost certainly used several of these without naming them.
My experience: the startup years
Earlier in my career I joined a personal finance startup in Singapore as a product designer. I inherited what most early-stage teams have. A design kit in Sketch. A disconnected set of React components spread across web and app. No system, no governance, no documentation worth keeping.
As a solo designer my job was solving immediate product problems and hitting company goals. System work was an after-hours job. I was lucky to work with engineers who valued consistency over endless refactoring, so we built it together on the side.
This was the autocratic phase by necessity. I was both the owner and the user of the system, so I made decisions on the fly and shipped improvements every sprint. There was no one to consult. There was no one to slow me down. The output was modest. A token system where colours matched. Type sizes that cohered. A baseline set of components. Then the company was acquired, and the context changed completely.
My experience: the multinational years
The next chapter put me inside a multinational working across five countries, three languages, and several product teams. The design system there had no owner and had been left unmaintained for years. Local design teams ran their own files. Engineers built custom components on top of them.
The company was moving towards IPO, and a mandate landed to migrate the front end onto HubSpot CMS. The migration forced a round of standardisation, and I took the lead on the design system conversations.
In hindsight, I cycled through four leadership styles in roughly this order.
Servant first. Before deciding anything, I needed to understand why the existing system had been abandoned. Conversations with designers and engineers surfaced the real causes. No documentation. Many people did not even know the system existed in the codebase. The original system had no provision for multi-language layouts or local market nuances. The job was to remove their barriers and it’s drastically different compared to the time at Seedly.
Autocratic next. The team had limited appetite for owning a system. Together with the engineering lead, we made a set of firm calls on direction so the migration could move. Decisions about the foundations needed to land fast, and consensus would have stalled us.
Democratic during the migration itself. Once direction was set, we needed every hand on deck. None of us fully understood HubSpot’s limitations yet, and I needed designers and engineers contributing patterns, edge cases, and corrections. Open discussion was the only way to surface what we did not know.
Servant again at the end. Post-migration, the system needed to belong to the team rather than to me. I built scaffolding for that to happen. Sprints carried dedicated story points for system work. Designers and engineers were encouraged to bring their own contribution problems and ship them with my support. The intent was not to step back and disappear. It was to stay close enough to unblock, document, and reinforce the rituals while the team grew into ownership.
Mapping the styles to design system work
Once I started thinking about this deliberately, the mapping became hard to unsee.
The spine of the model is the first four rows. Autocratic, transformational, democratic, servant. Those track company maturity. The remaining three are situational overlays. Affiliative when you are forcing painful migrations. Transactional when you operate in regulated, audit-heavy environments. Laissez-faire when the contributor network is mature enough to govern itself, which is rarer than most people think.
The hardest transition is autocratic to democratic
The single most underrated skill in design systems is knowing when to stop being the one who decides.
Founders and early DS leads who built the system tend to keep making unilateral calls long after the org has outgrown that mode. The system ossifies. Product teams stop contributing because they have learnt their input does not change outcomes. The library keeps growing, but the organisation around it stops trusting it.
Three signals that you have stayed in autocratic mode for too long.
Your team brings you proposals that already match your taste. They are predicting rather than contributing.
Edge cases never reach the system. Product teams have started solving around it because escalating is slower than working around.
The roadmap is your roadmap. You cannot point to a single item on it that came from someone other than you.
If two of those are true, the system is no longer scaling. You are.
How to use this as a working reference
If you are leading a design system today, the table above is meant as a working reference more than a model to admire. Use it before your next big conversation with your team or your leadership group.
Before a roadmap review, a contribution-model debate, or a pitch to rebuild the system, run three questions against the table.
What stage is the company in? Pre-seed, scaling, mature, regulated. The row that matches your phase is your starting point.
What does the team look like today? A solo designer, a federated network, a dedicated team with specialisms. Team dynamics decide whether the style you are reaching for is actually viable right now.
What is the dominant risk? Bottlenecks, fragmentation, graveyards, drift. The risk column tells you what failure mode you are most likely walking into.
The right move usually falls out of those three answers. Not from a generic framework, and not from whichever style you are most comfortable with.
A design system is not a Figma file you ship. It is an organisation you build. The leadership style you bring to it decides whether it grows up or falls over.
P.S. I recently left the studio I founded and am now on the lookout for a full-time role as a Product Designer. Drop me a DM on LinkedIn if you are looking for a designer who thinks in systems and uses AI as part of the workflow.