Most design organizations do not have DesignOps. They have a design leader doing DesignOps between meetings, badly, at the expense of the work they were hired for.
That is not a criticism of the leader. It is a description of what happens when a function is necessary, unglamorous, and never gets its own headcount.
What the work actually is
DesignOps is easy to caricature as process and tooling. The real scope is wider and more consequential, and it is worth listing because the list is what makes the case.
Staffing and coverage. Who is on which squad, at what ratio, against which priority. Rebalancing when a launch pulls someone sideways. Noticing when an initiative has quietly gone from two designers to one.
Rituals. Critique that converges instead of circling. Design review with a decision at the end. Onboarding that gets a new designer productive in two weeks rather than two months. These are not meetings, they are the mechanisms by which quality is produced at scale, and they degrade without maintenance.
The design system as a service. Intake, triage, contribution paths, adoption tracking, deprecation. A design system without operations is a component library with a backlog.
Hiring and growth. Pipeline, interview loop, calibration of what "senior" means, career ladders, promotion evidence. Most of this is invisible until it fails.
Tooling and access. Licenses, permissions, file structure, naming, the archaeology of where things live. Small individually, and collectively responsible for a startling amount of lost time.
Reporting. The quarterly account of what the organization did and what it returned. Currently produced by hand, from memory, by the most expensive person available.
Every one of these gets done in every design organization. The only question is whether anyone owns it.
Why it does not get staffed
The economics are hostile in a specific way.
A DesignOps hire produces no visible artifact. In a headcount conversation, that role competes against a product designer who will demonstrably ship screens for a team that is demonstrably asking for one. The DesignOps case is a second-order argument about capacity leverage, made to people who are optimizing first-order output, and it loses reliably.
So the work does not disappear. It redistributes. It lands on the design leader, who does it at the cost of strategy and hiring, and on senior ICs, who do it at the cost of the design work they were promoted for. Both are the most expensive labor in the org, and both are doing it as a tax on their actual job.
The zeroheight Design Systems Report 2026 captures where this ends up in one place. 56 percent of design system teams name staffing as their single biggest challenge, ahead of buy-in and tooling. 61 percent say they do not have enough people. 61 percent are five people or fewer, and 16 percent of design systems are maintained by exactly one. Only 23 percent agree they have adequate resources.
Nielsen Norman Group's assessment across around 500 companies with UX teams found organizations doing roughly 22 percent of recommended DesignOps efforts. Not 22 percent of an aspirational maximum. Roughly a fifth of the baseline.
The cost of leaving it unowned
When nobody owns operational work, it does not stop. It gets done reactively, by whoever notices, at the worst possible moment.
Coverage rebalancing happens after a project has already slipped. Onboarding gets improvised, so a new hire takes an extra month to become useful. Design system requests get handled as favors, so there is no queue, no prioritization, and eventually four teams build the same component. Promotion evidence gets assembled in a panic. The quarterly report gets written the night before.
None of these produce an incident anyone investigates. They produce a slow, constant tax that shows up as the organization being mysteriously slower than the sum of its people, which is exactly the symptom design leaders describe and cannot diagnose.
The part that is genuinely automatable now
Here is what has changed, and it is the reason this post exists rather than being another argument for a headcount nobody is going to approve.
A large share of DesignOps work is not judgment. It is assembly: gathering scattered facts into a form somebody can act on. Who is on what. What moved this week. Which requests are queued. What this person contributed. What we said we would do versus what we did.
Assembly is the part that consumes the hours, and it is now the part a system can do, because the underlying facts are already being generated as a side effect of the work. Figma knows who edited what. Linear and Jira know what moved. Slack holds the decisions. The research repository holds the studies. What has never existed is anything that reads across them and holds the relationships.
The judgment stays human, and should. Whether a squad is under-resourced given its strategic weight, whether a designer is ready for promotion, whether a ritual is failing because of the format or the people, whether to fight for a headcount or spend the political capital elsewhere. That is the job. It has always been the job. It has just been buried under assembly work that had to be done first.
What to do if you cannot hire for it
Three moves, roughly in order of return.
Name the work, even without an owner. Write the list. Put each item next to whoever is actually doing it today. The exercise alone usually surfaces that three senior ICs are collectively spending a day a week on operations nobody planned for, which is both a real finding and the beginning of a headcount case grounded in something.
Kill the manual assembly first, not the judgment. The status roll-up, the allocation sheet, the quarterly deck. These are the highest-hours, lowest-judgment items and the ones most likely to be automatable from records that already exist. Recovering that time is worth more than optimizing any single ritual.
Make the case with the coverage number, not the principle. "We need DesignOps because operations matter" loses. "Three of our five strategic initiatives are covered by a single designer each, and here is how that changed over the quarter without anyone deciding it" is a different conversation, because it is about risk to work the business already said it cared about.
DesignOps is the function that turns a group of designers into a design organization. The reason it is chronically unstaffed is not that leaders undervalue it. It is that the case for it has always had to be made from principle, by the person with the least time to make it, without the numbers that would settle it.
That last part is the one worth fixing first.