On a government benefits application, the design-system team rejects a service team's document-upload component a month before a policy deadline; how should the disagreement be escalated and resolved?

## Disagreement is normal In a **design system** shared by many product teams, the system team and a product team will regularly disagree — about whether a component belongs in the system, whether a change is worth its cost, or whether a deadline justifies an exception. Disagreement is not a sign that governance failed; having **no agreed way to resolve it** is. Without a path, the product team either waits and misses its date, or quietly builds its own version and the system fragments. The scenario: a government benefits application is built by several service teams. The team running evidence submission needs a **document-upload** component to meet a policy change that takes effect in a month. The system team rejects it for the shared library as a one-off. ## Step 1 — Make the disagreement specific - The system team states, **in writing**, which published criterion the proposal fails: the need is unique to one service, it overlaps an existing file input, or nobody will maintain it. - The service team answers with **evidence**: other services (appeals, change of circumstances) also collect documents; users are struggling with the current approach in testing. - Often this step alone resolves it — either the criteria were misapplied, or the service team sees why a local build is right. ## Step 2 — Separate the deadline from the decision Two questions are tangled together: *can the service ship on time?* and *does this component belong in the shared system?* Only the first is urgent. A **sanctioned local component** answers it: 1. It is built from system tokens and existing parts, so it looks and behaves like the rest of the service. 2. It meets the **full accessibility bar** — a deadline can relax whether a component joins the system, never whether it works for disabled users, who are a core audience of a benefits service. 3. It is **registered** with the system team, so it is visible rather than hidden. 4. It carries a **review date**, after which it is either promoted, replaced or kept local on purpose. ## Step 3 — Escalate through a known path If the disagreement about system membership remains, escalate — but through a path agreed before anyone needed it: 1. **Working level**: the designers and engineers involved, with the criteria in front of them. 2. **Leads**: the system team lead and the service's product lead. 3. **Governance forum**: a council or design leadership group with representatives from several services, which decides against the same published criteria. Each step is **timeboxed** — a common practice is days, not months — so escalation does not become a way to run out the clock. The forum's decision is binding for both sides. ## What the outcomes look like | Outcome | What happens next | |---|---| | System team was right: genuinely one-off | The local component stays local, owned by the service team, reviewed at its date | | Service team was right: shared need | Upload enters the system roadmap; the local build becomes the starting point for a contribution | | Partly both | The pattern is documented now; a shared component follows when a second service needs it | ## Record it Write the decision, the reasons and the criteria applied into a **decision log**. The next time a team proposes a similar component, both sides start from precedent instead of re-arguing, and if the criteria themselves turn out to be wrong, the log shows where to change them. ## Who owns the escalation path An escalation path only works if it exists before the dispute. It is typically written into the governance charter: which forum decides, who sits on it, how quickly each step must respond, and whether its decision is binding. Two properties matter most: - **Representation**: the forum includes people from several services as well as the system team, so a ruling does not look like the system team judging its own case. - **Named people**: each step names a role, not 'leadership', so a team knows exactly whom to approach next. ## Anti-patterns - A system team acting as a **gatekeeper with no appeal**, which teaches teams to route around it. - A product team **silently forking** the component, which hides the need from the system. - Escalating straight to the most senior executive, who lacks the context and sets a precedent of bypassing the forum. - Letting the deadline win the membership argument by default, which fills the shared system with one-offs.