Building Capability

Chapter 12: The Long Game

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

• Why true capability builders think in years, not projects
• How successive wins compound into transformational change
• Redgum’s four guiding principles for capability building
• The difference between what most technology firms offer and what this process delivers
• What your business could look like if you committed to the long game

I want to start this chapter with a question.

If you handed your business to someone else tomorrow — a competent, capable person who shared your values and your ambition but didn’t have your personal knowledge of how things worked — how well would they go?

Could they onboard a new client without you there to explain the nuances? Could they manage a project through delivery without calling you for decisions that only you know how to make? Could they resolve a dispute with a customer using the frameworks and the knowledge your organisation has built, rather than relying on your personal judgment?

For most organisations I work with, the honest answer is: not as well as they’d like.

Not because they haven’t tried. Not because they haven’t grown. But because the capability that makes the business valuable, the knowledge, the expertise, the way of doing things, lives largely in people, not in systems. And that means it doesn’t scale. It doesn’t persist through staff changes. It doesn’t survive the founder’s unavailability, let alone their exit.

This is the long game. Not just building a system to solve a problem, but building a business that can keep doing what it does well, at increasing scale, without requiring the same people in the same seats every time.

That is what genuine capability building, done over years, makes possible.

Compounding Wins

One of the patterns I keep returning to in this book is compounding. The idea that well-constructed wins don’t just deliver their own value. They make the next win more possible, more valuable, and easier to deliver.

I want to show you what this looks like at the scale of a multi-year engagement, because the numbers become genuinely surprising.

An organisation that builds just one new capability per quarter, twelve capabilities in three years, doesn’t just have twelve capabilities. They have a foundation, several layers of structure built on that foundation, and an outer layer of genuinely transformational capability that wouldn’t have been conceivable without the layers beneath it.

The first year typically delivers efficiency and capacity. Time saved. Errors reduced. Volume handled without headcount increase. These are real wins. They’re tangible and measurable. They pay for themselves.

The second year delivers the capability that changes what the business can offer. New services. Better client experience. The organisation starts to be able to do things that competitors cannot, or cannot do at the same quality or price.

The third year, and this is the part that’s hard to convey to someone at the beginning of the journey because it sounds ambitious, the third year often delivers something that looks like a different business. Not a different industry, not a different market. But a business that has stopped competing on the same terms as its nearest competitors and started operating in a category where direct comparison becomes difficult.

The News Ltd / Optima story is the clearest illustration I have of what this arc looks like at scale. The project did not start as an attempt to transform a national publisher’s operations. It started with a specific, solvable problem: departments were making decisions based on information that was already out of date. The entry point was modest enough to be achievable. But the architecture was designed with a much larger picture in view.

What emerged over time was a live digital model of the newspaper itself, a platform where a single advertising booking would ripple through editorial space allocation, press configuration, and financial projections simultaneously. Finance moved from reviewing results two months after the fact to forecasting profitability weeks ahead. Sales moved from selling space they could not fully verify to searching availability across every title and every edition in real time. Every department stopped managing reactively and started managing forward.

That capability did not exist in the industry before it was built. No competitor could acquire it by purchasing a standard platform. It was constructed layer by layer, each phase making the next one possible, until the organisation was operating in a fundamentally different way to anyone around it.

Lilydale Books tells the same story at a different scale. Year one: a better way to manage back-of-house stock and orders. Operational. Unglamorous. Real. Year two: a parent-facing portal that changed how families experienced the back-to-school process entirely. Year three: new school onboarding, growing from ten schools to forty-two and still growing, with a client experience that larger generic competitors with national distribution simply were not built to replicate.

Two very different organisations. The same pattern. Each year’s capability unlocking the next. The end state in each case not being a faster version of what they had before, but something that operated by different rules entirely.

I’ve seen this play out across a number of clients.
APS, a third-generation accounting software business with thirty established desktop products, faced the classic compounding dilemma. Their development team was fully occupied maintaining existing revenue-generating products. They couldn’t afford to divert resources to build cloud capability from scratch, but they also couldn’t afford to keep explaining its absence to prospects.
The answer was to start small and build the foundation: a single cloud reference application that demonstrated the architecture and proved the approach. That first release wasn’t the product. It was the proof that the product was possible. It gave investors confidence, opened conversations with new customers, and gave the internal team a working model to build from. Everything that followed was made possible by that first deliberate step.

