When “control” becomes the wrong instinct in complex systems

I've been exploring AI less as a destination and more as a diagnostic. If AI is best understood as a diagnostic, then the most important leadership work isn’t deciding where to deploy it, but deciding how to respond to what it reveals.

AI is not forcing a new structure into existence. It is revealing where the current one no longer fits the work it is being asked to support. And that is why it can feel destabilising. Not because it introduces chaos, but because it removes the comfort of slack and makes structural misalignment visible. Seen this way, the opportunity is not to reorganise around AI, but to treat the friction it surfaces as actionable feedback on team design.

In slower environments, coupling is masked by experience and goodwill. People bridge gaps manually and absorb the cost. Under AI-driven pressure, that absorption capacity diminishes. Dependencies do not disappear with better tools- they become more apparent.

One way to think about the current wave of AI adoption is not as a transformation programme, but as a diagnostic for how our organisations actually function under pressure. When you look at it through that lens, decision-making is often the first thing to show strain.

AI isn’t the transformation, it is the stress test that reveals where organisational change has been overdue for some time.

Teams often find it helpful to have a way of describing where they are. Whether it’s through surveys, assessments, retrospectives, or research-backed models, being able to say “this roughly reflects our situation” can bring a sense of clarity and shared understanding. It gives teams language for the conditions they’re operating within, and often creates a moment of recognition.

What tends to be harder is knowing what that recognition should lead to. Once a team can describe the environment it’s in, the question shifts from understanding to action. What would actually make a difference here? Which changes are worth attempting, and which would simply make the current situation run a little more smoothly without really changing it? That’s the question I want to explore.

A while back, I wrote an article about not leading with the label — why starting with names like Wardley Mapping or Team Topologies can create resistance before teams have connected those ideas to their own problems. The DORA work has brought that back to mind; diagnosis benefits from shared language, while change benefits from starting with lived problems and outcomes. If you’re using the DORA archetypes right now, the interesting question might not be which framework comes next, but how you help teams explore change without overwhelming them upfront.

The DORA AI Capabilities Model offers a way to make the “AI as an amplifier” insight actionable, outlining the technical and cultural capabilities that help organisations get positive performance gains from AI rather than simply accelerating existing dysfunction. Among those capabilities, User-Centric Focus stands out — because it’s the one that keeps teams moving in the right direction and because DORA research² shows that teams who focus on the user have 40% higher organisational performance and significantly higher job satisfaction.

For a long time, I’ve found John Cutler’s Journey to Product Teams infographic useful as a way of making sense of different ways of working. It visualised different patterns of team interaction — waterfall, agile with a release silo, feature factory, product team — and, importantly, helped people recognise that not all “agile” teams were operating under the same conditions. The work captured the interaction patterns teams tend to fall into, with those interactions expressed through the language of practices and process. Recently, I started wondering what if we re-expressed that same journey, not in terms of practices or process labels, but purely through team interactions? That question led to some interaction models I've created to try to articulate the Journey to Stream-Aligned Team.

The delivery gap isn’t a people problem; it’s a sociotechnical architecture problem, and what’s encouraging about that is this: sociotechnical architecture is a design choice. It can be examined, discussed, and evolved. When organisations start with users, make needs explicit, and design team boundaries and interactions around real value flows, the gap between intent and experience finally begins to close.

Organisations often assume they already think about users. Most strategy starts with customer insights, market movements, competitive analyses, and ambitious visions. But day-to-day conversations tell a different story. One of the most powerful shifts I see in organisations adopting User Needs Mapping comes from the simplest possible question:

“Who is this serving?”

It sounds trivial. It isn’t.

Most organisations genuinely believe they are taking an outside-in approach. Strategies are full of customer insights, market movements, competitive analyses, and ambitious visions. But when implementation begins, everything slows down. Not because people resist change or don’t care; in fact, most teams care deeply and work incredibly hard. The real issue is quieter: the organisation plans outside-in but executes inside-out.

Once a team has aligned on who their users are, the natural next step is to understand what those users actually need. This is where things often get messy, because what teams hear, what they assume, and what users actually need are rarely the same thing.

Almost every team that completes Step 2 of the User Needs Mapping process says some variation of:

“I can’t believe we’ve never done this before.”

The reality is that teams rarely pause to question what they believe they already understand. Step 2 creates that pause and grounds the rest of the User Needs Mapping process in shared reality rather than assumption.

When organisations talk about alignment, they often jump straight to strategy, structure, or process. But the foundation for all of these, the invisible glue that holds collaboration together, is something far simpler: shared language.

Most of the time, we smooth over awkwardness. We normalise it, joke about it in retros, build workarounds and move on. But in organizations that stay adaptive, awkwardness isn’t ignored or joked away. It’s treated as a feedback signal; a prompt to inspect the structure, not just the symptoms.

So you have managed to find a recurring awkward interaction. You’ve traced it back to an interaction signal that’s worth paying attention to. So what now?

You don’t need to start with a reorg. In fact, many of the most effective changes begin not with a restructure, but with a small shift—something safe to try, observable, and grounded in a real need.

This post offers practical ways to experiment with structure, roles, and responsibilities in response to specific types of awkwardness, without triggering unnecessary disruption.

You’ve spotted a signal, something awkward, frustrating, or inefficient that keeps cropping up between teams. Now what do we do? Not every instance of this type of friction requires a redesign, but some of them are telling you:

“This part of the system is no longer fit for purpose.”

The aim of this post is to help you determine which signals are worth acting on and how to respond without immediately resorting to a full-blown reorganisation.

Not all awkwardness is created equal. Some team tensions are signs of unclear responsibilities. Others point to over-dependence, broken trust, or missing capabilities. If you want to improve the way your organization works, you need to get better at reading the signals, especially the awkward ones. A single awkward meeting might just be a one-off, but if it continues to repeat, then it’s worth paying attention to. Awkward interactions that recur frequently tend to cluster around specific pain points, and these patterns can reveal where your current setup is breaking down.