The Problem with Lists Disguised as Strategy
Imagine you are a general preparing for battle. Your advisor hands you a list: "1. We have tanks. 2. It is raining. 3. The enemy has high morale. 4. Our supply lines are long." That list is accurate. It is also nearly useless. You cannot see where the tanks are relative to the enemy, which roads are passable in rain, or where your supply lines are most exposed. You need a map.
Most organizations do strategy with lists. The most popular format is SWOT Analysis — Strengths, Weaknesses, Opportunities, Threats. A SWOT might say: "We have strong engineers (Strength). AI is growing (Opportunity). Our competitors are well-funded (Threat)." Every item on that list might be true. But a list has no spatial relationship between items. It cannot show you where you are, where your competitors are, or which direction the terrain is moving. You cannot navigate with it.
What Wardley Mapping Adds
Wardley Mapping, created by Simon Wardley in 2005 while he was CEO of Fotango, gives you a visual topography of your business and technology landscape. It is a two-dimensional map where every component of your system — from user-facing features to underlying infrastructure — is plotted by two properties: how visible it is to the user, and how mature it is as a technology. The result is a picture that makes strategic disconnects immediately obvious.
A classic example of a disconnect that a Wardley Map exposes but a SWOT never would:
"Why are we spending six engineers custom-building our own internal logging framework — a solved problem available for free — while our one genuinely novel AI recommendation engine is understaffed?"
The map shows this as a visual absurdity: a team pouring resources into the bottom-left corner of the map (commodity territory) while the top-right corner (where differentiation lives) is barren. No PowerPoint deck makes this visible. A Wardley Map does.
Why This Matters for Platform and DevOps Engineers
Platform engineers make build-vs-buy decisions constantly. Should we build an internal developer portal or use Backstage? Should we run our own Kubernetes clusters or use a managed service? Should we write a custom deployment pipeline or adopt ArgoCD? Without a framework for situational awareness, these decisions get made based on gut feel, vendor sales pitches, or whoever argues loudest in the room. Wardley Mapping gives you a principled, visual language for these decisions — and for communicating them to leadership.
Interviewers at senior levels often ask: "How do you decide what to build versus buy?" A weak answer lists criteria in the abstract. A strong answer describes a framework — ideally one you have used. Referencing Wardley Mapping and explaining the Evolution axis (Genesis → Commodity) demonstrates strategic maturity that separates principal engineers from mid-level ones.