I’ve watched this happen. It’s not magic. It’s compounding.

And here’s the thing: organisations that skip the first year, that try to go straight to the transformational capability, never get there. Because the foundation isn’t there. The layers aren’t there. The organisation hasn’t built the muscle to absorb or operate at that level.

You can’t shortcut compounding. You just have to start.

The Four Principles

I want to close this book by laying out explicitly the principles that have guided every successful capability build I’ve been part of. Not as a checklist, I’m suspicious of checklists, but as a way of articulating what I believe about this work, after three decades of doing it.

1. Think big. Think whole-business first.

Before any technology decision is made, before any process is mapped, before any brief is written, understand the whole business.

• What does the end customer actually need?
• What value is the organisation genuinely creating?
• What would the business look like if it were running at its best?

This is the step most organisations skip because it’s slow and it doesn’t feel like progress. It feels like talking instead of doing. But it is, without question, the most important step. The organisations that do it properly consistently build better things faster than those that don’t.

If you’re an existing business: start with the customer. Strip away all the assumptions about how delivery should work. Look at what the customer actually needs and work backward.

If you’re building something new: look beyond the technology. How does it fit into business strategy, branding, messaging, marketing, sales, conversion, retention? Understand the whole customer lifecycle from their point of view. Only then tune the technology to support it.

2. Make it consultative. Always.

The client and the development team are exploring together. Not the client directing and the team executing. Not the team designing and the client approving. Exploring together.

This requires a different kind of engagement from the client than most technology projects ask for. It requires showing up, asking questions, being challenged, revisiting assumptions, and being genuinely open to finding out that the original idea wasn’t right.

It also requires a different kind of relationship from the development side: not just a service provider following a brief, but a genuine thinking partner who brings perspective and challenge as well as execution.

When that relationship works, when both sides are genuinely in the work together, the outcome is reliably better than anything that could have been specified in advance.

3. See it as a long-term investment that returns early and keeps returning.

Don’t see a capability build as a project with a start and an end. See it as an investment vehicle with a specific kind of return profile: quick wins in the early stages, progressively larger returns as the foundation matures, and compounding value over time.

This mindset changes how you evaluate each phase. A phase that delivers modest direct value but lays critical foundation for something larger isn’t a disappointment. It’s essential infrastructure. A phase that takes longer than expected but teaches you something important isn’t a failure. It’s tuition.

The long-term view allows you to hold both: the urgency of delivering genuine value early, and the patience to build things properly for where you’re going.

4. Be in the journey.

This is perhaps the most personal principle, and the one I feel most strongly about.

You have to be genuinely in the work. Not watching from a distance. Not delegating the decisions to someone who’s delegating them to someone else. Not throwing the brief over the wall and waiting for the delivery.

Be in the conversations. Make the hard calls. Be willing to be challenged. Run the experiments. Sit with the discomfort of shipping something that isn’t perfect. Engage with the feedback. Come back to the table when something doesn’t work the way you hoped.

The organisations that genuinely build long-term capability are the ones that treat this as their work, not as work they’ve outsourced. We bring expertise, capability, and perspective. But it’s your organisation. Your customers. Your people. Your future.

That ownership can’t be contracted out. It has to come from you.

What This Looks Like in Practice

Let me try to make this concrete.

An organisation that commits to the long game doesn’t look like an organisation launching a technology project. It looks like an organisation that has integrated technology investment into how it thinks about growth.

Quarterly roadmap reviews are a standing fixture in the calendar. The capability build is a line item in the annual budget, not a one-off capital expenditure. When a senior leader talks about strategy, the capability roadmap is part of the story. New staff are onboarded into a culture where the systems reflect the organisation’s best thinking, and where improving those systems is everyone’s responsibility.

The development relationship is a long-term partnership, not a series of project engagements. There’s shared history. The team that’s building knows the business. The business knows the team. Trust has been earned through a succession of wins and through navigating the inevitable moments where things were harder than expected.

And the business is doing things it couldn’t do two years ago. Not incrementally better at the same things. Genuinely capable of things that weren’t possible before.

