Your job is on a spreadsheet somewhere

Defending design system work when budgets contract

There’s a spreadsheet open right now in your organisation. Someone in finance or operations is looking at headcount. They’re looking at initiatives that don’t directly ship features. They’re looking for things that seem optional.

You’re on that spreadsheet. You might not be at the top of the list yet. But you’re there.

I’ve been on both sides of this. I’ve been the one asking the hard questions about team investment, and I’ve been the one trying to answer them. The second position is worse, not because the questions are unfair, but because by the time someone asks them out loud, the frame has already been set against you.

The design system practitioners I’ve watched lose their roles share a pattern. They waited. They assumed the value of their work was obvious. They thought the consistency, the efficiency, the careful infrastructure they’d built would speak for itself. It didn’t. The things that make design system work valuable are precisely the things that make it invisible. And invisible work is easy to cut.

The system survives. The people don’t.

When budget cuts come, the Figma library doesn’t disappear. The component repository doesn’t get deleted. The tokens don’t evaporate. The design system, as an artefact, survives.

What disappears is the team maintaining it. The governance keeping it coherent. The advocacy ensuring it gets used correctly. The expertise that knows why decisions were made and what breaks when you ignore them.

The system becomes a zombie: technically present, practically abandoned. I’ve written about how this plays out with AI tooling in The hidden cost of design system entropy, where drift compounds until the cost of fixing it exceeds whatever you thought you’d saved. The same dynamics apply here, just with human absence instead of AI exposure as the catalyst.

Without active stewardship, components get detached and modified locally, tokens fall out of sync, teams start solving the same problems independently, each slightly differently. The product that used to feel cohesive starts feeling assembled. And the people who could have prevented that? They’re gone. Moved to feature teams, laid off, or so stretched across other responsibilities that maintenance becomes impossible.

The timing problem

If you’re reading this because someone just questioned whether your role is necessary, you’re already behind. The conversation has shifted from “what does this work contribute?” to “what can we live without?”. Those are different conversations, and the second one rarely ends well for anything that doesn’t directly ship features.

The tech layoffs since 2022 weren't temporary corrections. They signalled a fundamental shift in how companies think about investment. Over 150,000 tech workers lost their jobs in 2024, according to tracking by Layoffs.fyi and Crunchbase. Google cut more than 100 design positions in October 2025 alone. The message from leadership has been consistent across industries: prove your value in terms we understand, or become the value we recover.

Design system roles sit in a particularly vulnerable position. They don’t ship features. They don’t close deals. They support the people who do those things, but that support is invisible until it’s gone. And by the time it’s gone, the decision has already been made.

The window for making your case isn’t when someone asks. It’s now, while the question is still hypothetical.

What executives actually hear

I’ve sat across the table from finance leads and product executives trying to explain design system value. I’ve watched their eyes glaze over at words like “consistency” and “scalability” and “design debt”. These aren’t bad concepts. They’re just not their concepts.

What they hear: overhead. What they’re calculating: headcount. What they’re comparing you against: the team that shipped the feature that closed the deal that hit the quarterly target.

I explored the challenge of communicating design value in Mastering design communication, drawing on Tom Greever’s framework for articulating design decisions. The same principles apply here, amplified by higher stakes. You’re not just explaining a design choice, you’re explaining why your role should continue to exist.

The research on efficiency gains is useful ammunition. Studies from Klüver, Slack, Ray, and others consistently show that design teams see efficiency gains around 38% when using a mature design system. Development teams see gains around 31%. The Sparkbox study with IBM’s Carbon design system found 47% faster development time compared to building from scratch.

Those are significant numbers. But they only matter if you translate them into language executives already use.

Take your team’s average hourly cost. Multiply by the hours the system saves per project. Multiply by the number of projects per quarter. That’s not “efficiency.” That’s money not spent. That’s headcount not hired. That’s runway not burned.

The conversation changes when you stop defending consistency and start quantifying capacity.

Building the case before you need it

The best time to plant a tree was twenty years ago. The second best time is now. That same logic applies to advocating for your work.

If you’re not already tracking component usage across your products, start today. Being able to demonstrate that a component appears in 75% of your features next quarter carries more weight than arguing for consistency in the abstract. In The component adoption gap, I wrote about how measuring what matters shapes behaviour. The same applies here: usage data isn’t just metrics. It’s evidence that the system is load-bearing infrastructure, not optional tooling.

Document time savings in terms that finance understands. "Faster iteration" means nothing to a CFO. "We saved eleven days of engineering time on the authentication flow" does.

Identify the specific workflows that would break without your work. If the design-to-development handoff relies on tokenised values and documented component specs, be explicit about what that process looks like without those resources. I explored this dynamic in From handoff to harmony, where I argued that the best work happens through continuous collaboration, not transactional handoffs. The infrastructure enabling that collaboration is exactly what disappears when design system roles get cut.

