Redgum Private Review

Building Capability

Chapter 7: Capability Builds on Capability

Chapter 7: Capability Builds on Capability — chapter artwork

Before you read — by the end of this chapter you will understand:

  • Why capability compounds — and how each layer unlocks the next
  • The levels model: why level one has to be easy
  • How to structure a roadmap of discrete, sequenced deliverables
  • The “choose your own adventure” model for managing long-term development investment
  • How to balance building new capability against embedding what you’ve already got

One of the metaphors I keep coming back to is the idea of levels in a game.

Think about any well-designed game, the kind that holds your attention for months, not minutes. Level one is accessible. It teaches you the controls, the rules, the logic of the world. You can complete it without too much difficulty. That’s intentional.

The designers know that if level one defeats you, you’ll never see level two, and all the brilliant, complex, deeply satisfying things they built into levels ten, fifteen, and twenty will never be experienced by anyone.

Level one is easy not because the designers couldn’t make it hard. It’s easy because level one isn’t the point. Level one is the door.

This is precisely how I think about capability building.

The Levels Model

When I start a new capability build, I’m not just thinking about what we’re building right now. I’m thinking about what has to be true of it later. What has to be in place by the end of release one so that release two is possible? What has to be true of release two so that release five becomes conceivable?

This changes everything about how you design the first phase.

A lot of technology projects fail in the long run not because the first phase didn’t work, but because the first phase was designed without the later phases in mind. It was built as a complete solution, a finished thing, rather than as a foundation. And when the organisation wants to expand, they find that the first phase can’t carry the weight. The architecture doesn’t support it. The data model is wrong. The integrations aren’t there. And so instead of extending what they have, they have to rebuild.

That’s expensive. It’s demoralising. And it’s avoidable.

The levels model says: even if you’re only building level one today, you design it knowing where you’re heading. Not because you’ll build all of it now, you won’t and you shouldn’t, but because the foundations have to be right.

Level one should be achievable, valuable, and relatively quick to deliver. But it has to be the right kind of level one: the one that makes level two, five, and twenty possible.

Building the Roadmap

The output of this thinking is a roadmap. Not a Gantt chart. Not a project plan with fixed dates and milestones. A roadmap in the truest sense: a picture of where you’re going and the sequence of steps it takes to get there, with enough flexibility to adjust as you learn.

Here’s what a well-constructed capability roadmap looks like in practice.

After the initial discovery and design phase, we produce a list of capabilities: everything the organisation wants to be able to do, everything we’ve identified that would create value, everything the team has asked for during consultation. That list is long. It should be long. We’re not filtering it yet; we’re capturing the full picture.

Then we organise it. What’s foundational, meaning what has to exist before anything else can? What’s additive, things that extend and enhance once the foundation is solid? What’s transformational, the things that change what the business is capable of in a fundamental way?

Those three categories usually map naturally to a release sequence. Releases one and two are foundational. Releases three through six are additive. Releases seven through ten are transformational. The exact numbers don’t matter; the logic does.

Each release becomes a discrete, self-contained deliverable. It can be built, tested, and deployed independently. It delivers real value on its own. But it also advances the platform: it makes the next release more possible and more powerful than it would have been without it.

The Choose Your Own Adventure Model

Here’s something I’ve learned from doing this for a long time: no organisation builds a capability roadmap in a straight line.

Life intervenes. Priorities shift. A new customer requirement changes what’s most important. A team member leaves and creates a gap somewhere unexpected. The budget that was available in Q1 isn’t available in Q3. A competitor does something that makes a particular capability suddenly urgent.

This is not failure. This is reality.

I worked with Phillip, a construction law partner who had spent two to three years of conceptual development, flow charting, conversations with IT professionals, mapping the complexity of construction project management, before we started building anything. His preparation was extraordinary. He understood his domain deeply and he’d thought carefully about what the system needed to do.

But even with all of that preparation, the roadmap didn’t follow a straight line. Construction projects have unique requirements that emerge only when you’re inside them. Regulatory nuances appear at unexpected stages. Client feedback from early users reveals use cases that weren’t visible in the planning phase.

What made the engagement work, nearly 200 weekly sessions over the life of the project, was treating the roadmap as a living document. At any given point, the next step was clear and specific. The steps beyond that were visible but flexible. The architecture of what had already been built was solid enough to support whatever came next, regardless of which direction “next” turned out to be.

A good roadmap accounts for this. Rather than a fixed sequence, release one then two then three in order with no deviation, a mature capability roadmap is a menu. Here are the available next steps, here is what each one delivers, here is what it costs, here is what it enables. You choose.

The organisation retains strategic control over their own investment. We provide the expertise about what’s possible, what’s advisable, what will unlock the most value. But the sequencing decisions are made in consultation, regularly revisited, and adjusted based on what’s actually happening in the business.