That’s the picture. It’s not hypothetical. I’ve seen it happen, more than once.

The Business You Could Be

Let me come back to the question I started with.

If you handed your business to someone tomorrow, if you stepped back, or stepped out, or handed it to a management team, or sold it to a buyer, what would they find?

Would they find a business whose value lives in systems, in documented processes, in captured expertise that new people can learn and apply? Or would they find a business that works because of who’s in it right now, that depends on knowledge that nobody’s written down, that would be significantly diminished by the departure of two or three key people?

This isn’t just an exit question. It’s a growth question. Because the same constraints that make a business hard to sell also make it hard to scale. The same dependency on key individuals that makes an exit complicated makes an expansion complicated. The same undocumented expertise that limits a buyer’s confidence limits a new employee’s effectiveness.

Phillip, a construction law partner, spent two to three years thinking through exactly this problem before he started building. He knew that the expertise that made his work valuable was locked in his head, in the patterns he’d recognised across hundreds of disputes, in the procedural knowledge that only came from years in the industry. His goal wasn’t to automate his job. It was to give that expertise a form that could operate beyond him. After nearly 200 weekly conversations with his development team, what emerged was a system that captured how construction projects actually worked, not generic project management assumptions, but the specific legal and procedural complexity of the construction industry. His knowledge didn’t disappear when he stepped back. It was in the system.

Building genuine capability, over time, in layers, done properly, solves this problem. Not all at once. Not with a single project. But progressively, compoundingly, and in ways that keep generating return long after the initial investment is made.

The business you could be is not some hypothetical future version of yourself. It’s the business that exists when the knowledge you’ve accumulated, the processes you’ve refined, and the expertise you’ve built over years is no longer trapped in individuals, but lives in systems that your team can use, your customers can access, and your organisation can rely on.

That’s the long game.

And it starts with the decision to play it.

A Final Word

I’ve been doing this work for a long time. Long enough to have made most of the mistakes in this book myself, before I understood what I was doing wrong. Long enough to have watched organisations that committed to this approach build things that genuinely changed their trajectory. Long enough to know that the principles aren’t complicated. The execution is what’s hard.

If you’ve read this far, you understand what building capability actually means, what it requires, and what it makes possible.

What comes next is yours to decide.

But if you want to start, if you’re ready to look at the whole picture, understand the real opportunity, and take the first deliberate step toward the business you could become, I’d suggest starting with an honest conversation about where you are and where you want to go.

Not a technology conversation. A business conversation.

That’s where it always begins.

Tool: The Long Game Capability Audit

This tool is both a diagnostic and a planning exercise. It gives you an honest picture of where your organisation currently sits on the capability-building journey, and a first step toward closing the gap.

Step 1 — The franchise prototype test. If you handed your business to a competent new owner tomorrow, what knowledge currently lives only in people, not in systems? What would break in the first week? What would they not be able to do at all without two or three specific individuals? Be honest. This is the gap capability building is designed to close.

Step 2 — Locate yourself in the journey. Which of these best describes your current stage?

• Pre-start — capability exists in people and informal processes, nothing systematised yet
• Year one — first phase delivered, proof of value established but not much more
• Building layers — multiple releases, growing adoption, additive capability underway
• Compounding — returns are building on each other, the business is becoming different
• Mature — capability is embedded, thinking and investing in years

Step 3 — Rate the four principles. From 1 (not at all) to 5 (genuinely strong), how well does your organisation currently live each of these?

• Think big. Think whole-business first.
• Make it consultative. Always.
• See it as a long-term investment that returns early and keeps returning.
• Be in the journey.

Your lowest scores are where the long game is most at risk.

Step 4 — Write your long game statement. Complete this sentence: In five years, this organisation will be able to [do what it currently can’t], for [whom], because we have [built what capability]. We will know we’re on track when [what milestone] is reached by [what date].

Step 5 — Name your single most important next action. What is the one thing you need to do in the next 90 days to move toward that picture? Who owns it?

Want to go deeper?
The online version of this tool includes a full capability maturity model assessment, a five-year capability roadmap template, a guide for building the internal structures (budget model, governance, review cadence) that sustain the long game, and a facilitated annual review workshop format.
Available in the members area at [website]