The Internal Pitch

At some point, the design system team needs engineering to do something they didn't plan for.

Adopt a new component. Migrate from a legacy pattern. Allocate a sprint to contribution work. And engineering's roadmap is already full — it is always already full — and the design system request arrives as one more thing competing for time that doesn't exist.

For most of my career in design systems, the pitch never happened proactively. Not because the argument wasn't ready. Because the conditions for a proactive pitch never existed. The design team was not invited to planning. We were invited to the emergency. We arrived after the wall was hit, when the question was no longer "should we use the design system?" but "how do we fix what we built without it?"

That is not a pitch problem. That is a positioning problem. And it is the most common structural reality design system teams operate inside.

Most design system teams handle this by sending a well-formatted Slack message and hoping for the best. The roadmap does not care about well-formatted Slack messages.

Why Most Design System Pitches Fail

The most common design system pitch to engineering leadership sounds like this: "We need squads to adopt the new component library. It will improve consistency and reduce design debt."

This pitch fails for three reasons.

First: "consistency" is a design value. It is not an engineering priority. Engineers care about shipping features, reducing bugs, and not breaking what already works. Consistency is the outcome of doing those things well — not a reason to take on adoption work.

Second: "design debt" is a design concept. Engineering has technical debt. It is not the same thing. Asking engineering to prioritize design debt reduction requires a translation that most design system teams never provide.

Third: the pitch asks for engineering time without offering engineering value. It is a request disguised as a pitch.

A pitch that asks for something without offering something in return is not a pitch. It is a favor request with a slide deck attached.

The blocking mechanisms evolve. Early in my career, teams said no to the design system because they could. Later, as user research became a standard organizational practice, a new tactic emerged: requiring research validation for design system decisions before they could be applied. Not because the research would change the outcome. Because the research process created a delay. The ask went into a queue. The queue moved slowly. The sprint ended.

A gatekeeping mechanism dressed up as a quality standard is still a gatekeeping mechanism. The pitch needs to account for both.

Engineering adopts what reduces their cost. Not what improves your consistency score.

The clearest illustration of this: I watched a PM decide she could do design herself during an MVP sprint because the timeline was too tight for process. Her reasoning was direct — design is easy, everyone can comment, everyone can validate. The design system was not bypassed because of a deliberate decision against it. It was bypassed because design was classified as optional when speed was the only priority.

When design is perceived as easy, the design system is perceived as unnecessary. The pitch happens too late because the classification happened too early.

The Three Arguments That Actually Work

Each of these arguments translates design system value into engineering priority language. Use the one that matches the engineering leader you are pitching to.

Argument 1 — The Velocity Argument

"Squads using the design system implement new UI patterns 30% faster than squads that don't. Adopting the system for the Q3 feature set will save approximately 40 engineering hours across the sprint cycle."

This argument works with engineering managers and VPs of Engineering. It speaks in sprint hours and delivery velocity — the two currencies that matter most in quarterly planning.

You need data to make this argument. Which is why the ROI measurement from Episode 2 exists. Build the measurement model before you need the pitch.

Argument 2 — The Defect Reduction Argument

"Design system components ship with accessibility, cross-browser compatibility, and dark mode handling built in. Adopting them for this feature set eliminates three categories of QA defects that your team currently catches in staging."

This argument works with engineering leads who own quality. It speaks in defect categories and QA cycles — the costs that don't show up in sprint planning but accumulate in every release.

Argument 3 — The Maintenance Argument

"Your squad currently maintains three custom implementations of the same dropdown component. When the brand refreshes — or when the accessibility standard changes — that maintenance cost multiplies by three. Adopting the design system component consolidates that to one."

This argument works with engineering leads who own technical debt. It speaks in maintenance cost and future-proofing — the long-term engineering concerns that get sacrificed in every feature sprint.

The maintenance argument requires knowing which squads have duplicate implementations. Which requires an audit you should have done already. If you haven't — that is your quick win for this week.

How to Deliver the Pitch

One page. One meeting. One ask.

The one page: the ROI summary from Episode 2. Three numbers, one trend line, one recommendation.

The one meeting: not a Slack message. A standing agenda item in the engineering planning cycle. Request fifteen minutes in the next sprint planning meeting. Not a separate design system meeting. The one they are already attending.

The one ask: specific, scoped, and attached to a sprint. Not "adopt the design system." Instead: "allocate four engineering hours in the next sprint to migrate the dropdown component. Here is the migration guide. Here is the time estimate. Here is what you stop maintaining afterward."

A specific ask can be accepted or declined. A vague ask gets deferred. Indefinitely.

The Quick Win: Audit One Squad

Identify one squad with the lowest design system adoption. Count the number of custom UI components they maintain that have an equivalent in the design system.

That number is your maintenance argument. Bring it to their next planning meeting with one specific migration proposal.

"Would you choose this if nobody required it?"

If the answer is no — the argument isn't ready. Go back to the velocity data and the defect reduction numbers until the answer changes. Because that answer tells you more than a hundred launch slides ever will.

The Argument

A design system that cannot make its own case is a design system that depends on goodwill. Goodwill does not survive reorganizations, budget cuts, or new engineering leadership. The internal pitch does.

Season 2 has made the case for treating a design system like a product. Season 3 is about what happens when that product needs to scale its reach — without scaling the team proportionally. That is the service problem. And it is harder than it sounds.

Disagree loudly. Inspire boldly.

And remind me — falsely if needed — that somewhere a design system pitch landed in a sprint planning meeting and engineering said yes on the first try.

Which of the three arguments — velocity, defect reduction, or maintenance — would land best with your engineering leadership right now?

Season 2 complete. Continue to Season 3 — Design System as a Service →