--- type: article title: "Wardley Mapping and Situational Awareness: Seeing Evolution Before Writing Code" description: "Why strategy without a map is merely a list of wishes, and how tracing the evolution of components from novel genesis to utility commodity prevents builders from fighting the wrong war." timestamp: 2026-10-27T00:00:00.000Z facet: technical tags: ["Wardley Mapping", "Systems Architecture", "Strategy", "Situational Awareness", "Metacognition"] --- ## Strategy Without a Terrain Is Just a Wish List Walk into almost any technology planning room and ask to see the strategy. Nine times out of ten, you will be handed a slide deck containing a mission statement, a list of quarterly goals, and a timeline of features. Imagine a general standing before a mountain range with a list that reads: *Quarter One: March north. Quarter Two: Win the battle. Quarter Three: Hold the valley.* Without a map of the actual terrain, showing where the rivers run, where the cliffs rise, and how the ground is shifting, a list of intentions is not a strategy. It is a wish list disguised as execution. This is the exact blindness that Simon Wardley diagnosed when he introduced **Wardley Mapping**. In complex technical systems, builders routinely make multi-year commitments while flying blind. We fall in love with the elegance of our internal machinery without asking two foundational questions: *Who actually depends on this component?* and *How fast is this component evolving toward becoming a commodity?* ## The Two Axes of Situational Awareness A genuine map requires coordinates that mean something in reality. Wardley Mapping provides situational awareness by placing every component of a system onto two axes: ### 1. The Value Chain (Vertical Axis: Visibility and Need) Every architecture exists to serve a human need at the top of the graph. Beneath that need sits a chain of dependencies: the user interface, the orchestration logic, the data stores, the compute substrate, and the power grid at the very bottom. Mapping the vertical chain forces an immediate honesty check. If you cannot trace a clear line from a technical component up to a genuine human need, you are looking at architectural vanity. Conversely, when a foundational dependency buried six layers deep is fragile, the map reveals how a single tremor at the bottom will fracture the user experience at the top. ### 2. The Evolution Axis (Horizontal Axis: Genesis to Commodity) Nothing in technology stands still. Every capability travels from left to right across four distinct stages of maturity: * **Genesis (Stage I):** Novel, poorly understood, high uncertainty, and constantly changing. This is the realm of pure exploration. * **Custom Built (Stage II):** Understood by a few specialists, bespoke, and built from scratch for specific use cases. * **Product (Stage III):** Standardized, repeatable, and increasingly differentiated by feature sets and reliability. * **Commodity and Utility (Stage IV):** Essential, ubiquitous, standardized, and invisible until it breaks, like electricity, TCP/IP, or basic cloud storage. As we explored in [Working In the System Versus On the System](/posts/working-in-versus-on-the-system), the most common trap for a seasoned builder is clinging to a layer that has already moved right on the map. ## The Commodity Trap and the Three Postures of Craft Why do intelligent teams burn years of effort with so little to show for it? Because they apply a **Custom Built** mindset to a capability that the rest of the world is turning into a **Commodity**. Engineers love building things from first principles. Left unchecked, a talented team will happily spend eighteen months writing a bespoke authentication layer, a custom deployment pipeline, or a proprietary wrapper around a rapidly commoditizing model. As explored in [In Defense of Reinventing the Wheel](/posts/defense-of-reinventing-the-wheel), rebuilding something in a private sandbox to learn how it works is a wonderful educational exercise. Rebuilding a commodity in production while pretending it is your strategic moat, however, is a quiet form of organizational self-sabotage. Once you place your system on an evolutionary map, you realize that no single engineering culture fits the entire landscape. You need three distinct postures of craft: * **Pioneers (Genesis):** Builders who thrive in ambiguity, run rapid experiments, and expect half of their prototypes to fail while discovering what is possible. * **Settlers (Custom to Product):** Builders who take the rough, working discoveries of the Pioneers and turn them into reliable, documented, repeatable products that others can actually trust. * **Town Planners (Commodity):** Builders who industrialize mature products into rock-solid, low-cost utility primitives so that the next generation of Pioneers can stand on their shoulders. Every posture is honorable. Disaster only happens when you ask Pioneers to run a utility power plant, or when you judge Town Planners by how many novel inventions they ship. ## Cross-Pollinating the Map with the Architecture of And In the spirit of [The Architecture of And](/posts/the-architecture-of-and), a Wardley Map refuses the binary argument between *build versus buy* or *speed versus stability*. Instead, it shows you **where** to be fast and experimental (on the left side of the map) **and** **where** to be disciplined, standardized, and frugal (on the right side of the map). When you look at your architecture as a moving landscape rather than a static diagram, ego dissolves. Letting go of yesterday's custom code is no longer a personal loss; it is simply moving your camp to higher ground so you can explore the next frontier. ## Metacognitive Inquiry Protocol Use these two questions to test your situational awareness before committing to your next major build: * **01. The One-Minute Reflection:** Look at the project consuming the largest share of your engineering hours this month. Where does it sit on the evolution axis from Genesis to Commodity? Are you investing bespoke creative energy into something that will be a standard utility within eighteen months? * **02. The Three-Minute Mapping Exercise:** Take a single sheet of paper. At the top, write the core human need your system serves. Beneath it, draw the five key components required to deliver that need, placing novel, uncertain components on the left and mature utilities on the right. Circle the single component where moving from custom code to a standard utility would free your attention for the true frontier.