In every role I have held, the dilemma was the same.

The design system needed someone to hold the long view. To sit in the roadmap meeting and say — not loudly, not with a title that justified the intervention — that the decision being made in this room would create a problem in four sprints that nobody here would want to own. To show up in the budget conversation and make the case for infrastructure investment that produces no visible feature and no deliverable that fits on a slide. To operate, in practice, as the organizational strategist for how design and engineering stay aligned across time — without anyone having formally asked for that role to exist.

I worked undercover sometimes. Not deceptively. Practically. The mandate was not going to be given. So I gave it to myself and did the work quietly until the results made the argument I had not been invited to make out loud.

The pushback I encountered most often was not from leadership. It was not from engineering. It came from designers. The people who should have been the system’s most natural allies. The people whose work the system was built to serve. They saw the system as a constraint on their craft — a set of rules that reduced design to assembly. They were not wrong that constraints exist. They were wrong about what the constraints were for.

The most isolating place to lead a design system is inside a design team that has not yet decided whether the system is a tool or a threat. I have been in that place more than once. I never fully resolved it. I learned to work inside it.


What the Role Actually Is

The design system lead is described, in most job descriptions, as someone who builds and maintains a shared component library. Ensures consistency across products. Partners with engineering. Advocates for design standards.

All of that is true. None of it is the job.

The job is to hold the long view on how design and engineering stay aligned across time, teams, and competing priorities. That view requires understanding not just what the system contains but what the organization needs the system to do five quarters from now — and what is currently being built that will make that harder. It requires reading organizational behavior well enough to know when a decision is about the system and when the system is just the surface on which a different argument is happening. It requires being the person who names what is actually going on in the room when everyone else is discussing the component.

Nobody teaches this in a design program. Nobody lists it in a job description. It accumulates. Role by role. Failure by failure. Every broken process is a curriculum.

The design system lead is not a component builder who got promoted. They are an organizational strategist who happens to work in design. The distinction matters because the skills are different, the failures are different, and the loneliness is different.

What the Work Teaches You

Design systems work does something to a practitioner that no other design discipline does in quite the same way. It forces a relationship with organizational dysfunction that is not optional and not temporary. You cannot design a governance model without understanding the political structure it has to survive inside. You cannot build a contribution process without understanding what motivates a designer to contribute and what motivates them to work around the process instead. You cannot deprecate a component without understanding that the resistance is never really about the component.

What the work gave me was leverage. Not political leverage — the leverage of someone who has seen more failure modes than anyone else in the room and is no longer surprised by any of them. Every role added a new failure to the library. Every failure clarified something about how organizations actually behave versus how they describe their own behavior. That gap — between the stated process and the actual one — became the thing I could read that most of my colleagues could not.

It also gave me the ability to stop being disappointed. Not because the disappointment stopped being warranted. Because I understood where it came from. A broken process is not a personal verdict. It is an organizational condition. You can work inside it, work around it, or leave. What you cannot do — if you want to stay functional — is take it personally every time.

This is the thing design systems work teaches that no other design discipline advertises. Not the craft. Not the systems thinking. The emotional architecture of working inside dysfunction without being consumed by it. The ability to be effective inside a broken process while simultaneously understanding exactly how broken it is.

If I could not fix what was broken — I learned something new. That is not consolation. That is the operational philosophy that makes a twenty-year career in this work survivable. And occasionally, against the odds, effective.


The Three Things the Role Requires That Nobody Prepares You For

One — The Ability to Hold Authority Without the Title

The design system lead rarely has organizational authority commensurate with the scope of their responsibility. They influence decisions they do not own. They are accountable for outcomes they cannot control. They sit in rooms where the decisions that will affect the system are being made by people who do not think of the system as relevant to those decisions.

Holding authority without the title means making the argument so clearly, so specifically, and so connected to what the other person actually cares about — that the argument makes itself. It means knowing when to speak and when to let the consequences of a decision become the argument. It means accepting that some battles are not winnable in the room and positioning for the moment after the room when the prediction proved correct.

This is not a political skill. It is a patience skill. And it is the one the job requires most.

Two — The Ability to Manage Resistance From Allies

Leadership resistance is manageable. You know where it comes from — budget, timeline, competing priorities. You can build the case. You can find the metric that matters to the person holding the objection and connect the system to it.

Designer resistance is different. It comes from identity. A designer who sees the system as a constraint on their craft is not making a budget argument. They are making an argument about what design is for. That argument cannot be won with data. It has to be won through the work itself — by demonstrating that the system creates more creative freedom than it removes, not by asserting it.

The most technically correct design system in the organization can be undermined by three designers who feel it diminishes their craft. That is not a governance problem. It is a narrative problem. And the design system lead has to hold both.

Three — The Ability to Stay Curious About Failure

Every design system fails at something. The contribution model does not hold. The adoption stalls. The governance collapses when a key person leaves. The token architecture drifts. The handoff process returns to being a meeting.

The practitioners who stay effective over time are not the ones who avoid failure. They are the ones who stay curious about it. Who treat every collapse as a diagnostic rather than a verdict. Who can be inside the failure — and still be asking what it is teaching them rather than what it says about them.

The design system is never finished. Neither is the person who leads it. Both are continuous works in progress operating inside organizations that are also continuous works in progress. The only version of this work that is sustainable is the one that finds the learning inside the failure every single time.


This week: write one sentence that completes this prompt.

This week: write one sentence that completes this prompt.

“Design systems work taught me _______ that I would not have learned if I had spent my career on product design instead.”

Not what the work produced. What the work taught. The skill, the tolerance, the organizational understanding, the emotional architecture that only comes from operating inside a shared system across multiple teams and multiple failures.

Write that sentence. Share it with one person who has been in this work as long as you have. Ask them if their sentence is the same. The gap between your two sentences is the thing the industry does not talk about often enough.


The Argument

The design system lead is the only person in the organization whose job is to hold the long view on how design and engineering stay aligned across time. Nobody gave them that mandate. The title does not confer it. The job description does not describe it. It is taken — quietly, practically, role by role — by practitioners who understood before anyone else that if they did not hold it, nobody would. The work is organizational strategy executed through craft. The leadership is influence exercised without authority. The resilience is a philosophy built from the accumulated evidence of every broken process that did not break the person working inside it. If you could not fix what was broken — you learned something new. That is the career. That is the role. That is the point of all of it.


💡
Whether you agreed with everything in this article — or spent it thinking about the role you have been playing in your organization that nobody officially asked you to play — the argument is now yours.

Disagree loudly. Inspire boldly.

And remind me — falsely if needed — that somewhere a design system lead was given a clear mandate, a sufficient budget, and a design team that unanimously believed in the work.


Before you go, entertain this for a second

What has design systems work taught you that no job description prepared you for?