The Three Mountains
My wife is a primary school teacher. A few years ago, I was preparing a presentation for a client — an existing customer who wanted to talk about where they were heading with their data — and she was at the kitchen table doing pupil assessments. Three categories: working towards an objective, at the expected level, or operating at greater depth.
I looked at what she was doing and something clicked. That's exactly the conversation I needed to have with my client. Not about databases or data warehouses, but about honestly assessing where they were before trying to leap to where they wanted to be.
I adapted it slightly. The first category became "just about managing." The other two stayed roughly the same. I've been using it ever since — about a decade now — and it's become the single most useful model in my toolkit.
🏔️ Mountain One: Just About Managing
Most organisations live here for most of their processes. Things work, but only just. The system is held together with spreadsheets, bits of paper, tribal knowledge, and relationships. You know to go and ask Sarah for the membership numbers because she keeps a spreadsheet. Dave in accounts can tell you who's actually paid. It functions, but it's fragile and person-dependent.
The simplest test: ask your organisation a basic question. In the membership world, that question is often "how many members have we got?" It sounds trivially simple. It isn't.
On Mountain One, you can get the answer. You just need to open a few files, maybe phone accounts to check who's paid, cross-reference a couple of spreadsheets that might not quite agree. You'll get there. But do it again next week and you might get a slightly different number. The definition of "member" is fuzzy — do lapsed members in their grace period count? What about the free tier? Every time you ask, you're reassembling the answer from scratch.
I use two everyday analogies to make this concrete. The first is my printer. The printer behind me in my office is very definitely Mountain One. We don't print much. Every time I come to it, it never quite works, but we always get there in the end.
The second is trains. British trains — apologies to anyone working in the transport network — are a Mountain One experience for many of us. If you need to make a journey with several changes, you'll build in large buffers because you're not quite sure whether things will run on time.
⛰️ Mountain Two: Working as Expected
Mountain Two is reliability. Consistency. Trust.
Back at Amazon, we had professionally managed laser printers. They always worked. If the paper ran out, there was a stack underneath and a laminated card telling you what to do. That's Mountain Two — not because the technology was better, but because the process around it was mature.
The Swiss train system is the other end of my train analogy. You'd happily book connections with only a few minutes between them because you know they'll run on time. You know this because there's a reputation, but also because you've already done it. There's an experience factor — you've tested it and it delivered.
For the membership question on Mountain Two: you go to one system, it tells you the number, and it's reliably correct every time. No phone calls, no cross-referencing, no ambiguity about definitions. The answer is there because the data is trusted and the processes that maintain it are mature.
The gap between the two mountains isn't primarily about technology. It's about the maturity of the processes that manage, maintain, and keep everything up to date. You can have excellent software and still be on Mountain One if the data going in is inconsistent or the processes around it are informal.
🌫️ Mountain Three: The Misty Peak
Mountain Three is always enshrined in mist. You never really get there. It's the aspirational destination — data warehousing, predictive analytics, five-year planning horizons, board-ready insights.
The client who prompted this model was keen on exactly this. They wanted powerful reporting across their entire organisation. Business intelligence from their data. And they were right to want it. But to do that, you need solid data. If you start extrapolating forward or asking questions of data that's unreliable, you'll get terrible results.
What I had to do was walk them back. "What you're describing is Mountain Three. But your data is Mountain One right now. We need to get you to Mountain Two first — to the place where you trust your data — before we talk about extrapolating it forward. If you want to take data to the board for a five-year planning horizon, you want Mountain Two data. You don't want numbers pulled together from contradictory spreadsheets that give different answers depending on which week you run them."
This is where the model earns its keep. It gives people language to have an honest conversation about readiness. Not "your data is bad" — which nobody wants to hear — but "you're on Mountain One, and Mountain Three needs Mountain Two foundations."
🏞️ The Valley Nobody Warns You About
The twist that broke the model free from its primary school origins was this: you can't teleport between mountains. And between each mountain is a valley.
In all change management, things get worse before they get better. You were comfortable on Mountain One. You knew your bus and train connections were a bit ropey, but at least you knew how they worked. You'd found the coffee shop where you wait. Now someone's asking you to change to a completely different system. Yes, you can see you'll get there faster eventually, but right now it's uncomfortable. You're in the valley.
The resistance to change in all of us is surprisingly strong. Many people expect some form of teleportation — install the software and arrive at Mountain Three. Software is a bit magical to people who aren't familiar with building it. They believe it will just deliver some amazing future. And we kick ourselves in the foot because sometimes we can deliver magic and we love to do that. But most of the time there's not much magic. It's mostly hard craft, plotting along, trudging down the mountain, undoing things you thought were done, then trudging up the other side.
If you've been walking up a mountain, the idea of walking down feels like relief. Your legs will love that. But very quickly, if you're walking down a steep descent, your legs hurt going down as well. The valley is painful in both directions.
🔄 The Jevons Twist
Here's the hidden twist. Mountain Two doesn't stay Mountain Two.
I came across the Jevons paradox while writing an AI white paper for our company. William Stanley Jevons studied steam engine efficiency in the nineteenth century. When a step change in technology made steam engines far more efficient, you'd expect coal consumption to fall — you need less coal per unit of work. It didn't. It shot up. Because now people did far more with their steam engines.
This is exactly what happens with the mountains. You reach Mountain Two. You achieve reliable, consistent results. Nobody takes the win. What they see is: I'm standing up here, I can see further, and there's another mountain I want to reach. Your expectations shift. What was Mountain Two becomes a new Mountain One, because you're now demanding more from it. Mountain Three keeps shifting away.
I built a unified log dashboard recently — threw some prompts into Claude Code, vibe coded for a couple of hours, and came back with something that pulled data from several sources into a clean interface. Mountain One to Mountain Two in an afternoon. But immediately I'm on Mountain Two thinking: now that I've got this data, I want to go further. The cycle restarts.
It's fractal. It happens at every level — whole company, department, individual process. Whatever problem you immerse yourself in, whatever scale you're working at, the mountains are there.
🧭 Using the Model
If you want to apply this, five steps.
Pick the right problem. Don't try to assess the whole landscape. Zoom in. You might have an amazing finance function but a Mountain One data process sitting inside it. Choose your zoom level and be specific. Too big a canvas and you'll struggle.
Be honest about where you are. Most people think they're further along than they are. Everyone wants to say they're on Mountain Two. Ask yourself: how consistent are my results? If I swapped myself out, could someone new pick this up? How resilient is this process to unexpected change? I've never found anyone genuinely on Mountain Three. We tend not to care about the things we're already excelling at — we live in the world of problems.
Identify the right valley. Be clear about which descent you need to make. Going down the wrong valley wastes the pain. The way I structure this with clients is to lay out the model, talk through the characteristics of each mountain, and let them self-identify where they are. The best way to help someone see they're on Mountain One is not to tell them — it's to let them make that decision themselves.
Prepare the team. You're not walking alone. You're leading, which means by definition you're taking other people down into the valley and up the other side. Do they trust you? Are you going to be there when the valley is harder than expected? This works on several levels — are you there physically, or are you a fractional who might not be around when the next mountain is reached? And are you actually present and helping, or just shouting directions from a helicopter?
Be realistic about the destination. By the time you reach Mountain Two, it may have moved. The goalposts shift — every paradigm change pushes the expected standard further out. Expect a conveyor belt, not a finish line. When you arrive, it will probably be the next milestone on a longer journey, not the end.
🗺️ The Map Warning
All metaphors break if you stretch them hard enough, and this one will definitely snap if you push it. I've tried mapping out mountain four, five, six — assigning each project milestone its own peak. I've pulled it back to three. Arguably it's really two, with one in the mist. But it's had good mileage over the years.
The part I keep coming back to — and this applies well beyond databases and membership organisations — is the danger of putting the map away. The common mistake I make when walking actual mountains is thinking I know where I'm going, stuffing the map in my bag, and then getting to a point where the valley doesn't look right. On real mountains, that can be the difference between life and death. For companies and projects, it can be similarly fatal.
If AI makes us faster — and there's every indication it will — then we need to get really good at understanding our position. Keeping track of where we are, where our teams are, before anyone goes shooting off in the wrong direction. Measure twice, cut once. And keep checking the map.
This post is based on a conversation with Adam Horner on The CTO Playbook podcast, Episode 77.