Synoptro Blog

The transformation will be staffed eventually

Dennis Berger — Thu, 28 May 2026 12:55:00 GMT

It's conference season again. Adaptive DesignOps is the new framing; the banner on this year's Design Operations NYC says so, and a handful of Medium pieces filed since January echo it. The pitch: efficiency was the 2018-era DesignOps story, scaling was the 2022 one, and 2026's job is transformation. AI-native operating models, the dissolving boundary between DesignOps and ProductOps, AI as the new team member. It's a tidy story. The room I'm in tells a different one.

Three in five design system teams are understaffed, per zeroheight's 2026 Design Systems Report, up from last year. Only 44% have a dedicated DesignOps manager. I work inside one of those orgs full-time, and most of the people I talk to do too. The story and the room don't quite match.

This isn't surprising. The discourse always leads the staffing by a few years. Conferences need a story to sell, and "twice the work with the same headcount, again" doesn't fill an auditorium. But the gap is widening, and I notice what fills it. When the keynote tells me AI will be a true team member that balances bandwidth before a manager thinks about it, and the calendar I'm looking at has me running intake triage solo across four squads while a fifth waits its turn, I am not the manager who hasn't thought about bandwidth. I am the part of the org that was supposed to get the budget, the headcount, the productivity...and got this instead.

The transformation tax

A useful question to ask of any "DesignOps is becoming X" claim: who does the becoming?

If transformation is something a team does, fine, but a team needs people, and the staffing data says many of us are short the people. If transformation is something a tool does on the team's behalf, that's a different sentence with a different consequence. The version where AI takes on ops work that doesn't show up anywhere on the org chart is a real version. It's also the version where the headcount conversation goes only one way at the next budget cycle, and it's not the way the keynote implied.

I am not against the framing. Adaptive is a real word and the practice does adapt. I just notice that "adaptive" can describe a discipline gracefully accommodating a new tool, or a discipline absorbing the cost of being permanently under-funded. From the outside they look similar enough that the same talk can apply to both.

What the report actually says

The same zeroheight survey notes that DesignOps, accessibility, and content design are increasingly represented in design system teams. That's true; the roles exist and new openings still happen. What's also true: the representation is uneven, and the dedicated-DesignOps-manager number is under half. The teams with an ops layer are increasingly the ones whose design system survives a reorg. The teams without an ops layer are the ones whose design system degrades until the next rebrand.

That is the part of the story that has not become a conference theme: "Some of you will get the budget and some of you will not, and the ones who don't will be told the AI will take care of it" is a less appealing keynote.

Where the gap shows up

I don't know how to close this gap from inside a corporate job. I know the gap is real; I see it in the calendar of the people I talk to. I see it in the design system audits that take six months because there's one person doing them with only 20% their total capacity. I see it in the fact that the most common DesignOps job posting in 2026 is still "one person, multiple squads, build the function." The discipline has not been staffed to deliver the future that the conference keynotes describe.

What I can say with more confidence: when you don't know where the friction is coming from, the abstract talk about transformation lands poorly. It feels either aspirational or accusatory, depending on the day. The more useful move is usually pointing at the specific friction point (intake, handoff, the team's weekly rhythm, scoring of what got shipped) and describing what's actually breaking. Synoptro has a short diagnostic for this at synoptro.com/friction-finder. I built it because the question kept coming up and I wanted to stop answering it from scratch.

That conversation about the specific friction is what precedes any conversation about transformation, and it's what the budget cycle is actually going to be about. The pitch that lands with a CFO is "here are the three things breaking, here is what that's costing the company, and here is the smallest set of moves that fix it." That's the pitch the keynote can't make for us, because the keynote doesn't know our companies, our org charts.

The next year

I'd love for the adaptive-DesignOps framing to age well. Some of us will end up in the truly adaptive version and some in the work-absorption version, and which side of that you land on will depend less on the framing and more on whether the company funded the DesignOps role this cycle. The conferences will continue to tell a single story, because it feels good. The staffing data will continue to tell two stories at odds with each other, because it's the uncomfortable truth.

Of course, both can be true at once. We are adapting. We are also tired. The discourse is allowed to celebrate the first half, but we don't have to pretend the second half isn't there.

