Most governance writing in the design systems world assumes a team with a dedicated DS lead, a rotation of contributing designers, an engineer liaison, and quarterly planning cycles to align on roadmap. That structure is appropriate for a design org with 20 or more people. It does not describe how governance actually works in a team of two designers and one front-end engineer, which is what most early-stage product teams look like when they start taking their design system seriously.
Governance is not a large-team problem. If anything, small teams need it more, because there is less informal redundancy. In a team of 15, someone usually notices when a token is being used incorrectly because three other people are working in adjacent components. In a team of three, a bad pattern can propagate through an entire component library before anyone notices.
What governance actually means at this scale
At the two-to-five person scale, governance is not a process or a committee. It is a set of answers to three questions that everyone on the team can answer consistently without asking each other:
First: who is allowed to add a new token, and what information is required before adding it? Second: what happens when a new component needs a pattern that the system does not currently support? Third: how are breaking changes to existing tokens communicated and rolled out?
If everyone on a three-person team can answer all three questions without disagreement, you have a working governance model whether or not you have named it that. If the answers differ, or if no one has ever discussed them explicitly, the system will drift regardless of how clean the initial structure was. A governance conversation is just this: getting the team to agree on answers to those three questions and writing them down somewhere accessible.
The decision record as a minimum viable governance artifact
Large-team governance frameworks often involve change request forms, approval workflows, deprecation boards, and documentation sprints. For a team of three, most of that is overhead. The minimum viable artifact is a decision record: a short log of significant token and component decisions, written at the time of the decision.
A decision record entry does not need to be long. It needs to answer: what was decided, why it was decided (what alternatives were considered), and what parts of the system it affects. A token addition like adding --spacing-component-card-gap instead of using the existing --spacing-md warrants one paragraph explaining why a component-scoped token was the right choice over a general-purpose one. That paragraph, written when the decision is fresh, is worth more than a year-end documentation sprint.
The value of decision records compounds when someone joins the team. A new designer on a three-person team cannot ask "why does the button have its own border-radius token instead of using the global radius scale?" and expect a confident answer a year later. The answer in the decision record can be consulted even if the person who made the original decision has left.
Token stewardship without a dedicated DS team
In a team of two designers and one engineer, there is usually no one whose full-time role is design system stewardship. Governance without a dedicated owner runs a predictable failure pattern: everyone assumes someone else will catch inconsistencies, so no one does, and drift accumulates unchecked.
The fix is explicit rotation, not a new hire. Designate one person per sprint as the token steward for that sprint. Their job is not to solve problems, it is to notice them: scan for tokens that were added without a corresponding semantic layer entry, catch hardcoded values in component definitions that should be token references, check whether any new component introduced a duplicate of an existing token under a different name. An hour of structured review per sprint, rotated among team members, catches most of the mechanical drift that accumulates over time.
We are not suggesting this is equivalent to a full-time DS role. It is a minimum floor. A team that does this consistently will have fewer structural problems when they do eventually hire a DS lead or scale their design org, because the system has not been drifting unchecked for eighteen months before that hire happens.
Handling requests that the system does not yet support
This is the most common governance friction in small teams: a designer needs a component state or a layout pattern that does not exist in the design system yet. The paths available are: build it into the system properly, use the closest existing pattern with an agreed deviation, or add a one-off that everyone acknowledges will need to be brought into the system later.
All three paths are sometimes correct. The failure mode is not choosing a path; it is having no explicit agreement about which path was chosen. A one-off that everyone understands is a one-off is manageable. A one-off that gets treated as a system pattern because no one noted it as a temporary deviation is a governance failure that shows up as inconsistency in the production codebase six months later.
The practical mechanism: a brief comment in the component file or design layer noting whether a given pattern is system-canonical, a pending system addition, or an acknowledged exception. Not documentation for its own sake. Just enough signal that when someone reads that file later, they know what category of decision they are looking at.
Breaking changes: communication at small scale
Token renames and value changes that break downstream implementations are one of the highest-cost events in a small team's design system lifecycle. A rename from --color-primary to --color-interactive-default might touch every component in the library. In a large team, this is handled through deprecation periods, migration scripts, and announced release cycles. In a team of three, the equivalent is a single shared message that explains what changed, why it changed, what needs updating, and by when.
The mistake to avoid is treating a small team as meaning no announcement is needed because everyone was present for the decision. Even if all three people were in the meeting where the rename was agreed, the implementation work is distributed. Someone will encounter the old token name in production code three weeks later and not remember whether it was supposed to have been migrated. The small-team version of a breaking change announcement is not a formal deprecation notice; it is a single clear message in whatever channel the team uses for coordination, written at the moment the change is committed.
What over-governing looks like at this scale
There is a failure mode in the other direction. A team of three that installs a full change-request workflow, approval queues for every token addition, and monthly steering committee reviews will spend more time governing the system than using it. The overhead is not appropriate to the scale, and it creates resentment toward governance as a concept rather than a specific implementation.
The right calibration for a team of two to five is: explicit answers to the three core questions, a decision record that logs significant choices, sprint-rotation stewardship to catch mechanical drift, and a clear communication habit for breaking changes. That is the overhead the system actually needs at this scale. Everything beyond that is borrowed from a larger-team playbook and should be added only when the team size warrants it.
