Exploring with Wardley Maps


Recently I’ve been thinking about why we use certain approaches in particular ways, which I think is an effort to retrofit a more formal method to the loosely associated set of techniques we tend to use. I spent this morning considering a set of Wardley Maps, which we use extensively as a tool to help with the development of a shared context, produced as part of a long-term engagement in the fashion industry.

We often use the mapping process and the resulting maps to come to a shared understanding of how various activities of a group fit into an overall narrative. We also use more specific maps to surface and discuss the finer points of work in specific areas. This has evolved over time into a multi-level approach to mapping, with generally a single high-level organisation map and multiple more specific maps showing components, composition and external context in more detail.

Top-Level Map - Organisational Context and Business Need

For this set of maps the group we were working with initially had fairly loosely defined objectives. We were mainly working on adding internal technical capability where previously it was outsourced. This meant that the actual anchoring needs for the maps needed some thought. What we found was that producing a rough map gave us an artefact to use in these discussions with the group. It also served a purpose in upward communication of team activities to C-level executives. The act of showing how our proposed activities tied in with strategic objectives sparked conversation on the detail of those objectives around the organisation. It also served as validation that activities were anchored to an business need which was previously not always clear and as the conversations continued the anchoring needs of the maps could be refined and agreed.

Figure 1: Organisation Level Map (Simplified)

Figure 1: Organisation Level Map (Simplified)

Second-Level Maps - Technical Context(s)

We use more detailed maps as more of a technical tool. One style which we find helpful is a ‘zoom’ into the technical components of specific area of the higher-level map, usually an area which we have defined as a particular sub-team responsibility. The exercise of mapping these detailed areas is a way of discussing where sub-team focus and energy is directed on value-creation work (i.e. work in the genesis and custom space) and where this is unnecessary (i.e. there are readily available product and commodity components). It also highlights where there is extensive integration work to be done. Even commodity components require effort to piece together.

In general we work with teams that expected to make their own technical decisions around the systems they are building but this type of mapping allows some constraints and guiding principles (possibly some carefully chosen elements of Wardley’s Doctrine) to be surfaced and discussed.

The example in figure 2 is that of a retail communication tool focused on direct customer interactions (figure 1’s ‘Team 4’). The team spent time assessing the market around what they were trying to achieve and looking at the technical platforms that could help them. Mapping was used in both of these activities to help with perspective and context. The map shows the technical platform comprised of mainly commodity technology with some product-stage components. What was clearly missing at the time were tools to create and manage different customer interaction flows. As a result this was where most of the development effort was directed.

Figure 2: More Detailed Technical Map

Figure 2: More Detailed Technical Map

This more technical chart can be related to the higher level organisational map, however, the higher-level is not just a simple roll-up of the lower-level components. In fact, most of the detail shows product-stage and commodity components with a smaller number sitting in custom build. However, the fact that large and important technical elements sit in the custom build stage places the overall component in that domain in the higher-level representation. This very much depends on the size and complexity of the custom components. A simple and easy to deal with custom item would not exert that level of force on the overall activity.

Second-Level Maps - External Context(s)

The two previous maps do not show anything about the external environment that the group is operating in. We find that a third map can be useful to represent this, sometimes focusing on a specific component that we feel is worth effort. Mapping the environment of these components helps us stay aware of other developments in the space and how things are moving relative to what we are doing. i.e. is our work still valuable and is the effort still justified. It also helps us to spotlight organisational inertia where that is a concern, rather than having these elements as secondary items on a more complex map. Figure 3 shows a context map used to highlight the constraints on the development of a component due to factors within the wider organisation.

Figure 3: More Detailed Context Map

Figure 3: More Detailed Context Map

Highlighting the inertia as it relates to this particular team on the map is useful only if we can then use this information in some way. In this case the context map highlights an incorrect assumption in the previous maps - the supporting data component is much more immature than first thought. This presents a problem for the team and is not something that they can explicitly control. Moving back up to the top-level context allows us to see how we can deal with the problem on an organisational level and there is a second team assigned to this area. The maps help us address this as an explicit element of the organisational strategy. We also highlight and detail the team’s need and where it may benefit from being a user of another team’s work. Additionally we can now feed the new information into the other maps to correct the position of the data component.

Figure 4: Top-level Map Incorporating New Information

Figure 4: Top-level Map Incorporating New Information

The Magic Number (of Maps)?

The three maps shown are all related to the same small-ish team working in the same larger organisation. They try and show different aspects of the same activity. We found producing and using all the maps useful in different ways and they helped us work through different problems and with different conversations.

There is obviously a cost to producing and maintaining a number of artefacts, especially when they are representing views and perspectives of the same overall activity. The maps shown are representations of documents that were more often than not scribbled on bits of paper. A low-overhead method of mapping is key to allowing people to explore the processes and represent different aspects on different charts, and also keep things in motion as time passes. We do find that the ability to produce nice looking charts does help with credibility when trust-building is needed. There are some production techniques we use to help with the task of producing the more polished maps but we’ll save those for another post.

Summing Up

What have we learned from this mapping activity and the utility of this set of maps?

  • High-level maps can show a clear link between an activity and a high-level organisational need
  • Limiting the components on a particular map allows focus on a certain area and user need
  • Pulling out components for more focus allows for different views on a particular area (technical component makeup, external market etc.)
  • Maps can be related to each other i.e. a more detailed map can highlight the reason for the placing of a particular component on a higher level map
  • The process of producing multiple maps helps to spark discussion around the anchoring points and assumptions that may not hold under scrutiny
  • The more maps you have the more your mapping overhead. It helps to keep things simple and fairly transient, especially for the more detailed representations that become outdated very quickly

Further Reading

  • The Wardley Maps book contains discussion and examples of each of these types of map
  • For some more in-depth discussion of representing sub-system components within maps see this excellent article which discusses the evolution of components in a jet engine

Thanks to David Lindsay for reading drafts of this article