Connect your value to metrics that already have executive attention. Reduced time-to-market matters when you’re competing for customers. Consistent user experience matters when you’re trying to retain them. Accessibility compliance matters when you’re trying to avoid legal exposure. I’ve written about accessibility as infrastructure that scales across entire workflows. None of these are design system metrics specifically, but all of them depend on the work design system practitioners do.

What to protect when you can’t protect everything

Sometimes you don’t win the argument. Sometimes the cut happens anyway, and the question becomes what to preserve with whatever resources remain.

Protect the foundations

Tokens, core components, and the documentation that makes them usable represent the highest-leverage investment. Without these, teams can’t build consistently even if they want to. Cutting here saves money today and costs significantly more to rebuild later.

Protect the handoff infrastructure

Whatever mechanism exists for designers and developers to share intent, keep it working. Broken handoffs multiply effort across every team that depends on the system.

Consider pausing expansion

New components, experimental patterns, aspirational features: these are the first candidates for reduction. You can resume building them when conditions improve. The core that supports current production needs to keep running.

Be honest about maintenance debt

If you’ve been deferring cleanup work, now isn’t the time to address it. Focus on preventing new entropy rather than fixing accumulated issues. That debt will still be there when you have capacity.

Re-evaluate governance overhead

Complex approval processes and extensive documentation requirements have costs. In lean times, lighter governance that maintains quality without blocking teams might be more sustainable than comprehensive processes that slow everyone down. In Encouraging design system adoption, I wrote about balancing control with collaboration. That balance moves when resources contract.

Operating with less

Running design system work on reduced resources requires different priorities than running it with full support. The goal combes stability rather than growth.

Shift toward reactive maintenance rather than proactive improvement. Address issues as they arise rather than anticipating them. This isn’t ideal long-term, but it preserves usability while minimising ongoing investment.

Empower teams to contribute rather than depend. A federated model – where product teams can extend the system within guidelines – distributes the maintenance burden. The risk is inconsistency. The benefit is sustainability when you can’t staff dedicated roles.

Automate what you can. Usage analytics, linting rules that enforce token usage, documentation that generates from component code. These reduce the manual effort required to keep things healthy. Upfront investment in automation pays dividends when you’re stretched thin.

Document ruthlessly. When you can’t maintain active support, good documentation becomes your only scalable way to help teams use the system correctly. Prioritise the documentation that prevents the most common mistakes.

Communicate constraints openly. Teams that understand resources are reduced will adjust their expectations. Teams that don’t will lose trust when they can’t get support. Transparency prevents frustration from turning into abandonment.

The long game

Economic conditions change. Budgets that contract eventually expand again. The question is what position you’ll be in when that happens.

Organisations that eliminate design system roles during downturns face a choice when growth resumes: rebuild capability from scratch, or continue operating without it. Neither option is cheap. Rebuilding costs years of work and institutional knowledge. Continuing without the capability means every team solves common problems independently.

Organisations that maintain even minimal investment during lean periods preserve the option to scale back up efficiently. The foundations remain intact, the knowledge stays, and the path from reduced operation to full capacity is measured in months rather than years.

This is the argument I’ve found most effective with stakeholders who think in strategic timeframes. Design system work isn’t just about current efficiency, it’s about preserving the ability to move quickly when conditions improve. Cutting it entirely isn’t a temporary cost saving. It’s a long-term capability sacrifice.

The executives making budget decisions today will be the ones explaining velocity problems in eighteen months. Give them the information they need to make a different choice.

The spreadsheet is already open

Somewhere in your organisation, someone is looking at numbers. They’re looking at headcount. They’re looking at initiatives that don’t directly ship features. They’re looking for things that seem optional.

Your role is on that list. It might not be at the top yet. But it’s there.

You have two options. Wait until someone invites you to defend your work, by which point the frame has already been set against you. Or start making the case now, on your terms, in language that matters to the people making decisions.

Gather your usage data. Calculate your efficiency metrics. Translate your value into money. Identify the minimum viable investment required to maintain stability. Prepare to propose trade-offs rather than simply defend the status quo.

And be willing to make real concessions. The people asking hard questions about your role aren’t wrong to ask them – resources are genuinely constrained. Demonstrating that you understand the pressure and can operate sustainably within tighter constraints builds more credibility than insisting nothing can be cut.

I’ve watched design system practitioners lose their roles because they couldn’t articulate their worth in terms that mattered to decision-makers. I’ve also watched practitioners survive and even strengthen their position because they understood how to communicate value, propose alternatives, and operate flexibly when conditions demanded it.

The difference rarely comes down to the quality of the work itself. It comes down to whether anyone made the case before the meeting happened.

---

Thanks for reading! Subscribe for free to receive new posts directly in your inbox.

This article is also available on Medium, where I share more posts like this. If you’re active there, feel free to follow me for updates.

I’d love to stay connected – join the conversation on X and Bluesky, or connect with me on LinkedIn to talk design systems, digital products, and everything in between. If you found this useful, sharing it with your team or network would mean a lot.