You do not need a design system.

You need a designer who gives a shit.

Startups love chasing maturity. Especially when things start to feel messy. There is always a moment where someone lifts their head and says, “We have grown. Things are not as fast or clean as they used to be. We need systems. We need roles. We need proper design.”

This is usually when someone decides they need a Head of Design. Or a design system. Or a set of rituals that will somehow make the mess go away.

But most of the time, the mess is not a maturity problem. It is just the natural consequence of doing too much, too fast, with not enough people. A new title will not fix that. A glossy playbook will not either. And trying to fast-forward into someone else’s version of “mature” usually just slows you down and introduces bloat you do not need yet.

I have seen this happen across startups, corporates, and scale-ups. The pattern is the same: instead of solving the actual problem in front of them, teams try to solve their vibe.

Claymation figure holding a blueprint while everything is burning

One of the easiest traps is copying what worked somewhere else. You hear that Company X uses tokens. That they have polished rituals and beautiful documentation. That they have built a huge design system and have a Figma plugin for everything.

So you bring that into your team, hoping for the same results.

What you do not see is the years it took to get there. Or how deeply those tools are tied to the way that company actually works. Without that context, you are just bolting on structure for its own sake. The form without the function.

You copied the ceremony, not the intent.

Claymation builder who is not constrained by a rigid blueprint

Up did not have a design system for the first four years.

Not because we were careless, but because the product was evolving so quickly that a system would have slowed us down. It would have locked in assumptions too early. We needed to move fast, try things, and let the product itself shape the patterns.

Instead of a system, we had shared values. Tight feedback loops. Designers who gave a shit and cared deeply about quality. That worked because we were close to the product and to each other. We did not need a rulebook to stay consistent.

Eventually, we built a system. But only once the product had stabilised and the patterns were real. It was not a shortcut to good design. It was the byproduct of it.

Hiring too senior too soon

Another version of the trap is bringing in a Head of Design before there is anything to lead.

You think you are buying strategic thinking, clarity, and leadership. But if you do not have a team, or a clear strategy problem, or the appetite to be challenged on your decisions—what you are really buying is frustration.

I have seen brilliant design leaders stuck pushing pixels because they were hired as a shortcut. No authority, no mandate, no trust. They were not the wrong person. It was just the wrong time.

What you probably need is a senior designer who gives a shit. Someone who can work through ambiguity, push the work forward, and help you figure out what to do next.

Blue builder at work and gaining the trust of the other characters

Prove the need before filling the role

At Bendigo Bank, we were trying to demonstrate the value of design inside a business unit that had never worked with a product designer. They were not hostile—just unconvinced. There was no budget, no roadmap, just a vague sense that maybe they should talk to someone.

We offered to run a four-week “try-before-you-buy.” One of our best designers embedded directly with the team, working on real projects to show what was possible.

By the end of the four weeks, everything had changed. The conversation shifted from “We do not need a designer” to “Next financial year, we want to bring on two seniors and a junior.”

This did not happen because we convinced them with a deck. It happened because we did the work, showed the outcomes, and built trust from inside the team.

Sometimes maturity looks like structure. Other times, it looks like patience.

Blue builder and all the other characters enjoying a lunch break together

There are rituals that help. Crits, showcases, design huddles—these can all be powerful. But they need to grow out of what your team needs, not what you think makes you look like a real design org.

Some teams thrive with structured reviews. Others work better with quick, frequent pairing. The shape of the ritual matters less than whether it helps your people work better together.

When a ritual becomes a performance, or a checkbox, it is time to kill it.

You need rituals that serve your people, not your image

What to try instead

  • Clay ball

    Start with the problem, not the tool.

    If your team is shipping bad work, do not start with components. Start by asking why nobody flagged it.

  • Clay pyramid

    Pilot roles before filling them.

    An embedded designer will teach you more about what you need than any org chart.

  • Clay cube

    Delay structure if you can.

    A focused, high-trust team beats a bloated one with processes nobody follows.

  • Clay diamond

    Build the system after the patterns emerge.

    Good systems reflect your product. They do not predict it.

You do not need a design system.
You need a designer who gives a shit.

You do not need rituals.
You need a team that knows how to work together.

You do not need to look mature.
You need to make good decisions.

Get the work right first
The structure will follow.

Claymation builder who is not constrained by a rigid blueprint