Wardley Maps & Pace Layering for Senior Tech Leads and Engineering Leaders

Intro to both tools, why they exist, how they overlap and pragmatic tips how to use them and when

If you're a senior developer, tech lead, Staff, or Principal engineer, you're likely grappling with more than just code.

You're thinking about architecture, tech bets, team direction, influencing product roadmaps, and ensuring your technical initiatives deliver real strategic value for the business.

We dive into Wardley Maps and Pace Layering, not as abstract theories, but as practical tools that can help you answer questions like:

• What perspectives do these tools add to connect technical landscape to the business model? How can we reach clarity?

• How can we make smarter bets on our technological investments?

• How to make compelling cases for architectural changes, refactoring, or technology choices?

• Where should our teams be focusing their bandwidth as our tech landscape evolves?

• How to distribute and balance the budget and headcount around foundations, products, and features?

• What's a lightweight way to start applying these strategic ideas today?

• How can these lenses fill the communication gap between C-suit and the edge nodes of the org tree to speak the same language and pull in the same direction?

And if you’re a senior engineer, you may still find these tools valuable. Ever feel like you're just churning out code without seeing the bigger picture? Or wondered why some parts of your system are ancient monoliths while others are shiny microservices? How about when your great ideas getting blocked or go under-funded because no one up there could understand the value of the problem you’re trying to solve?

Note: I have used Gemini Advanced over the course of 7 hours combined with manual editing, annotation, illustration and adding resources to create this post. I also had to rewrite a few entire sections. You can dismiss it as “if AI knows this stuff, I don’t need to read it”, and that’s respectable. Sure, AI can generate content but it cannot understand it for you. As a senior technical leader myself, I found this exercise insightful, and I believe the final result is richer. I would read a post like this if it existed (and believe me I did my research). 😊

Wardley Maps: the GPS for Tech Landscape

Imagine you're navigating a complex open world video game like GTA. You wouldn't just wander aimlessly, right? You'd want a map.

That's kind of what a Wardley Map is for your business and tech strategy.

Created by Simon Wardley, it's a visual way to understand what you're building, why you're building it, and where the real challenges and opportunities lie.

A 2D User Centric Map

Forget abstract business goals for a second. A Wardley Map always starts with your users and their needs. This is your "North Star" or the main quest objective. Everything else on the map exists to support the user needs.

Y-Axis: Value Chain - How Visible Is It to the user?

Think of this as your dependency tree or tech stack, laid out vertically. Stuff at the top is what the user directly sees and interacts with (e.g., the UI of your web app).

Stuff at the bottom is the plumbing – the databases, servers, power supply – less visible but totally essential.

This shows how different components rely on each other to deliver value. If your database (bottom) is slow, the user experience (top) suffers.

X-Axis: Evolution - How Mature Is This Tech?

This is where it gets really interesting. Components aren't static; they evolve over time, driven by good old supply and demand. Think of it like tech maturity levels:

1. Genesis (The Wild West): This is brand new, experimental stuff. Think cutting-edge algorithms, the first version of a crazy idea. It's uncertain, likely to break, but potentially revolutionary. Dev parallel: That weekend hackathon project held together with duct tape and dreams.

2. Custom-Built/Bespoke (Your Special Sauce): You're building this yourself because nothing off-the-shelf quite fits. It's unique to your needs, maybe a bit bespoke and quirky. Dev parallel: Your company's proprietary rendering engine, bespoke platform or that complex internal API.

3. Product (+Rental): Someone else has figured this out and is selling it. This is sometimes called COTS (for Commercial off-the-shelf). Think commercial software, SaaS products (like Stripe for payments, Okta for authentication or Akamai for CDN), or well-established libraries (like React for front-end rendering). You buy or rent it. Dev parallel: Using a popular frontend framework, a cloud database service, or an authentication provider.

4. Commodity (+Utility): This stuff is so standard and well-understood, it's like a utility (like electricity). It's expected, reliable, and you pay for what you use. The vendors often have a thin margin since this space is very competitive. Dev parallel: AWS S3, basic compute instances, open-source databases, or even electricity itself.

If you want to get fancy, you can download Wardley Mapping Canvas here

Here's a quick comparison of these evolutionary stages to help you assess your own tech components:

Wardley Mapping Example: A news site

I used this example from several years ago because I know it intimately well and it doesn’t leak any info from my current company.

Putting the main parts of the architecture on a Wardley Map, we get this:

A few notes:

• Adding everything to the map quickly clutters it to the point it is not useful. This is a high level view showing some of the pieces that may be required in a discussion about why we should build our own CMS for example.

• For product and community pieces, I’ve removed the brand names.

• We built our own headless CMS because we needed a powerful tool for storytelling that wasn’t matched by anything on the market.

