Most design teams aren’t broken. They’re stuck at a stage they’ve outgrown, with the tools they had when they were one stage smaller. The work changed shape and the operating model didn’t. So the team works harder, the PM gets louder, the designer goes quiet, and the dashboard keeps reporting that everything is fine.
What follows is a model we’ve been building from twenty years of design leadership conversations — not a framework, a field guide. Five stages every design team passes through, the signs you’re at each one, what breaks if you stay too long, and the move that actually unlocks the next stage. No certifications, no McKinsey deck. Just the pattern.
Read it once. Find your team. Then decide whether the answer is a better tool, a different process, or a harder conversation with your VP.
Stage 0 — Chaos
Every request is a fire. Slack DMs route around any system that exists. The backlog is whatever the loudest PM mentioned in standup yesterday. Designers are measured on how fast they turn around mockups, and the only ritual is the weekly status meeting where everyone reads what they shipped from a tab they kept open.
Signs you’re here: the team has a Notion page called “Design Requests” that hasn’t been updated in three weeks. The most senior designer is the one with the highest tolerance for being interrupted. Nobody can answer the question “what is the team working on this week” without opening four tabs.
What breaks: the senior designer quits. They quit because every week looks the same as last week, except louder. The ones who stay learn to say no by going slow, which the org reads as “design is a bottleneck.”
The unlock: a single human says no on behalf of the team. Usually a design lead, occasionally a designer who got promoted into it by accident. The job isn’t process. The job is filtration.
Stage 1 — Survival (tribal triage)
Someone is now gating requests, but the gate exists in their head. There’s a form, maybe, that nobody fills out. There’s a Slack channel called #design-requests that the gatekeeper monitors. The team has roughly the right idea about priorities and roughly no documentation of how those priorities got set.
Signs you’re here: if the gatekeeper goes on vacation, the team reverts to Stage 0 inside three days. The phrase “just send it to me and I’ll figure out where it goes” is said multiple times per week. Onboarding a new designer takes six weeks because the system is shadow-knowledge.
What breaks: the gatekeeper burns out. They burn out because they spend forty hours a week on triage and zero hours on craft. Or they get promoted, and the person who replaces them doesn’t have the relationships to make tribal triage work.
The unlock: the rules come out of one person’s head and into a shared surface. Doesn’t have to be a tool yet. A wiki page titled “how we accept work” is enough. The point is that the gate is now legible.
Stage 2 — Process (the brittle workflow)
Now there’s a real workflow. A request form. A triage column. A “in design” column. A handoff column. Probably built in Jira, Linear, Asana, or a Notion database that’s started to look suspiciously like Jira. Status updates happen at standup. The team can answer “what are we working on” without opening four tabs.
This stage feels like progress. It often is. It also has the longest plateau of any stage in the model, because once you have a workflow that mostly works, the incentive to change anything drops to almost zero.
Signs you’re here: the team uses an issue tracker for design work. The PM org is happy because they can see status. Designers are mostly unhappy because every status update feels like surveillance, and the workflow assumes design moves linearly from request to handoff — which it doesn’t.
What breaks: the gap between the workflow and the work itself gets wider every quarter. Designers start keeping a second, real backlog — in Figma comments, in their head, in a private Notion. The official tool becomes a performance for the PM org, and the actual work happens in a parallel universe. Velocity charts trend up while quality trends down and nobody can explain why.
A workflow that the team is performing for an audience is not a workflow. It’s a theater. And theater has actors, not designers.
The unlock: the operating model has to start from the work, not from the reporting. This is the hardest stage to leave because leaving it means telling your VP that the dashboards they trust are misleading them. Most teams don’t leave. They stay here for years.
Stage 3 — System (the operating model)
The team now has an operating model that survives turnover. The intake gate isn’t a person, it’s a rule: solution-specific requests get reframed as problem statements before they enter the queue, period. The workflow has stages that match how design actually moves — non-linear, with explicit loops back to earlier stages when the problem turns out to be different than the intake suggested.
Signs you’re here: a new designer onboards in a week, not six. The PM org has stopped asking “when will it ship” and started asking “what problem are we actually solving.” Status updates are written by the system, not by the designer, and they’re short.
What breaks: the system itself becomes invisible to the people using it, which is the point — but it also becomes invisible to the people who should be improving it. Without a feedback loop, even a great operating model ossifies. After eighteen months, the team is still running the system that worked for last year’s problems, and the new problems are invisible.
The unlock: outcomes have to feed back into the system itself. Not just “did we ship” — that’s a status. Did this ship actually change anything for the user?If your operating model can’t answer that question, you’re still at Stage 3, and you’re heading toward the same plateau Stage 2 had.
Stage 4 — Calibration
The rarest stage. The system measures its own outcomes and adjusts. PMs whose requests consistently led to measured wins get a higher trust score — not as surveillance, as calibration. PMs whose requests consistently led to ship-and-forget tickets with no outcome get reframed harder at intake. The team isn’t reacting to dashboards; the dashboards are reacting to the team.
Signs you’re here: the designer reflection at the end of every Stream is read by the PM, not skipped. The phrase “we shipped it but it didn’t move the metric” is something the team can say out loud without finger-pointing. Quarterly reviews start with what the team learned, not what the team shipped.
What breaks here: nothing structural. What breaks here is people — specifically, the people who built the system. Designing the operating model for your team is the most senior work design leadership ever does, and once it’s running, the founder of it gets bored. The system needs a steward, not a builder, and most builders are bad stewards. Plan for that.
How to use this model
There are two honest ways to use this. The first is diagnostic: read it once, decide where your team actually is (not where you tell investors it is), and write down the move that unlocks the next stage. Then go do that move and only that move. The biggest mistake teams make at this point is trying to skip stages. Stage 1 to Stage 3 in one quarter is impossible. The shape of the work has to change first.
The second is selection: when you’re evaluating tools, evaluate them against the stage you’re moving into, not the stage you’re currently in. A tool built for Stage 2 will hold your team there. A tool built for Stage 3 will feel like overkill until the day it doesn’t.
We built Lane around Stages 3 and 4, because that’s the gap nothing on the market addresses. Jira and Linear are excellent at Stage 2 and we won’t pretend otherwise — if you’re still climbing out of Chaos, start there. But if you’ve been at Stage 2 for a year and the wider gap between the workflow and the work is starting to scare you, that’s the signal. The next stage isn’t a better dashboard. It’s a different operating model.
Surveillance produces performance. Support produces truth. The maturity model is the road from one to the other.