This is what I mean when I describe it as a choose-your-own-adventure model. You’re not handed a map with a single route and told to follow it. You’re given a world with multiple paths, a guide who knows the terrain, and the autonomy to decide which direction serves you best right now.

The constraint, and it’s an important one, is that some paths require you to have walked other paths first. You can’t skip level ten to level twenty. The sequence has internal logic. But within that logic, there is genuine flexibility.

The Balancing Act: New vs. Existing Capability

There’s a tension in every ongoing capability build that doesn’t get talked about enough, and it causes more friction than almost anything else.

On one side, you have the pull toward new capability: the exciting stuff, the next thing the system can do, the next feature that gets people talking, the next release that changes something meaningful.

On the other side, you have the weight of existing capability: the things already built that need to be refined, improved, embedded. The users who are still on a learning curve. The processes that haven’t fully settled into the new way of working. The edge cases that the first release didn’t handle elegantly.

Both are legitimate. Both need investment. And if you ignore either one, you create problems.

An organisation that only ever chases new capability ends up with a sprawling, unstable system full of half-finished things that the team hasn’t fully adopted. They keep building on sand, and eventually something falls.

An organisation that only ever embeds and refines existing capability stops moving. The technology stabilises, the team gets comfortable, and the competitive advantage that was supposed to come from the investment never quite materialises, because nothing new is being created.

The right balance is roughly 60/40 in most mature engagements: sixty percent of investment going into enhancing and embedding what’s already there, forty percent going into new capability. The specific numbers aren’t sacred. I’ve moved that slider significantly in both directions depending on the client’s situation. But the principle is: you need both, always.

Knowing which direction to push the slider at any given moment is part of the craft. And it’s one of the reasons why this is a long-term relationship, not a one-time project.

Why You Can’t Skip

I want to be direct about something, because I’ve had this conversation more than once with clients who see the roadmap and want to jump straight to the exciting stuff.

You can’t skip.

Not because I’m being precious about the process. Because the architecture doesn’t support it. Because the data isn’t there yet. Because the organisation hasn’t built the muscle to absorb a level-ten change when they’re still getting comfortable with level three.

I’ve seen what happens when organisations try to shortcut the sequence. They end up with a system that technically exists but doesn’t work the way it should. The users haven’t been brought along. The foundations weren’t right. The integration points weren’t designed for what was eventually bolted onto them. And the whole thing becomes fragile, dependent on a few key people who understand its quirks, unsustainable as those people move on.

The shortcut costs more in the long run, without exception.

Level one has to be right before you go to level two. Not perfect, it will never be perfect, and waiting for perfect is its own kind of failure. But right. Solid. Something you can stand on with confidence and build upward from.

That’s the discipline. And it’s the thing that separates the organisations that genuinely build long-term capability from the ones that build expensive problems.

Where We’re Going Next

If the roadmap is the map, and the proof of value is the first step, then the next question is: what do you put on the map? What capabilities are worth building, in what sequence, using what tools?

That’s where technology comes in. Not as the first answer, never as the first answer, but as the enabling layer that makes everything else possible.

In the next chapter, we’ll talk about technology: how to think about it correctly, how not to let it drive decisions it shouldn’t be driving, and what the cloud actually changes, and doesn’t change, about building long-term capability.

Tool: The Capability Roadmap Builder

The thinking in this chapter only becomes useful when it’s applied to your specific situation. This tool helps you take the full list of things your organisation wants to build and turn it into a coherent, sequenced roadmap.

Step 1 — List everything. Before filtering or prioritising, write down every capability your organisation has discussed building, across all departments, all horizons, all “wouldn’t it be great if…” conversations. Don’t judge yet. Just list.

Step 2 — Categorise by type. Sort each item into one of three categories:

  • Foundational — must exist before anything else can be built
  • Additive — builds on the foundation to extend what’s possible
  • Transformational — changes what the business fundamentally is or does

Step 3 — Sequence within each category. Within each category, order the items by dependencies first (what must come before what), then by value soonest.

Step 4 — Define your releases. Map the sequenced items into discrete releases. Each release should deliver genuine value on its own and advance the platform for the next release. For each release, capture: what’s included, what value it delivers, and what it makes possible next.

Step 5 — Check the balance. What percentage of your roadmap is new capability versus enhancement of what’s already built? A healthy ongoing build typically runs around 40% new, 60% embed and refine. Skewing too far in either direction creates problems.

Want to go deeper?
The online version of this tool includes a full visual roadmap template, a release planning worksheet, a guide for running quarterly roadmap reviews, and the “choose your own adventure” sequencing framework for managing changing priorities without losing architectural coherence.
Available in the members area at [website]