• Although the Cloud Infra was based on a purchased product, we were only using a subset of its features that was commodity (a managed Kubernetes cluster)

Using Wardley Maps to for tech decisions

• Spotting red flags: See that critical UI feature (high on Y-axis) relying on some janky, bespoke solution (in Genesis stage) when a solid "Product" solution exists? That can be a red flag for tech debt or a missed opportunity.

• Giving a direction to budgeting and headcount: On the other hand if nothing in the market fits the bill, you may deliberately choose to invest in that area to turn it to a proper Bespoke solution.

• Finding opportunities for migration and cost reduction: It is completely normal for a company to build something that doesn’t exist. But as more companies run into the same problem, some startups may create products that solve those problems better and at a lower price point. Reassessing the tech landscape can pop those opportunities where a migration (tech bet) can save costs on the long run. Security is hard to get right. Instead of building a Bespoke authentication solution, you’re typically better off using a battle-tested “Product” like Okta or Keycloak.

• Setting SLOs: Generally, components early in their evolution stage can use lower SLO . Higher reliability commitments create frictions against the experimentation and flexibility that these solutions need to evolve rapidly. On the other hand, solutions that are Productionalized or Commodity need to be held accountable for higher SLOs. In case of 3rd party vendors, these SLOs are often part of a SLA that sets clear legal or financial consequences for the breach.

• Identifying spin-off opportunities: have you created an elegant Bespoke solution to solve your company’s problems? Do you know if other companies have the exact same problem and there’s nothing on the market to address it? You may be sitting on a gold-mine to spin-off a new business model and monetize that solution by turning it to a Product that can open a new revenue channel for your company.

• Communicating with Non-Techies: A visual map is a great way to explain complex tech dependencies and strategic choices to CPO, CTO, or even CFO (when the total cost of ownership is questions). Wardley Mapping is particularly useful because it surfaces the value of the invisible components in the tech landscape.

Beyond these basics, Wardley Maps has a few power-ups that allows it to deliver value at scale:

• Climatic Patterns: These are like the "rules of the game" – predictable forces like "everything evolves" or "success breeds inertia" (meaning, sometimes your past wins make you slow to adapt).

• Doctrine: Think "best practices" or SOP (Standard Operating Procedures) that help you play the game better, like "know your users" or "use appropriate methods" (Agile for new stuff, Six Sigma for optimizing commodities).

• Gameplay: These are your "special moves" or "power-ups" – specific actions you can take to change the game, like open-sourcing a component to speed up its move to commodity and mess with competitors.

Now, let's switch gears to Pace Layering for another map and perspective.

Pace Layering: Mapping the speed of evolution

While Wardley Mapping can help set a direction for tech evolution, Pace Layering helps make sense of decoupled architectural layers. It can be used as a tool for deliberate allocation of resources (budgeting, headcount), governance, reliability, compliance, and stability.

The concept of Pace Layering, or "Shearing Layers," was originally introduced by Stewart Brand in his work on how buildings evolve. He observed that different parts of a building change at different rates. His key insight was that because these layers change at different speeds, they "shear" past each other. This loose coupling between layers is crucial for resilience and adaptability.

…in the early 1970s, the English architect Frank Duffy wrote, “A building properly conceived is several layers of longevity of built components.” He identified four layers in commercial buildings:
- Shell: lasts maybe 50 years
- Services: swapped out every 15 years or so
- Scenery: interior walls, etc. move every 5 to 7 years
- Set: furniture, moving sometimes monthly.

Source

Previously we have covered why using building and construction metaphors in the world of software leads to fallacies but stay with me, especially on the loose coupling between these layers.

In the tech world, you might hear of a specific three-layer model for applications:

1. Systems of Innovation (SOI) - The Skunkworks (Fastest Layer):

   • What they are: New, experimental things (e.g., hackathon projects, prototypes).

   • Rate of Change: Fast.

   • Dev Mindset: Rapid iteration, MVPs, learning quickly.

   • Dev parallel: AI model integrations, new app feature prototypes, A/B tests.

2. Systems of Differentiation (SOD) - Your Competitive Edge (Medium Layer):

   • What they are: Applications enabling unique company processes (e.g., custom pricing engine, unique CRM integrations).

   • Rate of Change: Medium.

   • Dev Mindset: Agility, delivering business value, configurability.

   • Dev parallel: Your company's unique pricing engine, a custom CRM integration, recommendation algorithms.

3. Systems of Record (SOR) - The Bedrock (Slowest Layer):

   • What they are: Core, foundational systems managing critical data (e.g., core financials, HR databases).

   • Rate of Change: Very slow.

   • Dev Mindset: Stability, reliability, security.

   • Dev parallel: Ancient, critical database schema; the mainframe; core network infrastructure.

