Framework

Your design system team has a culture problem

Every design system requires three distinct cultures to function. Most teams are stuck in one. Quinn and Cameron's Competing Values Framework explains why your team is grinding — and the INC framework maps the way out.

The Framework

Four cultures. Every organisation has all of them.

In 1983, Robert Quinn and Kim Cameron mapped organisational culture onto two axes: internal vs external focus, and flexibility vs stability. Four quadrants emerged. Four cultures that coexist inside every team, every company, every design system.

The problem isn't which culture you have. It's that you're probably stuck in one when the work demands you move between three.

Flexible · Internal → External → Stable

Clan

Collaborate
Internal · Flexible

Shared language. Shared context. The team that doesn't need a meeting to align. Culture so strong it's load-bearing.

Design systems role

Encodes collective knowledge — CLAUDE.md, tokens, shared narrative.

LeaderFacilitator / Mentor
Fails asGroupthink — harmony that suffocates conviction

Adhocracy

Create
External · Flexible

Burn freely. Branch freely. Vision over validation. The garage before the handbook. Jazz, not sheet music.

Design systems role

NorthStar prototyping — explores possibilities before anyone builds.

LeaderInnovator / Entrepreneur
Fails asChaos — brilliant sparks that never become fire

Hierarchy

Control
Internal · Stable

Standards. Governance. The machine that runs without you in the room. Reliability at scale.

Design systems role

Governed components, versioned tokens, production systems that survive.

LeaderCoordinator / Monitor
Fails asBureaucracy — process that protects itself, not the product

Market

Compete
External · Stable

Ship. Measure. Win. The culture that doesn't care how it was built — only whether it converts.

Design systems role

The customer of the system — converts capability into results at speed.

LeaderCompetitor / Producer
Fails asBurnout — output without reflection, velocity without direction
“Most design system teams don't have a tooling problem. They have a culture problem they've never named.
The diagnosis
The Insight

I<N>C isn't a process. It's three culture shifts.

When I first saw Quinn and Cameron's framework, I didn't learn something new. I recognised something I'd been doing unconsciously for years.

Each phase of I<N>C doesn't just require different skills. It requires a fundamentally different culture — different values, different leadership, different relationship to risk. The teams that struggle aren't bad at design systems. They're running Hierarchy culture during a phase that demands Adhocracy. Or demanding Adhocratic energy when the work needs Clan.

The framework makes the unconscious conscious. And once you can name the culture each phase needs, you can switch deliberately instead of grinding against the wrong one.

I — Ideate
<N> — Narrate
C — Create
CVF Culture
Adhocracy
Clan
Hierarchy
Focus
External — what's possible
Internal — what we know
Internal — what's reliable
Posture
Flexibility — explore without permission
Flexibility — encode collaboratively
Stability — govern without apology
Artefact
NorthStar prototype
CLAUDE.md, design tokens, shared context
Production components, governed code
Failure mode
Chaos — vision without traction
Groupthink — context without output
Rigidity — standards without soul
Leadership
Scout bee — sees what others can't
Narrator — translates for every audience
Architect — builds what survives contact with users
AI role
Generative — wild, unconstrained, disposable
Contextual — informed by encoded knowledge
Constrained — governed by tokens and standards
When to burn work
Always. Knowledge survives. Code doesn't.
Rarely. Context is the compound asset.
Never. Shipped code must persist.
The Fourth Quadrant

Market culture isn't your job. It's your customer.

The fourth quadrant — Market — is external focus with stability. Competition. Delivery. Revenue. In organisational terms, it's the go-to-market engine that converts capability into results.

Market culture sits deliberately outside the design system's concern. But it's what the entire system exists to serve. A well-functioning I<N>C cycle produces components, tokens, and patterns that Market teams can deploy at speed without thinking about the system underneath.

This is where most design system teams get measured wrong. “How many features did you ship?” is a Market question aimed at a Clan/Hierarchy team. The right question is: “How much faster can everyone else ship because of what you built?” The design system doesn't compete. It arms the competitors.

IDS 2026

Branch + Burn is conscious culture-switching

At Into Design Systems 2026, Nate Baldwin (Sr Staff Designer, Adobe) presented “Prototyping for the Unknown”. His method — Branch + Burn — looked like pure Adhocracy: branch freely, prompt vaguely, iterate wildly, take field notes, delete the branch, don't look back.

But his 4-step structured prompting told the real story. Step 1: Context priming — investigate, analyse, validate. “Do NOT make code changes.” Step 2: Detailed planning — format as prompts, incorporate tests, strict rules. Step 3: Plan refinement. Step 4: Implementation.

Look at what he's actually doing. Step 1 is Clan — building shared understanding before acting. Steps 2–3 are Hierarchy — encoding governance, creating constraints. Step 4 is execution within those constraints. The Branch + Burn part — the Adhocracy — is the exploration phase that feeds the whole cycle.

Nate's “don't make code changes in Step 1” isn't a productivity hack. It's a culture boundary. He's protecting Adhocratic exploration from premature Hierarchy. He's preventing the build impulse from killing the discovery impulse.

His process isn't one culture. It's a deliberate transition across three. The same transition I<N>C encodes as a framework. The difference: I<N>C names what Nate does intuitively, so teams can learn it instead of hoping to hire someone who already does it.

The Punchline

You're not maintaining a component library. You're maintaining the Clan.

Read any job description for a design system architect. It reads like a Hierarchy role: maintain the component library, enforce standards, ensure consistency. That's C work. Necessary. But it's the least important third of the job.

The design system architect's real work is maintaining the Clan culture that lets everything else function. The shared understanding. The encoded domain knowledge. The context that enables a scout bee to explore wildly during I and an engineer to build reliably during C — without either of them needing a three-hour alignment meeting.

CLAUDE.md is a Clan artefact. Not governance — that's Hierarchy. Not a prototype — that's Adhocracy. It's the shared narrative, the <N>, that holds the whole system together. When I write context files, I'm not writing documentation. I'm not writing rules. I'm encoding culture into a format that both humans and AI agents can consume.

Token files, naming conventions, component APIs — these feel like Hierarchy artefacts. But their real purpose is Clan. They create shared language. They make implicit knowledge explicit. They let someone new to the team build as if they'd been there for years. That's not governance. That's belonging, made machine-readable.

The design system IS the Clan culture, made machine-readable. And the design system architect is, whether they know it or not, the Clan leader.

“When I write CLAUDE.md, I'm not writing documentation. I'm writing culture.
The reframe

Which culture is your team stuck in?

If your design system team feels like it's grinding, it's probably not a tooling problem or a headcount problem. It's a culture problem — and now you have the language to diagnose it. Name the culture. Name the phase. Switch deliberately.

Diagnose It TogetherMore Thoughts
/