Compounding Complexity: Systems Thinking and Design Leadership in the AI Era

The systems mindset in the AI era

Systems thinking is (still) having a moment. It shows up in strategy decks, in job descriptions, and in nearly every conversation about how product teams will work differently in the AI era. I find it in AI-generated writing (cough, slop) too, usually as a pithy line intended to sound profound:

• Designers are moving from designing screens to designing systems.
• Design is evolving from pixels to platforms.
• Designers are becoming curators (or orchestrators, conductors, maestros) of AI behavior.
• We don’t design interfaces anymore, we design intent.

The models didn’t invent these lines. They learned them by watching us (cue the 1987 anti-drug PSA). Each missive treats systems thinking as a destination designers graduate to, rather than a discipline with its own history and tools.

This isn’t the first time I’ve explored how systems thinking shapes product development. In 2016, at Adaptive Path’s MX conference, I argued that teams, products and organizations are complex adaptive systems, not complicated problems to be solved.

Complicated problems reward organizations built for efficiency and maximum return on minimum effort. Complex systems punish them, because their parts are interdependent: customers, partners, suppliers, APIs, other teams and, now, the models and agents inside the product.

My warning was that if you manage a complex organization as if it were just a complicated one, you’ll make serious, expensive mistakes. The same is true of the products we build.

Three years later, I went deeper into complex adaptive systems in my talk “The Future of Design Leadership: Transforming Design Management to Thrive in the Fourth Industrial Revolution” at Interaction19 in Seattle. I cited Amy Edmondson, who observed that despite working in innovative fields like technology and software development, many organizations still operate as if “the fundamental mindset and skills of management work best for fixed, understandable, reasonably predictable deliverables.”

Today, at the end of 2026, teams still live in that gap, between “Give me a date, how many people you need, and what features you will deliver” and “prompt, build, prompt, measure, prompt, learn.” A few years into the AI era, the gap hasn’t closed.

Neither systems thinking nor AI resolves that tension. AI compounds the risk through its speed, its apparent accuracy, and its ability to act on its own. Systems thinking improves the odds of building something useful and avoiding costly failures. It becomes the operating model for better products: tighter feedback loops, attention to emergence, and resilience over brittle efficiency. Ignore it, and you’ll make the same serious, expensive mistakes, only faster.

Three public cases show what that looks like in practice.

I don’t know what happened inside any of these companies. Their teams may well have mapped the system, argued about the risks, and been overruled. But each failure follows a pattern systems thinking warns about.

Replit relied on telling an agent what to do instead of limiting what it could do.

Klarna cut what looked like redundancy and found out it had been upholding quality.

Air Canada let its chatbot speak for the company without connecting it to the policy it was speaking about.

None of these was a hard technical problem. Each one was likely a slice of a system that nobody was looking at as a whole.

Six systems thinking tools, revisited

From 2019 to 2023, I built talks around Leyla Acaroglu’s “Tools of a System Thinker,” six tools to help people (not just user experience designers or even product development folks) shift from a mechanical view of work to a systemic one (Acaroglu). I paired each with behaviors I asked of design leaders. Today, AI amplifies four of the six and complicates the other two.

The foundation of those themes is still strong today: more teams and work are interconnected than in the 2010s, as is designing for wholes rather than parts, and tight closed feedback loops are still critical to identifying problems before they metastasize. What changed is that each shift now runs at a speed and scale where getting it wrong compounds quickly.

A complicated system lets you predict what will break next and where. In a complex one, the problem shows up somewhere you didn’t plan for.

That makes feedback loops critical. When building takes hours, a loop measured in weeks means shipping the wrong thing, and perhaps even multiple versions of the wrong thing before anyone notices.

The product becomes a system too

Sharon VanderKaay describes complex adaptive systems as diverse, interconnected agents with the capacity to grow and change. Those agents used to be people, teams and partners. Now the word is literal, and it describes the product as much as the organization.