Pro-Tip: Think in Layers, Start with Business Capabilities When applying this, don't just slap labels on your existing apps. Think about what your business actually does (its capabilities) and how quickly those capabilities need to change.

Then, see which systems support them and how they fit into these different speed layers. This helps ensure your tech strategy truly supports the business strategy.

Here's a quick table to compare these layers:

You may have noticed a similarity between Pace Layering (1D) and the X-axis of the Wardley Maps. We’ll shortly cover this similarity and when to use each tool.

Pace Layering Example: That same news site

I often say business of news is the business of speed. The same rush that goes into writing about breaking news is omnipresent on the development floor where the latest tech is adopted. Or at least that’s my experience.

Before slapping labels on different parts of the architecture, we need to identify the business capabilities and the pace of their change:

• To tell compelling stories, the front-end was constantly changing in tight collaboration with UX and journalists. A bug in the front-end wouldn’t last too long due to the sheer number of eyeballs that would see it. This product was optimized to have several releases per day (including cache invalidation that was needed to ship the latest code).

• The Business Logic layer was more static but it still needed to change from time to time to support new features that were added in the front-end. This layer could potentially change at the same speed but often it was released every 2-3 days. Significant changes were pushed every few months in close coordination with its main consumer: the front-end.

• The CMS hardly changed and most of the effort was put on maintenance, refactoring, and scalability. The shape of the API hardly changed. In fact in my 5 years working with these systems, I had probably seen a handful of changes only one of which was a breaking change.

Note that we didn’t talk about Products or Community components that is surfaced in Wardley Maps.

In this example, front-end is the SOI, Business Logic layer was SOD, and the CMS could be considered SOR.

Using Pace Layering to manage resources and expectations

