What are the trade-offs between staffing a design system with a dedicated team, part-time contributors, or a hybrid of both?
answer
- whose job is the system
- focus versus closeness to products
- deadlines eat part-time allocations
- small core plus rotating contributors
- staffing sets what you can promise
basics
~20 sA dedicated team brings focus, quality and a roadmap but costs more and can drift from product needs. Part-time contributors are cheap and close to real problems but lose time to deadlines. A hybrid, a small core plus allocated contributors, balances both.
solid answer
~40 sA **dedicated team** has people whose full-time job is the system: it can keep quality, documentation and support consistent and plan a roadmap, but it is a visible cost and risks building what it finds interesting rather than what products need. **Part-time contributors** from product teams are cheap and bring real problems, but product deadlines win whenever they collide, quality varies, and nobody is accountable when things decay. A **hybrid**, a small dedicated core plus contributors with explicit, protected allocations or rotations, is the most common compromise: the core owns quality and continuity while contributors keep it grounded. The model also sets what the system can promise: support responsiveness, the number of platforms covered and release cadence all follow from how many hours are really staffed.
go deeper
Recall the three models, dedicated, part-time and hybrid, and one strength and one weakness of each.
Explain how each model typically fails, distance for dedicated teams and erosion for part-time ones, and why hybrid allocations must be protected.
Show how you would choose and adjust a model for a real multi-platform product, and scope what the system promises to the hours actually staffed.
Treat the staffing model as a funding and organisational decision, and plan how it should evolve as consuming teams and platforms grow.
## Why staffing is a real design decision A design system is a product with consumers, and like any product it is only as reliable as the people who look after it. How it is staffed determines what it can promise: how fast bugs are fixed, how many platforms are covered, whether documentation stays current, and whether anyone answers questions. Interviewers ask this to see whether a candidate can match a staffing model to an organisation rather than naming one as always right. Staffing is a different question from **decision rights**, meaning who approves changes and how ownership is distributed. A team can be dedicated and still share decisions widely, or part-time and still have one final approver. This answer covers who does the work. ## The three models | Model | What it looks like | Strengths | Weaknesses | |---|---|---|---| | **Dedicated** | Designers and engineers whose full-time job is the system | Focus, consistent quality, a roadmap, continuity, time for documentation and support | Visible cost; can drift from product needs; can become a bottleneck | | **Part-time** | Product-team members spending a share of their time on the system | Cheap; contributors bring real needs; ownership spread widely | Product deadlines win; quality varies; accountability is unclear; progress stalls | | **Hybrid** | A small dedicated core plus contributors with allocated time or rotations | Continuity from the core, relevance from contributors | Needs coordination; allocations must be protected; the core can still be overloaded | ## How each model fails - **Dedicated teams** fail by distance. Without regular contact with product teams they polish components nobody asked for, and product teams route around them. - **Part-time models** fail by erosion. An allocation of “a fifth of your time” disappears the first time a release is late. The system then decays quietly: bugs linger, documentation goes stale, and trust drops. - **Hybrids** fail when the contributor allocation is informal. If product managers can reclaim it at will, the hybrid collapses into an overloaded core. ## A worked example: a fitness-tracker companion app A company ships a companion app for its fitness tracker on two phone platforms, a simplified interface on the wearable itself, and a web dashboard. Four product teams (activity, sleep, coaching and device setup) all need charts, metric tiles and goal-progress rings. 1. **Part-time** might work at first: an engineer from activity and a designer from coaching maintain the shared chart and tile components. When the sleep team’s launch slips, both are pulled back, and the wearable versions of the components fall behind. 2. **Dedicated** would give the components an owner, but a team of five building for four platforms without contact with the product teams risks building charts that do not fit the coaching team’s real data. 3. **Hybrid**: two dedicated people own the foundations and the most shared components, and each product team contributes a person for a rotation of a few weeks each quarter. The rotation brings real needs into the system and spreads knowledge back out. ## Choosing a model - **Number of consuming teams and platforms**: more consumers and platforms usually justify a dedicated core. - **Maturity**: early systems often start part-time; sustained growth usually needs someone whose job it is. - **Budget and sponsorship**: a dedicated team needs funding someone will defend. - **What must be promised**: if product teams depend on the system for releases, somebody must be accountable for its responsiveness. ## Signals that the model needs to change - Bugs in shared components stay open for weeks because nobody has time to fix them. - Product teams keep local copies because the system cannot respond fast enough. - The dedicated team’s roadmap is full of work no product team requested. - One or two people hold all the knowledge, so a single departure would stall the system. - New platforms, such as another wearable, are added to the product faster than the system can follow. Each signal points in a direction: slow fixes and missing continuity argue for more dedicated capacity; irrelevance argues for more contact with product teams. ## Making any model work - Write down allocations and protect them explicitly; an informal share of time is the first thing cut. - Keep dedicated staff in regular contact with product work through pairing, embedding or rotations. - Scope promises to real capacity: fewer platforms supported well beats many supported poorly. - Revisit the model as the organisation grows; the right answer for two teams is rarely right for twenty.
- How do you keep a dedicated system team close to product needs?Build regular contact into the work: pair with product teams when they adopt a component, embed a system engineer in a product team for a period, run rotations that bring product engineers into the system team, and review real product screens rather than only the component catalogue. Prioritising the roadmap from observed product problems, not internal ideas, keeps the dedicated team solving what consumers actually face.
- What makes a part-time allocation hold up under deadline pressure?It must be explicit and agreed with the people who set product priorities, not just with the contributor. A named person, a defined share of time or a fixed rotation, visible in planning, is harder to reclaim than a loose intention. Even then, expect it to bend during crunches, which is why a small dedicated core is often needed for continuity.
saying these in an interview costs you the question
- Claims a dedicated team is always the correct model at any size.
- Assumes part-time contributors reliably keep their allocated system time.
- Confuses who does the work with who holds decision rights.
- Expects a two-person core to support every platform equally well.
- Believes a dedicated team needs no contact with product teams.