Not leading with the label: How to introduce transformative techniques without overwhelming your teams

Have you ever tried to introduce a new way of working such as Wardley Mapping, Team Topologies, or Domain-Driven Design (DDD), only to see your team’s eyes glaze over? You’re not alone. While these methodologies, approaches and frameworks can unlock incredible value, their perceived complexity, size and scope can often intimidate teams and create resistance before you even begin.

This phenomenon is often described by practitioners like Jeff Patton, Ben Moisor, and I'm sure others including me, as ‘leading with the label', announcing the methodology upfront and unintentionally overwhelming people with its perceived difficulty or scale. The solution? Focus on outcomes and practical steps instead of names and frameworks.

In this article, we’ll explore why leading with the label can be counterproductive, help you recognize situations where it might happen, and provide techniques to introduce transformative approaches without overwhelming your team.

Why leading with the label doesn’t work

Labels like "Wardley Mapping," "Team Topologies," or "Domain-Driven Design" are shorthand for highly nuanced and powerful methodologies. However, when introduced prematurely, these labels can create barriers:

1. Perceived complexity: Teams unfamiliar with these approaches may assume they require extensive expertise, training, or time.

2. Cognitive overload: People are already busy, and a new framework feels like yet another thing to learn.

3. Resistance to change: Labels can make the methodology seem rigid or prescriptive, triggering pushback.

Example: Imagine telling a team, “We’re going to start doing Domain-Driven Design.” Without context or a clear connection to their current challenges, the phrase might sound like an overwhelming and irrelevant technical exercise.

Recognizing when you’re leading with the label

You might be leading with the label if:

• You’re met with blank stares or skepticism: When you mention a framework, people seem confused or disengaged.
• Conversations derail into the mechanics: Questions focus on the “how” or “what” instead of the “why.”
• Momentum stalls early: Teams hesitate to move forward because the framework feels too complex or abstract.

A better way: Start with outcomes, not names

Instead of leading with the label, focus on the outcomes your team wants to achieve. For example:

• Instead of "We’re implementing Wardley Mapping," say: "Let’s create a clearer picture of how our systems and capabilities serve our users."
• Instead of "We’re adopting Team Topologies," say: "Let’s explore ways to reduce handoffs and make our teams more autonomous."
• Instead of "We’re going to use User Needs Mapping," say: "Let’s better understand what our users need and how we can align around delivering that."

This approach lowers resistance by:

• Focusing on tangible benefits.
• Simplifying the conversation.
• Encouraging curiosity instead of defensiveness.

Techniques for introducing approaches without the label

1. Solve a specific problem

Begin with a concrete challenge your team is facing. Show how elements of the framework can address that challenge, but avoid mentioning the framework by name.

Example: If team boundaries are unclear, introduce collaborative exercises to map dependencies and ownership without saying, “We’re using Team Topologies.” Instead, frame it as, “Let’s figure out where responsibilities are overlapping and how we can improve clarity.”

2. Introduce concepts gradually

Break the framework into digestible pieces and introduce them over time. Avoid overwhelming your team with the entire methodology at once.

Example: When using User Needs Mapping, start by identifying users and their needs in a workshop. Once the team is comfortable, introduce capability mapping as the next step.

3. Show, don’t tell

Demonstrate the value of the approach by guiding your team through an exercise or process without labeling it. Ensure you foster a trusting environment that encourages the team to try new things and they are invited to take part rather than have it thrust upon them.

Example: Facilitate a session where the team maps user needs and dependencies. Afterward, explain how this approach aligns with User Needs Mapping or Wardley Mapping principles.

4. Leverage storytelling

Share success stories from other organizations or teams, focusing on the outcomes they achieved rather than the methodology they used.

Example: Describe how a company reduced communication overhead and improved delivery speed by clarifying team ownership, without initially mentioning Team Topologies.

5. Use familiar language

Translate the framework’s jargon into terms your team already understands.

Example: Instead of “bounded contexts” (DDD), talk about “clear domains of responsibility” or “what each team owns.”

When to introduce the label

While avoiding the label initially can help build buy-in, there’s a time and place to introduce the formal framework. Use the label when:

• The team is already on board: Once they’ve experienced the value, naming the framework can help contextualize the approach.
• You’re scaling or standardizing: A shared vocabulary becomes useful as the methodology spreads across the organization.
• External training or resources are needed: Knowing the framework’s name allows teams to access additional learning materials and expertise.

A Real World Example

For more details on a recent real-world example, my good friend and colleague Ruben van Alebeek recently wrote a great post (that inspired this article) that demonstrates not leading with the label in action.

"We didn’t build psychological safety by naming it. We built it by practicing it."

I highly recommend taking a look: Team as the Nucleus

Final thoughts

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.

Frameworks don’t unlock change, people do. Focus on what matters to them, and the frameworks will follow. Start small, focus on outcomes, and let the results speak for themselves.