Why Should Developers Care about Pace Layering? (And How Does It Impact Your Work?

• Identifies best places for implementing loose coupling: Helps categorize old systems and encourages designing for "shearing": loose coupling for adaptability and identifying architecture “seams”.

• Clarifies requirements: different layers have different security, compliance, reliability and other NFRs (non-functional requirements).

• Justifies Different Dev Practices: Explains why your SOI team can CI/CD daily, while the SOR team has quarterly releases with lots of ceremonies, manual controls, and process friction.

• Guides resource and budget allocation: Justifying work on an SOR isn't about new features, but about ensuring resilience, security, scalability, and reducing operational risk. A decaying SOR puts the whole business at risk, no matter how fast your SOIs are. Use this to argue for that crucial refactor or tech debt pay-down.

• Manages Expectations: Sets clear expectations for stability vs. speed based on the pace of change: Innovation vs Differentiation vs Record.

Wardley vs Pace Layering: different perceptions

So, we've looked at Wardley Maps for understanding the competitive landscape and Pace Layering for decoupling our internal systems by their speed of change.

You might be thinking, "Hmm, these sound a bit similar, especially Pace Layering and the Wardley evolution axis. Are they just different words for the same ideas?" That's a great question, and it's a common point of reflection!

They definitely share some DNA because both are tools in the technical leadership and architectural toolbox. They both deal with how things change and mature over time.

That’s where the similarities end.

Pace Layering (SOR, SOD, SOI) feels somewhat one-dimensional, focusing on the rate of change. The X-axis of a Wardley Map also describes a form of evolution (Genesis to Commodity). So, what's the real difference?

• Driving Force & Scope:

  • Wardley's Evolution (X-axis) is about the market-driven commoditization of any component in your value chain. It's pushed by supply and demand competition (market forces). Everything on a map, from a tiny piece of code to a whole platform, is subject to this evolutionary pressure. It helps you understand where a component sits in its lifecycle relative to the market.

  • Pace Layering is about the business-dictated change cadence for an entire system or application based on its role in your specific organization and the business capability requirements. An SOR changes slowly because the business needs that stability, not necessarily because all its underlying components are ancient.

• Focus of Analysis:

  • Wardley Maps: Analyze the entire external competitive landscape and your position within it. The evolution axis is one part of a two-dimensional map (the other being the value chain/visibility). The goal is situational awareness to make strategic plays in the market.

  • Pace Layering: Analyzes your internal IT portfolio and how to govern it. It's about managing internal resources and development approaches effectively based on different required speeds of change.

• What They Describe:

  • Wardley's Evolution: Describes the maturity and ubiquity of a component. Is it novel and rare (Genesis), or standard and widespread (Commodity)?

  • Pace Layering: Describes the required operational tempo and governance model for a system. Does this system need to be rock-solid and change rarely (SOR), or does it need to be experimental and change often (SOI)?

Wardley Maps + Pace Layers: gaining perspective

Imagine you have a System of Record (SOR), like your core accounting system. In Pace Layering terms, it changes very slowly. On a Wardley Map, this accounting system itself might be considered a "Product" or even "Commodity" if you bought it off-the-shelf. The components it uses (like the database it runs on, or the programming language it was written in) would also have their own positions on the Wardley evolution axis. The database might be a "Commodity," while a specific custom integration module within that SOR might be "Custom-Built."

Conversely, a System of Innovation (SOI) is, by its Pace Layering definition, fast-changing and experimental. The components it's built from are almost certainly in the "Genesis" or "Custom-Built" stages on a Wardley Map.

This is where it gets really powerful:

• Wardley Maps give you the "lay of the land" – the strategic "why" and "what." They help you see opportunities, competitor moves, and user needs.

• Pace Layering then helps you organize your internal response – the "how." A Wardley insight might identify a new SOI, which then gets agile funding and rapid iteration.

By using both, you get a richer picture for smarter decisions on market strategy (Wardley) and internal system design/governance (Pace Layering).

Other lenses worthy of mentioning

Here are a couple of other widely recognized frameworks that help in designing and organizing complex software systems and the teams that build them:

Domain-Driven Design (DDD) is an approach to software development that emphasizes a deep understanding of the business domain. It focuses on creating a rich "domain model" that reflects the business's complexities and uses a "Ubiquitous Language" shared by developers and domain experts.

• Why it's relevant here: DDD helps you understand the "what" and "why" of the systems you're building at a very granular level. This deep domain understanding is invaluable when creating Wardley Maps (what are the true user needs and core components?) and when classifying systems for Pace Layering (what makes a system truly differentiating for our business?). Concepts like "Bounded Contexts" from DDD naturally lead to more modular systems that align well with the idea of "shearing layers" in pace layering

Team Topologies is a model for organizing business and technology teams for fast flow and adaptability. It proposes four fundamental team types (Stream-aligned, Enabling, Complicated Subsystem, and Platform) and three core interaction modes. (learn more here)

• Why it's relevant here: Once Pace Layering helps you identify systems that need to change at different speeds, Team Topologies can provide concrete patterns for how to structure your engineering organization to effectively support them. For example, you might have Platform teams providing stable SOR-like services, while Stream-aligned teams rapidly iterate on SODs and SOIs, consuming those platform services. It helps answer the "How can these frameworks improve our team's structure or mission clarity?" question from our intro.

City Maps (also known as IT Landscape Diagrams): are visual representations, that provide a holistic overview of an organization's IT landscape using city metaphors. Think of them like a city plan showing different zones (business domains), major infrastructure (core platforms), key buildings (applications), and roads (integrations).

• Why it's relevant here: While Wardley Maps dive deep into the dynamics of specific value chains and Pace Layering helps categorize systems by change rate, these broader EA maps provide the "big picture" context. They are particularly useful when communicating tech to technophobic leaders who for some reason have a say in tech 😄A Wardley Map might analyze a strategic new "road" or "utility" for this city, and Pace Layering could define the building codes (governance) for different "zones" (SOR, SOD, SOI) within it.

These aren't replacements for Wardley or Pace Layering, but rather complementary lenses. Understanding the business domain deeply (DDD) and organizing your teams effectively for flow (Team Topologies) can amplify the strategic insights you gain from mapping your landscape and layering your systems.

Lightweight First Steps

Feeling inspired but not sure where to begin?

1. Your First Mini-Wardley Map: Pick a single user story or a small feature your team is working on. Try to map out its immediate value chain: What does the user need? What few components directly deliver that? Where do those components sit on the evolution axis? Are there any opportunities to move a component in the x-axis while motivating it by business objectives? Don't aim for perfection; aim for a 15-minute conversation starter with a colleague.

2. Pace Layering Your Next Feature: When discussing a new feature or epic, ask yourself: "What's the expected rate of change for this? Is this an experiment (SOI), a core differentiator (SOD), or something that needs to be super stable (SOR) from day one?" This simple question can spark valuable discussions about expectations and approach. You can then think about NFRs like reliability, security, and compliance.

These frameworks give you a language and a lens to think more strategically about the software you build every day. They help bridge the gap between writing lines of code and delivering real, impactful, and sustainable value.

What do you think? Have you encountered these ideas of tech evolution or different speeds of change in your products? How might you use these tools? Let's discuss in the comments!

---

My monetization strategy is to give away most content for free. These posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends. The simplest way to support this work is to like, subscribe and share it. If you really want to support me, you can consider a paid subscription. If you want to save money, you can get 20% off via this link. As a token of appreciation, you get access to the Pro-Tips sections and my online book Reliability Engineering Mindset. Your contribution also funds my open-source products like Service Level Calculator. You can also invite your friends to gain free access.

And to those of you who support me already, thank you for sponsoring this content for the others. 🙌 If you have questions or feedback, or you want me to dig deeper into something, please let me know in the comments.