Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Wardley Mapping to Find Strategic Advantage
Transcript
- Lucas: Let me paint a picture. It's late 2024, and a fintech startup is processing about $2 billion in annual payments. Their fraud detection system — built in-house years ago — is starting to buckle. False positives are spiking, the engineering team is spending 40 percent of their sprint patching the fraud engine, and the CEO is asking: should we buy a third-party solution or double down on building? Luna: That's the classic build-versus-buy question, but with a lot of emotional weight. Nobody wants to admit their homegrown system might be the wrong call. Lucas: Exactly. And the CTO of this company, a woman named Priya, didn't want to make that call based on gut feel or vendor pitches. So she did something I think is still underused in tech leadership: she drew a Wardley Map. Luna: Wardley Mapping. I've heard Simon Wardley talk about it — it's basically a way to map your business landscape, right? You plot components on two axes: value chain and evolution. Lucas: That's the gist. The horizontal axis is evolution — from 'genesis' or novel on the left, through 'custom built', to 'product', and finally 'commodity' or utility on the right. The vertical axis is the value chain — what sits underneath what. You put the user need at the top, then the things needed to satisfy it, and so on down. Luna: So you're literally drawing boxes and arrows that show dependencies. And the position on the evolution axis tells you how mature or standardized each component is. Lucas: Right. And the strategic insight comes from a simple principle: if a component is further to the right — more commoditized — you should probably buy it, not build it. If it's on the left — novel or custom — that's where you can differentiate. Priya sat down with her team and mapped the entire payment flow. User need: 'pay for a subscription.' Under that: checkout page, payment gateway, fraud detection, compliance checks, ledger update, customer notification. Luna: And where did fraud detection land on the evolution axis? Lucas: That was the eye-opener. They had placed it as 'custom built' — left of center — but when they honestly assessed it, the algorithms they were using were essentially the same as what Stripe's Radar or a dozen other vendors offered. It was a commodity capability, but they were investing scarce engineering time maintaining it. The map made it visible: they had a $2 million annual engineering cost for something that gave them zero competitive advantage. Luna: So the map told them: buy. But I imagine the engineering team pushed back — people get attached to their systems. Lucas: They did. But the map became a neutral reference. Priya could say, 'Look, the map shows fraud detection as a commodity. Our competitors can buy the same capability. If we want to differentiate, we should put our engineering effort into something that's still on the left side of the map — like our real-time ledger or our subscription management logic.' And that argument landed because it wasn't her opinion; it was the landscape. Luna: That's powerful. It's like having a shared visual language for strategy. I've heard Wardley Maps described as 'the strategic equivalent of source control' — it gives you a versioned, shared view of the terrain. Lucas: That's exactly how one CTO put it to me. And what's interesting is that the map doesn't just help with build-versus-buy. It reveals hidden dependencies and assumptions. In Priya's map, they discovered that their compliance checks depended on a legacy database that was end of life. That wasn't even on their radar before the mapping exercise. Luna: So the map surfaces technical debt that's invisible in a Jira backlog. It connects architecture to business strategy in a concrete way. Lucas: Exactly. And once you have the map, you can start asking strategic questions. What moves do we want to make? Should we invest to move a component from product to commodity? Or should we build something novel that shifts our position? Wardley talks about 'the doctrine of strategic play' — there are patterns like 'exploit', 'evolve', 'disrupt' that you can apply based on where you are on the map. Luna: Give me a concrete example of a strategic play from a map. Lucas: Sure. Let's say you're a retailer and you map your e-commerce stack. You find that 'cart management' is a commodity — you use Shopify or whatever. But 'personalized recommendations' is still custom-built and gives you an edge. A strategic play might be to 'evolve' that recommendation engine into a product you could eventually sell to other retailers. The map shows you where you have the right to play. Luna: So it's not just about cost optimization. It's about finding where you can create value that competitors can't easily copy. Lucas: Exactly. And that's why I find Wardley Mapping so useful for CTOs who are tired of making decisions in a vacuum. It gives you a framework that's both visual and analytical. You can argue about where a component sits on the evolution axis — there's always some subjectivity — but the conversation itself is productive. Luna: I've seen some teams struggle with getting started though. The maps can get really complex really fast. Any tips for a first-time mapper? Lucas: Start small. Don't try to map the entire company. Pick one user need — like 'pay an invoice' or 'book a ride' — and map only the components directly under it. Limit yourself to 15 to 20 components. Use sticky notes on a whiteboard, not a fancy tool. And the most important rule: the user need must be a specific, observable action, not a vague goal like 'increase engagement'. 'User reads an article' is good. 'User has a great experience' is not. Luna: And how do you decide where a component sits on evolution? I've seen people get stuck on that. Lucas: There are a few heuristics. Ask: is this component typically built from scratch by most companies in our space? That's 'custom built'. Is it available as a standard product from multiple vendors? That's 'product'. Can you get it as a utility, like cloud compute or a credit card processor? That's 'commodity'. For genesis, it's something so novel it doesn't exist yet — like a new AI model that creates a new category. Luna: Right. And the evolution axis isn't about time — it's about how well-understood and standardized the component is. A cryptocurrency wallet might be 'custom built' today but moving toward product. Lucas: Exactly. And that's where the strategic insight comes in. If you're building a wallet from scratch when Stripe and Plaid offer it as a product, you're probably wasting money. But if you're doing something truly novel — like a wallet that integrates with decentralized identity in a new way — then building might be justified. Luna: So the map forces you to be honest about what's actually differentiating. And that honesty can be uncomfortable, especially for teams that pride themselves on building everything. Lucas: Absolutely. And that's why it's important to frame the exercise as a learning tool, not an audit. The goal is to understand the landscape so you can make better bets. Priya's team didn't feel attacked — they felt empowered because they could see where their effort would have the most impact. Luna: And the result? Did they switch to a third-party fraud solution? Lucas: They did. They migrated to Stripe Radar within three months, cut their fraud-related engineering time by 70 percent, and reduced false positives by 25 percent. The team that had been maintaining the fraud engine was reassigned to work on the real-time ledger — which was on the left side of their map and directly tied to their competitive advantage in instant payouts. Luna: That's a concrete win. And they probably avoided a much more painful forced migration down the line when the homegrown system became completely unsustainable. Lucas: Right. And that's the thing about Wardley Mapping — it's not just for one-off decisions. It's a practice. Priya now does a quarterly map review with her leadership team. They update the positions as the market evolves. It's become their shared strategic language. Luna: I love that. It's like a living document for strategy. And it scales — you can do a high-level map for the whole company or a detailed one for a single squad. Lucas: Exactly. And one more thing — Wardley Maps are also great for communicating with non-technical stakeholders. You can show a map to a CEO or a board member and they can see: here's where we invest, here's where we rely on vendors, here's the risk. It makes technical strategy tangible. Luna: That's a huge value. I've seen too many CTOs struggle to explain why they want to spend six months on a platform rearchitecture. A map can make that case in five minutes. Lucas: Exactly. And speaking of making things tangible — if today's conversation gave you a practical takeaway, that's exactly the kind of thing listener support helps us keep doing. We keep this show ad-free, and a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Yeah, it really does make a difference. Every bit helps us keep digging into these specific, actionable frameworks. Lucas: So back to the map. One question I get from CTOs is: how often do you need to update the map? And the answer is: it depends on the pace of change in your industry. For a fast-moving fintech, quarterly is about right. For a more stable enterprise, every six months might be enough. But the key is to treat it as a hypothesis — you put a component at a certain evolution stage, and then you watch for signals that it's moving. Luna: What signals? How do you know a component is evolving? Lucas: One signal is the emergence of standards. If you see multiple vendors offering the same API spec, that component is moving from product toward commodity. Another signal is consolidation — big players buying the startups in that space. Or, from your own engineering team: if you find that maintaining a component is no longer differentiating, that's a sign it should move right on the map. Luna: So the map isn't static. It's a tool for continuous situational awareness. Lucas: Exactly. And that's the real superpower. It's not about making one perfect map. It's about building the habit of seeing your business as a landscape of evolving components. Once you have that lens, strategic decisions become clearer. You stop asking 'should we build or buy?' and start asking 'where should we build to create asymmetric advantage?' Luna: That's a great framing. So to wrap up: for any tech leader listening who wants to try this, what's the first step? Lucas: Pick one user need this afternoon. Grab a whiteboard or a piece of paper. Write that need at the top. Then list the components underneath it — no more than 15. For each one, ask yourself: is this genesis, custom, product, or commodity? Don't overthink it. Just put a sticky note in one of four columns. Then step back and look at it. You'll almost certainly see something you didn't expect.