Wardley Mapping: A Complete Guide for Engineering Managers

What Is Wardley Mapping

A Wardley Map is a visual representation of a value chain, plotted on two axes. The vertical axis represents visibility to the user - components at the top are directly visible (like the user interface), whilst components at the bottom are invisible infrastructure (like DNS or compute). The horizontal axis represents evolution - from novel and uncertain on the left (genesis) to standardised and commodity on the right.

The map reveals strategic insights that are invisible in traditional architecture diagrams or technology roadmaps. By plotting your technology components on the evolution axis, you can see which components are being treated as custom-built when they should be commoditised, which components are about to shift evolutionary stages, and where your engineering investment is creating genuine competitive advantage versus where it is simply reinventing commodity infrastructure.

For engineering managers, Wardley Maps provide a powerful tool for communicating technology strategy to non-technical stakeholders. A CEO who cannot read an architecture diagram can often understand a Wardley Map because it speaks in terms of user value and market evolution rather than technical implementation. This shared understanding facilitates better strategic alignment between engineering and the broader organisation.

• The vertical axis (value chain) shows how components relate to user needs - higher means more visible
• The horizontal axis (evolution) shows maturity - from genesis (novel) to commodity (standardised)
• Components move from left to right over time as they evolve from custom to commodity
• The map reveals where to invest in custom solutions and where to use off-the-shelf products
• Use Wardley Maps to communicate technology strategy to both technical and non-technical audiences

Creating a Wardley Map Step by Step

Start with the user need at the top of the map. What is the primary thing your users are trying to accomplish? For an e-commerce platform, it might be 'purchase products.' For a developer tools company, it might be 'deploy software reliably.' This anchor ensures your map stays grounded in user value rather than drifting into technical abstraction.

Work downward through the value chain, identifying the components required to serve that user need. The user interface depends on an API, which depends on business logic, which depends on a database, which depends on compute infrastructure. Map each component and draw dependency lines between them. Do not try to be exhaustive on your first map - capture the fifteen to twenty most significant components and iterate from there.

For each component, assess its evolutionary stage. Genesis components are novel, poorly understood, and require experimentation - think of a proprietary machine learning model you are developing. Custom-built components are better understood but still specific to your context - your internal deployment pipeline, for instance. Product components have established best practices and multiple vendor solutions - CI/CD tools like GitHub Actions or GitLab CI. Commodity components are standardised and interchangeable - cloud compute, object storage, DNS.

Strategic Insights from Wardley Maps

The most immediate insight from a Wardley Map is identifying components where your engineering investment is misaligned with their evolutionary stage. If your team is maintaining a custom-built logging infrastructure when commodity solutions like Datadog or CloudWatch exist, the map makes this misallocation visible. Conversely, if a genesis-stage component - something that provides genuine competitive advantage - is being neglected in favour of commodity work, that is equally problematic.

Wardley Maps also reveal upcoming evolutionary shifts. Components move rightward over time, and anticipating these shifts enables proactive strategy. If your custom authentication system is approaching the product stage - meaning mature third-party solutions now exist - you can plan a migration to an identity platform like Auth0 before the maintenance cost of your custom solution becomes unsustainable.

Use maps to evaluate build-versus-buy decisions systematically. Components on the left (genesis and custom) are candidates for in-house development because they represent unique value or competitive advantage. Components on the right (product and commodity) should generally be purchased or outsourced because building them in-house diverts engineering effort from higher-value work. This simple heuristic, made visual by the map, prevents the common trap of building commodity infrastructure from scratch.

Wardley Mapping for Team Structure and Organisation

Different evolutionary stages require different team structures, skills, and management approaches. Genesis-stage work thrives with small, exploratory teams that have high autonomy and tolerance for failure. Commodity-stage work requires operational excellence, efficiency, and standardisation. Applying the same management approach to both types of work leads to either stifled innovation or unreliable operations.

Use Wardley Maps to inform your team topology decisions. Teams responsible for genesis-stage components should be structured for exploration - small, cross-functional, and empowered to experiment. Teams managing commodity components should be structured for efficiency and reliability - with clear processes, automation, and a focus on reducing toil. Platform teams typically manage components that span the product-to-commodity transition, providing internal products that other teams consume.

When hiring, the map helps you identify which skills your organisation needs. If most of your valuable components are in the genesis or custom stages, you need engineers who excel at ambiguous problem-solving and system design. If you are primarily operating commodity infrastructure, you need engineers with strong operational skills and automation expertise. The map makes these needs explicit rather than leaving hiring strategy to intuition.

Getting Started with Wardley Mapping

Your first Wardley Map will be imperfect, and that is expected. Start with a specific strategic question - 'should we build or buy a feature flagging system?' or 'where should we focus our platform investment next quarter?' - and map only the components relevant to that question. A focused map of fifteen components is more useful than a comprehensive map of one hundred that takes weeks to create.

Run a mapping workshop with your senior engineers and tech leads. Provide a brief introduction to the axes and concepts, then collaboratively build a map on a whiteboard or using tools like OnlineWardleyMaps or Miro. The conversations that emerge during mapping are often as valuable as the finished map - disagreements about where a component sits on the evolution axis reveal different assumptions about technology maturity and strategy.

Iterate on your maps over time. As you gain experience, your ability to assess evolutionary stages and identify strategic implications will improve. Share your maps with other engineering leaders and invite critique. Simon Wardley's book and blog are freely available and provide extensive guidance on advanced mapping techniques, strategic plays, and pattern recognition. The mapping community is active and welcoming to newcomers.

Key Takeaways

• Wardley Maps visualise technology components by user value and evolutionary maturity
• They reveal misalignment between engineering investment and component evolution
• Use maps to make systematic build-versus-buy decisions based on evolutionary stage
• Different evolutionary stages require different team structures, skills, and management approaches
• Start with a specific strategic question and map only the relevant components