skip to content

In a design system, product teams' contributions sit in review for weeks and teams stop contributing; how do you diagnose and fix the process?

level: seniorimportance: should knowfreq 28%

answer

  1. measure before blaming reviewers
  2. time spent in each stage
  3. who owns intake?
  4. agree the need before building
  5. tiered paths and written templates

basics

~20 s

Measure where contributions stall across proposal, review, build and release, then fix that cause: a named intake owner with a response target, tiered paths for small fixes, an early proposal checkpoint, and published guidelines and templates.

solid answer

~40 s

First I would measure where contributions actually stall rather than guess: time to first response, time in each of proposal, review, build and release, and the reasons for rework or rejection. The usual causes are nobody owning intake, one heavy path for every change, contributors building before the need is agreed, and expectations that live only in reviewers' heads. The fixes follow: a named intake owner with a response target, **tiered paths** so fixes ship fast, a short **proposal checkpoint** before anything larger is built, published guidelines and templates linked to the release-readiness bar, pairing on big contributions, and review capacity budgeted as planned work. Then I would re-measure and share the numbers with contributing teams.

go deeper

for a junior

Recall the four stages a contribution passes through, and that a long stall in any one of them discourages teams from contributing again.

for a middle

Explain the common causes of stalls: no intake owner, one heavy path for all changes, building before the need is agreed, and expectations that are never written down.

for a senior

Lead with diagnosis from real data, time per stage and rework reasons, then targeted fixes such as an intake owner, tiered paths, an early proposal checkpoint and budgeted review capacity.

for a principal

Treat the contribution process as a service with a budget: decide how much system-team capacity it deserves and how you would judge whether that investment is paying back.

## The symptom and why it matters A design system that relies on product teams to contribute depends on contributors believing their effort will land. When contributions sit in review for weeks, that belief erodes quickly: teams stop proposing changes, build local workarounds instead, and the system falls behind product needs. A slow **contribution process**, the path from proposal through review, build and release, is therefore not a minor irritation but a threat to the system's relevance. The fix starts with finding where time is actually lost, not with assuming reviewers are careless. Contributors who give up rarely say so; they simply stop filing requests, so the silence itself is the signal. ## Diagnose: find the stalled stage Pull the last few months of contributions and record how long each spent in each stage. The pattern usually points at one or two stages: | Stage | What a stall looks like | Likely cause | |---|---|---| | Proposal | Requests sit with no response at all | Nobody owns intake or triages new requests | | Review | Long back-and-forth over many rounds | Guidelines are unclear, so submissions arrive under-specified | | Review | Rejection after weeks of work | The need was never agreed before building started | | Build | The contributor gives up midway | The quality bar is unknown, or too heavy for the tier | | Release | Merged work waits for a distant release | Contributions queue behind unrelated system work | Also read the rework and rejection comments. If the same feedback appears again and again (missing states, raw values instead of tokens, no documentation), the written guidelines are not doing their job. ## Common root causes - **No intake owner.** Requests arrive in a shared place and everyone assumes someone else will answer. - **One heavy path for everything.** A typo fix waits in the same queue, with the same reviewers, as a new component. - **Late alignment.** Contributors build first and propose second, so disagreement about whether the system should own the component surfaces only at the end. - **Unwritten expectations.** What a contribution must include lives in reviewers' heads, so each reviewer asks for something different. - **Capacity mismatch.** The system team treats contribution review as spare-time work behind its own roadmap. ## Fixes 1. **Name an intake owner and a response target.** Someone triages every new request within an agreed time, even when the answer is 'not now'. A fast, reasoned no usually preserves trust better than silence. 2. **Tier the path.** Fixes get light review and ship quickly; enhancements get design and API review; new components get a proposal review before any build. Each tier lists exactly which reviews it needs, so no change waits for reviews it does not require. 3. **Add an early checkpoint.** For anything beyond a fix, require a short proposal and a quick decision before the build starts, so nobody invests weeks in something the system will decline. 4. **Publish guidelines and templates.** Write down what each tier must submit and link the release-readiness bar, so reviewers stop inventing requirements and contributors can check their own work. 5. **Pair on larger contributions.** A system team member co-builds with the contributor, which transfers conventions faster than rounds of review comments. 6. **Budget review capacity.** Treat contribution review as planned work with its own allocation, not something done when the roadmap allows. ## Keep the fix honest Measure the same things again after the changes: time to first response, time in each stage, the share of contributions that merge, and the most frequent rework reasons. Share these numbers with contributors, because visible improvement is what brings them back. Rising contribution volume with falling time in review suggests the process works; a falling merge rate after adding a checkpoint may mean the proposal step has itself become the new bottleneck, and needs trimming to a genuinely short decision. The underlying principle is that a contribution process is a service the system team offers to product teams. It should be designed like one: clear entry points, predictable waits, and effort matched to the size of the request. That holds whether the contributing teams build for the web, for native mobile or for the design library.

  • Why can a fast rejection be better for contributors than a slow approval?
    Contributors plan around predictability. A quick, reasoned 'not in the system' lets a team build locally and move on, and tells them what evidence would change the answer. A request that waits weeks without a decision blocks their feature and teaches them to skip the system next time, which costs the system future contributions.
  • After adding a proposal checkpoint, contributions got slower. What likely went wrong?
    The checkpoint probably became a heavy document review instead of a quick decision. A proposal step should be short, a few paragraphs on the need and context, answered within a fixed time. If proposals queue for weeks, the same stall has simply moved earlier. Measure time-to-decision at that step and cut what it asks for.

saying these in an interview costs you the question

  • Reviewers are simply slow; asking them to try harder will fix it.
  • Lowering the quality bar is the best way to speed up contributions.
  • Every contribution needs the full review, even a one-line fix.
  • Leaving a request unanswered is kinder than rejecting it outright.
  • Contributors should build first and only propose once the code is ready.