2026-09 · 4 min read
The work that disappears when it works
DesignOps succeeds when friction disappears. But if the work itself becomes unobservable, organizations lose the evidence they need to sustain it.
There is a particular kind of success that produces almost no evidence of itself.
Infrastructure has this quality. Roads recede into the background when traffic moves. Water systems are rarely discussed when water arrives. The better the infrastructure performs, the less attention it demands from the people using it.
DesignOps often works the same way.
When the operating system holds, files are where people expect them to be. Dependencies surface before they become blockers. Reviews happen at the right moment. Teams can find one another's work. The design system stays coherent. Nobody spends the morning wondering who owns the problem.
The friction disappears.
That is success.
But there is a distinction I have become more interested in: the friction should become invisible. The system producing that condition should not become unknowable.
Good operations should be quiet to use, not impossible to observe.
Preventative work creates a peculiar evidence problem.
A designer can point to an interface. A researcher can point to findings. Operational work often produces a counterfactual instead: the delay that did not happen, the duplicated effort that was avoided, the dependency resolved before it became urgent, the inconsistency that never reached production.
Those outcomes are real. They are also difficult to prove, because the strongest evidence is often an absence.
That creates a legitimacy problem. Organizations naturally recognize value that leaves artifacts behind. Features. Reports. Prototypes. Frameworks. Operational value is more often a condition: work moving with less friction, fewer surprises, and less avoidable coordination.
If that condition is taken for granted long enough, the infrastructure starts to look optional.
Usually until it breaks.
The tempting response is to make the operational work more visible.
More status decks. More process diagrams. More meetings explaining the meetings. More documentation proving that coordination happened.
I don't think visibility is the right goal.
The more useful idea is observability.
In engineering, an observable system leaves enough signals to understand how it is behaving without watching every internal action. DesignOps needs something similar. Not proof that someone was busy. Signals that the operating environment is getting healthier or less healthy.
How many dependencies remain unresolved? Where is work being duplicated? How long do teams stay blocked waiting for a decision? Which patterns repeatedly fragment across squads? Where does the same coordination problem reappear?
None of these measures DesignOps perfectly. That is not the point.
Together they make the condition of the system legible.
DesignOps should not make its activity visible. It should make the condition it creates observable.
This changes how I think about operational artifacts.
A portfolio view is not valuable because it proves that someone maintained a board. It is valuable when it reveals work that would otherwise collide.
A recurring concept-sharing ritual is not valuable because another meeting exists. It is valuable when dependencies surface earlier than they used to.
A quality review is not valuable because a checklist was completed. It is valuable when the same category of problem stops recurring downstream.
The artifact is only evidence. The condition is the outcome.
That distinction matters because it prevents DesignOps from becoming performative. The goal is not to leave more traces of the work. The goal is to leave the right traces — enough to understand whether the operating system is doing what it was designed to do.
There is a broader design principle here.
The best systems often reduce the amount of attention they require. But reducing attention is not the same as removing legibility. A system can be calm without becoming opaque. It can disappear from the user's immediate task while remaining inspectable to the people responsible for maintaining it.
That may be the right ambition for DesignOps as well.
Let the process recede. Let the coordination become easier. Let people forget how much friction used to be there.
But keep enough evidence that the organization can still understand what is holding the work together — and notice when that condition begins to change.
The work can disappear. The evidence should not.
This reflection draws on Susan Leigh Star and Karen Ruhleder's work on infrastructure as something that recedes into the background when it functions, and on the Site Reliability Engineering idea that reliable systems still need to remain observable.