AI changes what teams build, not just how. Large language models are probabilistic, so designers can no longer map every path in advance. Thoughtworks argues the job becomes keeping an experience coherent whatever the model returns (Thoughtworks).

Systems thinking shows up as questions a designer asks before drawing anything. When the model is wrong, how does the user find out, and what happens next? Where does a user’s correction go: does it improve the system, or disappear? Which behaviors could reinforce themselves over time? What does this feature depend on that someone else owns, such as a policy page, a data source, or another team’s agent?

That requires new measures of performance and quality. Thoughtworks suggests tracking user confidence, how often people intervene, and how often they override the system. Screen-level metrics like task completion miss whether the system as a whole is earning trust. Getting that instrumentation built is often a design leader’s job. Most teams treat it as a nice-to-have, something to build… later.

What about craft?

None of this means designers stop designing screens. It means a screen is now one part of an experience that spans models, agents, data and the teams behind them. Designing for the whole takes attention everywhere, not only on the parts people see, and craft follows the same logic: raising the bar has to lift everything the experience touches. The clearest place to see that is the design system.

The design system becomes infrastructure. Luke Wroblewski describes a design system built for agents as “a steering layer for a site’s design and front-end code” (LukeW). When agents write most of the code, the system is what keeps output on-brand and consistent.

For scaling design organizations, the advice has been to use the design system as a bridge between teams, and to position governance as a way to avoid problems later, not a power grab. It’s one bridge between isolated thinking and designing for interconnectedness and emergence.

That raises expectations for system quality. Mismatched tokens and stale documentation become errors that agents reproduce at scale, and a better system alone won’t produce better products. Ben Callahan (one of my fellow speakers at UX Lisbon 2023) argues that a design system raises the quality floor, while the quality ceiling depends on the choices product teams make with it. His answer is a loop: teams agree on what quality means, build toward it, evaluate the result, and fold what works back into the system. Each pass raises the floor, which gives teams room to raise the ceiling. Agreeing on what quality means is the analysis-to-synthesis shift applied to craft: the team deciding together what good looks like.

There is a risk to the craft itself. Kike Peña warns that when fast output becomes the only quality standard, the time spent exploring the problem space where design thrives starts to look unnecessary (uxdesign.cc). That exploration is also what raises the bar, so protecting time for problem framing must be a design leadership job, not the first action to be optimized because we trust the AI.

Where leaders should intervene

In 1999, the systems scientist Donella Meadows published an essay called “Leverage Points: Places to Intervene in a System.” A leverage point is a place where a small change can shift how the whole system behaves. Meadows ranked twelve of them, from least to most effective. At the bottom are parameters: the numbers people usually reach for first, like budgets, targets and headcount. They’re easy to adjust, but they rarely change what the system does. Further up are the structures that shape behavior: how fast feedback arrives, who has access to which information, and the rules everyone works within. Near the top are the system’s goals. Her point was that the higher the lever, the more impact it can have on the system, but it’s more difficult to actually change.

Most AI programs start at the bottom of Meadows’ list: licenses, adoption targets and usage dashboards. Those are parameters. They’re easy to change and easy to report, and they’re also the weakest levers. That may explain why a 2025 Harvard Business Review Analytic Services study found 83% of product decision-makers believe AI can significantly improve development, while only 34% are getting the results they want (Monterail).

The higher levers are the ones leaders actually control:

• What gets measured. If the dashboard counts features shipped, AI will produce more features. If it tracks how often people override the system, teams will build for trust.
• Who sees what. Air Canada’s chatbot and its policy page were maintained separately. Someone has to make sure research, support tickets and model failures reach the people designing the product.
• The rules for what can ship. Replit’s freeze was a request, not a rule. Leaders decide what an agent may change without review, and which parts of the design system are guarantees rather than suggestions.
• What teams are rewarded for. Outcomes, not output. The paragraph on success measures below makes the case.
• How fast feedback arrives. Meadows placed delays and feedback loops in the middle of her list. AI can shorten those loops, because it can watch behavior at a volume no team could. But it speeds up everything around the loop too. A delay that was tolerable when building took weeks becomes a problem when building takes hours. Reinforcing loops get faster as well, so errors compound before anyone notices. Leaders decide which loops get faster and where a person still has to be in control.