When juniors leave, the library remains

Dennis Berger — Thu, 14 May 2026 12:55:00 GMT

Nobody on your team has run a token audit in nine months and you know exactly why. The person who used to do it left in the spring. The role that would have replaced them didn't get backfilled. "We're being more selective at junior right now," went the all-hands. The work hasn't gone anywhere. It's just on the shelf.

The AI-and-design-jobs conversation has settled into a comfortable shape: designers are being sorted, not replaced. Template-pixel-pushers in trouble; strategic, systems-thinking, AI-fluent designers in growth. Job postings up at the senior end. Lenny's job market write-up has the numbers; Figma's State of the Designer has the sentiment. None of that is wrong.

The story stops at the sorting. It doesn't follow what the sorted-out people used to do.

Junior designers seeded the system. Not the first version of the design system. That was usually a senior or staff designer with a vision. The maintenance, though. The hygiene work. The audit-and-clean-up cycles that happen monthly, the new-component intake that gets triaged, the deprecated-token cleanup nobody volunteers for, the documentation pass after a quarter of features have shipped past it. That work has lived on junior calendars for as long as I've been doing this. It pays a junior to learn the system from the inside out by maintaining it. It gives them craft repetitions on a real codebase. It produces leveling artifacts they can point to in their next review. And it keeps the system not-broken.

Take that role out of the org chart and the work doesn't follow it out the door. It lands somewhere else.

So, where does it land? Three places. First, on the senior or staff designer who is now also the maintainer of the thing they used to design. Their week's deep work shrinks by some number of hours because the deprecated-color migration has to happen by Thursday. Second, on the DesignOps person, who absorbs it because that's where unowned operational work goes by default and because they can write a script for half of it. Third, nowhere. The work doesn't get done, the system rots a little each quarter, and the rot becomes visible in design quality six to eighteen months later, by which point the cause and the effect are far enough apart that nobody connects them.

Pick the bucket. None of them are good. The first costs you senior-craft hours you're paying for at senior-craft rates. The second loads more onto a function that is already, by every count, the most over-extended in design. The third is the one nobody's seeing yet because the lag is too long. None of them solve the underlying issue, which is that someone has to keep the system honest, and the org chart no longer has a slot reserved for that someone.

The 2026 hiring data is mostly right. Senior-strategic roles are growing. AI-fluent designers are in demand. The economics are real. But "senior-only design org" is a structural choice, and structural choices have consequences the hiring spreadsheet doesn't see. The pipeline that produced the next senior was, partly, this maintenance work. Some of it was the very-junior labor of doing it; some of it was the staff-level mentorship of teaching it; all of it was a context where craft repetitions happened on real surfaces. Take it out and the seniors of 2030 come from somewhere else. From companies that still hire junior, fewer each cycle. Or from a labor market where the ramp got shorter and produced fewer people who can do the work seniors used to do.

This is the part that compounds. AI gets more efficient quarter over quarter. Human craft gets developed by doing the work, repeatedly, with feedback, on real surfaces. We are removing the work and the surfaces. The line on the AI side keeps going up; the line on the human side bends the other way, slowly, in the kind of way that's hard to see in a single-quarter scorecard. Six years from now we will be hiring "senior" titles for skill sets that have lost half a decade of compounding. And we will look at the comparison, AI capability versus human output at our cost basis, and the conclusion will write itself. Because we wrote it years ago, when we stopped funding the bench.

What I keep watching, lately, is which of my friends are absorbing the maintenance work onto their own plates without saying so. They are framing it as "I just couldn't get to the documentation updates this sprint," "the icon library is in a weird state right now," "we'll catch up on the audit when things slow down." Things will not slow down. The audit will not happen. The system will get a little stranger every quarter. And the next time we hire, we will hire senior, because that is what the data says, and because the slot for the person who used to do this work is no longer in the budget.

What helps is seeing the second-order cost clearly enough to keep it in front of you when the next staffing conversation happens. Not as a position paper. Not as a slide. Clearly enough that you can spot the moment it would have been priced in, and notice what you traded for the version where it wasn't.