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.

We’ve all experienced them:

• The awkward handoff where nobody’s quite sure who owns what.

• The stand-up that becomes a status meeting for five different priorities.

• The clunky collaboration that drains energy instead of unlocking progress.

It’s tempting to dismiss these moments as challenges we just have to live with, symptoms of working in a complex organization. But what if we treated awkwardness as a signal? A sign that the current team structures, relationships, or responsibilities are no longer supporting the way work actually flows.

Understanding what drives your users is crucial for delivering products and services that truly meet their needs. While Jobs to Be Done (JTBD) focuses on uncovering the underlying motivations behind user actions, User Needs Mapping provides a framework for aligning teams and capabilities to meet those needs. Together, these methodologies offer a powerful approach to driving value and aligning your organization around user goals.

By combining User Needs Mapping with the "We can if..." approach from A Beautiful Constraint, you can create innovative, scalable solutions that work within your current limitations. You can overcome resource constraints when defining team and service boundaries and break free from path dependence by rethinking legacy systems and architectures.

All organizations operate within constraints.

Time. Budget. Legacy systems. Regulatory requirements. Skill gaps. Cultural inertia. These aren’t signs that something is broken. They’re the reality of operating in a complex world.

The challenge isn’t whether constraints exist. It’s how we relate to them. Too often, constraints are treated as blockers. Reasons we can’t act. Excuses for stagnation. But what if we reframed them?

Leading with the label can unintentionally create barriers to adopting powerful frameworks like Wardley Mapping, Team Topologies, or User Needs Mapping. By focusing on outcomes, breaking concepts into manageable pieces, and building trust through practical steps, you can guide your team toward meaningful change without overwhelming them.

Transitioning to new team boundaries is a common challenge for organizations that have identified more effective structures through techniques like User Needs Mapping or other strategic Team Topologies-based approaches. However, moving from your current state to an ideal team design can feel daunting. By integrating principles from Dynamic Reteaming, organizations can make small, incremental changes that evolve team structures naturally over time.

One of the most promising things about AI is how accessible it’s becoming. Teams don’t have to wait for central approval to experiment. Developers can integrate models in hours. Operations teams can automate tasks without waiting for platform teams. It’s fast. It’s exciting. It’s also a recipe for chaos if not handled with care. Because while AI is decentralizing capability, alignment has never been more important.