Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Wardley Maps to Spot Strategic Blind Spots
Transcript
- Lucas: So I spent part of last week with a CTO from a Series B SaaS company who was frustrated. She told me, 'We just spent six months building a custom CI/CD pipeline because we thought our needs were unique. And now GitHub Actions does everything we built — better, cheaper, and with a team maintaining it.' Luna: Ouch. That's a painful way to learn your special sauce isn't that special. Lucas: Exactly. And it's the kind of mistake that shows up when you don't have a clear picture of where your tech stack sits in the broader market. That's where Wardley Maps come in. Luna: Wardley Maps — that's Simon Wardley's framework, right? The former CEO who wrote about mapping your value chain against evolution? Lucas: That's the one. Simon Wardley, former CEO of Photobox, and now a researcher at DXC Technology. He developed this mapping technique to help companies visualize the components they depend on, where those components sit on an evolution axis from 'genesis' to 'commodity,' and what that means for your strategy. Luna: So the map has two axes. The y-axis is the value chain — what depends on what. The x-axis is evolution, from custom novel stuff on the left to standardized utilities on the right. Lucas: Right. So in the CI/CD case, the company's pipeline was a custom-built tool — way on the left side of the axis, in the 'custom-built' zone. But the market had already moved it to 'product' and even 'commodity' on the right. The map would have shown that immediately. Luna: And the key move is to identify which components are truly strategic differentiators — things you should keep custom — versus which are just plumbing that you should buy. Lucas: Exactly. Wardley calls it 'pioneer, settle, colonize.' Pioneer means you're inventing something new — high risk, high potential. Settle means you're turning it into a product. Colonize means you're standardizing and outsourcing it. The mistake is treating plumbing as pioneering. Luna: So how do you actually start making a map? Walk me through the steps. Lucas: First, you identify the user need — the top of the value chain. For a SaaS company, that might be something like 'deliver new features to customers.' Then you list every component that directly serves that need: deployment pipeline, feature flags, monitoring, database, authentication, payment processing, and so on. Luna: And you map each one on the evolution axis based on how mature the market is for that component. Lucas: Right. Authentication? That's a commodity. You should never build your own auth system unless you're a security company. Database? It's a product — you can self-host or use a managed service, but you're not inventing a new database. Your custom recommendation algorithm? That might still be in genesis or custom-built territory — that's where your competitive edge lives. Luna: So the map forces you to be honest about which parts of your stack are truly differentiating. And that's uncomfortable for a lot of engineering leaders who love to build. Lucas: It is uncomfortable. But the alternative is wasting six months on a CI/CD pipeline. One CTO I know told me he uses Wardley Maps every quarter during his strategy offsite. He brings his leadership team into a room with a whiteboard, and they map the entire stack in about two hours. Luna: And what do they find? What's the typical blind spot? Lucas: The biggest one is that teams overestimate how unique their internal tools are. They think their monitoring setup is special because they tweaked a few dashboards. But the map shows that the underlying components — Prometheus, Grafana, whatever — are all commodities. The real differentiator is the culture of incident response, not the tooling. Luna: So the map shifts the conversation from 'what should we build?' to 'what should we care about?' Lucas: Exactly. And it also exposes hidden dependencies. For example, that same CTO's team discovered that their entire deployment pipeline relied on a single engineer who had built a custom script five years ago. That script was not documented, not on any roadmap, and it was a single point of failure. The map made it visible. Luna: So it's not just about build versus buy — it's about risk management. Lucas: Absolutely. And Wardley Maps also help you anticipate market shifts. If you rely on a component that's evolving rapidly — say, AI model APIs — the map shows you that you need to stay flexible because the landscape is changing. You might need to switch providers or abstract your interface. Luna: That reminds me of the whole 'no-code' movement. A lot of companies built custom internal tools, and now there are off-the-shelf solutions that do the same thing. A Wardley Map would have warned them. Lucas: Exactly. And the framework isn't just for big strategic decisions. I've seen teams use it for a single sprint planning session. They map out the technical tasks and ask: 'Is this task moving a component from custom to product? Or is it just maintaining a commodity that we should stop investing in?' Luna: That's a powerful filter. Because a lot of engineering time goes into polishing something that the market has already commoditized. Lucas: Right. And one of the hardest things for a CTO is to tell a senior engineer, 'I know you love maintaining that tool you built, but we need to stop. It's not a competitive advantage anymore.' The map gives you an objective way to have that conversation. Luna: It's a strategic tool, but it's also a communication tool — helps align the team. Lucas: Speaking of keeping the team aligned and the show ad-free — we should probably mention something. We don't run ads on Tech Leadership. It's listener supported. A handful of people chip in monthly through buy me a coffee dot com slash fexingo, and that's what makes it possible to keep putting out episodes like this without sponsors. Luna: Yeah, and it's genuinely a small group. If you've gotten value from the show and want to help keep it going, that's the way. No pressure, but it does make a difference. Lucas: So back to the mapping — once you have your map, the next step is to identify 'climatic patterns.' Wardley talks about how certain patterns repeat: the 'commoditization of a component' or the 'shift from product to utility.' Recognizing those patterns lets you predict where your industry is heading. Luna: Like how cloud infrastructure went from a product you installed to a utility you pay by the drink. Companies that mapped that early had a huge advantage. Lucas: Exactly. And the same thing is happening now with AI. The models themselves are becoming commodities — every major cloud provider offers them. The differentiation is in the data, the fine-tuning, and the application layer. A Wardley Map would show that clearly. Luna: So if I'm an engineering manager listening, what's my first step? Lucas: Pick one user need — something your team deals with every day. Write it at the top. Then list every component that feeds into it. Put a dot for each on a timeline from 'genesis' to 'commodity.' Then ask: for each component, is our investment justified? Are we building something that's already a product? Are we ignoring a looming commoditization? Luna: That's a concrete exercise. And it doesn't need to be perfect — even a rough map reveals blind spots. Lucas: Exactly. Wardley says the map is never finished — it's a living document. The value is in the conversation it creates. And if you do it quarterly, you start to see patterns. You become proactive instead of reactive. Luna: One thing I wonder — how do you handle the politics? If the map shows that a senior engineer's pet project is a commodity, that's a tough conversation. Lucas: It is. But the map depersonalizes it. You're not saying 'your project is worthless.' You're saying 'the market has evolved, and the map suggests we shift our resources.' It's a data point, not an accusation. And good leaders can handle that. Luna: Fair. And if they can't, maybe that's another signal about the team. Lucas: Right. Wardley Maps are ultimately about making better bets with limited resources. And in a world where tech changes fast, that's the core job of a CTO. Luna: Great episode. I'm going to try mapping my own team's stack this week. Lucas: Do it. And let us know what you find — we might follow up in a future episode.