Staffing is structure too. Andrew Ng expects product and design work to grow as a share of the workforce as coding gets cheaper (HackerNoon). Ratios built for slow engineering will under-resource the work that now sets the pace.

Leverage points explain where to intervene. They don’t explain why so many organizations keep reaching for the weakest levers. For that, I go back to the adaptive cycle from my 2016 talk. Systems move through four phases: rapid growth, conservation, release and reorganization. Late in conservation, organizations chase efficiency by stripping out redundancy, tightening command and control, and suppressing experimentation. Those moves sit low on Meadows’ list, and many AI programs push in exactly that direction: fewer people, tighter process and more measured output. Conservation is the phase that comes right before release.

The way out isn’t to stop the cycle; no system can. Instead, we design and build the conditions for resilience that let a system absorb a release without losing what makes it work.

The four practices from 2016 still apply, each with an AI-era form:

Success measures need the same update. Fixed-goal questions ask whether all the committed features shipped or whether we handed off on time. Systemic ones ask whether it created business value, and what we learned that we must act on now. When output is cheap, “did we ship it” measures almost nothing.

Same discipline, new systems

What hasn’t changed: organizations are complex adaptive systems, leaders can intervene but not determine, and feedback loops decide whether surprises are caught in time.

What has changed: the agents in the system now include software, the loops run at machine speed, and the design system has become the steering layer.

For a design leader on a team already shipping AI features, systems thinking is mostly about where to look. The work on screens still matters, but the risk lives in the connections: what the model reads from, what it’s allowed to change, and where a user’s correction goes.

That leader asks what happens when the model is wrong before anyone asks what it looks like when it’s right. They push to measure overrides and interventions before launch, because instrumentation added “later” rarely arrives. And they treat the design system as a contract agents have to honor, with tests that enforce it.

For a team still working out how to use AI, the temptation is to start with tools: buy licenses, set an adoption target, count prompts. That’s the bottom of Meadows’ list. A design leader there gets more from mapping the system the tools will land in. Which feedback loops are already too slow? Which decisions depend on information that never reaches the people making them? Where is the team fragile, one person deep or one vendor deep? AI will amplify whatever the answers are. Fixing a slow loop or a single point of failure before adding agents is less exciting than a pilot, and it lasts longer.

In both cases the job is the one I described in 2016, running at a different speed: see the team, the product and the organization as one system, intervene where the leverage is, and keep enough slack to absorb the surprises nobody planned for.

Leaders should make changes from a position of strength, not desperation. The pressure to adopt AI pushes many organizations toward desperation, and desperate systems intervene at the weakest leverage points.

Sources

1. Meadows, D. Leverage Points: Places to Intervene in a System. Donella Meadows Project, 1999.
2. Andrew Ng: Product team ratios evolving. HackerNoon.
3. Product design in the age of AI: Designing non-deterministic systems. Thoughtworks.
4. Beyond the Model: a systems approach to AI product design. UX Collective.
5. Peña, K. Did AI kill the system’s thinking skills in UX? UX Collective.
6. Wroblewski, L. Design Systems for AI Agents. LukeW, October 1, 2026.
7. AI in Product Development Life Cycle. Monterail, citing Harvard Business Review Analytic Services, September 2025.
8. Avore, C. Resilient Design Management: Embracing Complexity in Teams, Products, and Organizations. Adaptive Path MX conference, 2016. Includes a quotation from Sharon VanderKaay.
9. Avore, C. The Future of Design Leadership: Transforming Design Management to Thrive in the Fourth Industrial Revolution. Interaction 19, IxDA, February 2019.
10. Acaroglu, L. Tools for Systems Thinkers: The 6 Fundamental Concepts of Systems Thinking. Disruptive Design, September 7, 2017.