The complexity multiplier

Why DesignOps was built for a world that no longer exists. And what needs to replace it.

I've spent the last few years advising on the build-out of DesignOps inside a large product organisation. What I observed was a complexity problem, and complexity, unlike maturity, doesn't grow linearly. It multiplies. And by the time the cost becomes visible, it tends to be measured in nine-figure acquisition deals rather than headcount decisions.

The world DesignOps was designed for

The tools and frameworks built to manage design at scale were designed for a simpler world: one team, one surface, one interaction type. The job was to make that operation efficient. Reduce friction. Standardise tools. Clarify handoffs.

That world is ending. In conversations with colleagues working across the automotive industry, the same pattern surfaces consistently: DesignOps doesn't disappear when it isn't named or invested in. It goes underground, absorbed into the margins of everyone's role, quietly accumulating as unacknowledged organisational debt. The language that lands with leadership isn't about design quality. It's about liability. Debt that's been accumulating. An investment that's been deferred.

Three forces that change everything

The first is surface complexity. Design no longer lives on one type of screen. It lives on a phone, a dashboard, a voice interface, an in-car display, an ambient system that operates without a screen at all. They have different attention models, different safety constraints, different input and output modalities. Designing consistently across them is a coordination challenge of a fundamentally different order.

The second is brand complexity. Multi-brand organisations don't just have multiple visual languages, they have multiple governance models, multiple stakeholder chains, multiple definitions of what good means. Who owns a decision when two brands share a component but have conflicting design principles? The answer, in most organisations, is nobody. Or everybody. Which is the same thing.

The third, and the one the industry is only beginning to reckon with, is the shift from interaction to delegation.

When a touch becomes a contract

When a user delegates a task (charge my car optimally, manage my route, handle this payment), they are not navigating a flow. They are issuing a trust contract. Delegation itself isn't new. What's different now is the scale, the opacity, and the interconnectedness. AI-driven delegation is non-deterministic. The same intent on Monday might produce a different outcome on Friday. And when a system is simultaneously managing charging, routing, payments, and personalisation, the blast radius of a coordination failure is categorically larger than anything that came before.

And delegation is not brand-neutral. How a system acts on a user's behalf: what it decides, what it explains, what it refuses. This is one of the most direct expressions of brand character imaginable. A premium brand that delegates silently feels arrogant. A safety-focused brand that delegates without explanation feels reckless. Most organisations haven't recognised this yet. But they will, the moment something goes wrong.

Multi-surface×Multi-brand×Delegated flows=Coordination crisis.
DesignOps was built for addition. The next decade requires it to operate at multiplication.

The silo problem

There is a pattern in complex product organisations that anyone who has worked inside one will recognise: deep domain expertise, clearly divided ownership, and nobody looking at the whole. Each team handles their slice with genuine care. Body control, infotainment, connectivity, after sales, commercial, engineering, each excellent within their boundaries. The boundaries themselves create the gaps.

The contrast with born-digital companies is stark. Tesla operates with a handful of harmonised models, one design language, one software layer. Rivian made a deliberate decision to build its own native in-car experience, as a coordination choice above all. Owning the full surface means owning the full coherence. Legacy brands never had that option. They inherited the silos.

Volkswagen Group recently invested over five billion dollars in a joint venture with Rivian to acquire the digital coordination capability they couldn't build internally, despite thousands of engineers and decades of automotive expertise. It puts a price on trying to figure it out on your own. They looked at the cost of continuing and concluded it was cheaper to buy the answer than to keep accumulating the debt.

What DesignOps needs to become

The shift isn't about adding more DesignOps capacity. It's about redefining the scope of what it coordinates. In a world of delegated, multi-surface, multi-brand experiences, DesignOps needs to coordinate the principles, boundaries, and behaviours of systems that act on behalf of users, across every surface they inhabit.

That means DesignOps needs more than a seat at the table when AI initiatives are scoped. It needs to be the function that convenes the table, bringing together legal, brand, product, and engineering around a question none of them can answer alone: what does this system do on behalf of the user, and does every function that needs to own that answer actually own it?

The definition of done has to expand accordingly. Not just what the user sees, but what the system decides when the user isn't watching. Not just whether the interaction is usable, but whether the delegation is coherent with what the brand stands for, defensible from a regulatory perspective, and consistent across every surface the user inhabits.

The direction this points toward is a fundamentally more integrated way of operating, where design, product, engineering, and brand ops are not parallel tracks that occasionally intersect, but a single connected system with shared ownership and clear accountability. When processes are siloed and ownership isn't clear, problems don't just accumulate. They compound.

In the organisations where this tension is most acute, DesignOps is often simultaneously being recognised and constrained. Leadership senses something is missing. They don't yet have language for what it should become. That moment of uncertainty is the opening.

The uncomfortable irony

The same force multiplying the coordination surface is also the only realistic tool for managing it at scale. When you have hundreds of discrete design moments, each needing its own governance, its own trust model, its own definition of done, no human team can audit them all.

Which is where AI enters, not as the thing that designs, but as the thing that watches and the thing that does the work nobody wants to do. In early tests by practitioners in the field, a design system refactoring process that previously consumed weeks of expert time now runs continuously, managed in a fraction of that time per sprint by someone overseeing an agentic workflow rather than executing it manually. Documentation updates automatically as the system evolves. For organisations where design system maintenance has historically been a bottleneck, this is a structural shift in what the team can do.

Where DesignOps previously transferred deep knowledge directly to teams, it is increasingly transferring that knowledge to agents and teaching teams to manage those agents. The skill required shifts from execution to orchestration. And when that coordination overhead is absorbed by agentic workflows, the human capacity that remains can be directed at the questions that actually matter: culture, governance, how design returns value to the business.

AI agents are also becoming participants in the work itself, with defined scopes, responsibilities, and outputs that sit alongside human team members. The question is how DesignOps coordinates humans and agents together, and whether the team structures, the role profiles, and the governance models we have were built for that. DesignOps is the function best placed to lead that conversation.

The tooling is early. The frameworks don't exist yet. But the direction is clear: the governance layer DesignOps needs to own is too large and too dynamic to be maintained manually. AI doesn't replace that governance. It makes it possible to enforce it. That is a reason to move faster, building the right structures before the complexity outruns even the tools designed to manage it.

Three questions worth sitting with

Nobody has fully solved this yet. These are the questions worth bringing into the room, before the next AI initiative gets scoped, before the next surface gets added, before the next brand gets onboarded.

On structure: Does your DesignOps function have a mandate that extends beyond the design team, or does its authority stop stop at the handoff?

On ownership: When an AI initiative launches in your organisation, who is responsible for how it relates to every other delegated experience your user already has? If you don't have dedicated DesignOps people. Who holds that question at all?

On definition: Delegation is a brand statement. Can you answer, right now, what it says about yours: what your system is allowed to decide autonomously, what it must always explain to the user, and what it must never do without asking?

This is not a theoretical problem. Somewhere right now, a DesignOps team is delivering its most measurable year while nobody has yet agreed what it should become. The work is real. The complexity is growing. And the people who understand both are still looking for the language to make that visible to the people who need to hear it. This article is an attempt at that language.

If the honest answer to any of these is "nobody has asked that yet": that is exactly the point. The complexity is already multiplying. The coordination just hasn't caught up.