Design systems that survive a growing product org

A system is not a component library. Here's how we structure tokens, governance, and contribution so design keeps pace with engineering.

Every engagement we take on starts with the same uncomfortable question: what would we build if we couldn't hide behind a slide deck? This piece pulls together what we've learned answering that question across dozens of teams — and where we've watched smart people repeat the same mistakes.

Start with the outcome, not the artifact

Roadmaps full of deliverables are easy to write and hard to defend. Roadmaps built around a measurable outcome — cycle time cut in half, revenue per session up 8%, MTTR under 15 minutes — force a real conversation about tradeoffs. That conversation is the entire point.

Once the outcome is on the wall, the technology choices get smaller, not bigger. You stop debating frameworks and start debating who owns what on Monday morning.

Ship in weeks, not quarters

Long release cycles let bad assumptions compound. Short ones flush them out. On every project that went sideways, we can point to the month someone said "let's just wait until it's ready." It never is.

"The team that ships in two weeks learns twice as fast as the team that ships in four."

Instrument before you optimize

You cannot improve what you cannot see. Before we touch a service, we make sure someone on the team can answer three questions in under a minute: how often is it called, how often does it fail, and how fast is it on the 95th percentile. If the answer is "not sure," that's the first ticket.

None of this is new — but it is uncomfortably easy to skip. The teams that don't skip it are the ones we like working with the most.