Building Capability

Chapter 11: Don't Let It Plateau

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

• Why capability builds plateau - and why that’s a choice, not an inevitability
• The opposite failure mode: building too fast and overwhelming the organisation’s capacity to absorb change
• How to manage the organisation’s capacity for change as the real bottleneck
• The capability growth cycle: design, build, embed, expand
• The roadmap as a living document, not a fixed plan
• The department budget model and how it keeps momentum alive

There’s a particular moment I’ve seen in capability builds that I’ve come to dread.

It usually happens somewhere between six and eighteen months after a successful initial deployment. The system is working. The proof of value was delivered. The team is using it. The organisation is seeing the benefits.

And then… nothing.

The roadmap that was agreed sits untouched. The backlog of ideas that the team generated in the early consultation sessions never gets revisited. The energy that was present at the beginning, the excitement, the sense of possibility, has quietly dissipated.

The organisation has plateaued.

Not because the work is done. Not because everything worth building has been built. But because the moment of crisis that prompted the original investment has passed, because the immediate pain that drove the decision is no longer acute, because the next phase requires deliberate decision-making that nobody has found the time for.

A plateau is not a resting point. It’s a slow decline.

This matters more than most leaders realise. Research consistently shows that a significant proportion of technology projects are judged to have failed to reach their goals, and the plateau is one of the leading reasons. The first release delivers a visible, measurable return — a process that works, a risk that’s managed, a team that has more time. But that initial return is almost never where the real value lives.

The substantial value addition comes later, and it doesn’t arrive as a single large payoff. It accumulates. Each new capability layer, each embedded process, each additional use case adds to the total. It’s the compounding of many different elements over time that materially increases the value of the organisation as a whole. The organisations that plateau after the first release capture only a fraction of what was available to them.

Why Plateaus Happen

Understanding why plateaus happen is the first step to preventing them.

The most common cause is what I’d call the relief problem. Before the first capability was built, the organisation had a genuine pain: a process that didn’t work, a risk that was exposed, a capacity constraint that limited growth. The first phase addressed that pain. And in addressing it, it also removed the urgency that was driving the investment.

When the pain is gone, the pressure to keep building goes with it. Other priorities re-emerge. The budget that was available because the situation was urgent becomes contested again. The project sponsor who was championing the work moves on to the next fire.

This is completely understandable. And completely counterproductive.

Because the value that was delivered in the first phase, real as it was, is a fraction of the value that’s available in the phases that follow. The organisations that treat the first phase as the destination, rather than the beginning of the journey, leave most of the return on the table.

I want to share a story that illustrates exactly how this plays out.

We worked with a retail wine merchant. Strong physical stores, loyal customer base, and a genuinely terrible online experience. When we analysed their traffic during the COVID lockdowns, we found a single unnecessary step in the checkout process that was costing them around $100,000 a year in abandoned transactions. One screen. We fixed it.

But that was never the real vision. What we had mapped out was a five-year capability build: an app-based retail experience that would change how wine was discovered, purchased, and enjoyed. Truly different from anything else in the market. The kind of capability that would have made their physical presence an asset rather than a constraint, connecting in-store experience with a digital layer that deepened the relationship with every customer who walked through their doors.

The first release went live just as lockdowns ended. And with the lockdowns went the urgency. Online traffic dropped back as people returned to physical stores. The immediate pain, the leaking checkout, had been resolved. And rather than asking how to build the next layer, how to bring the online and in-store experience together in a way that would be genuinely hard to replicate, they shelved the roadmap and went back to what they knew.

The result was a standard online store. Pick a product, check out, receive it. The same as a hundred other wine merchants.

Five years later, the business is shrinking. Their physical store network is under pressure from the same retail pattern changes that were already visible when we first started the work. The window to build something genuinely differentiated is much narrower now.

The relief problem didn’t just pause their capability build. It took away their best chance to change which race they were in.

The second cause is capacity: the organisation’s own capacity to absorb change. This is one of the most under-discussed constraints in capability building. The technology is almost never the bottleneck. The market is almost never the bottleneck. The people’s ability to adapt to new ways of working, to integrate new tools and processes into an already busy working day, is almost always the bottleneck.

A capability build that moves faster than the organisation can absorb creates churn. People revert to old habits. The new system gets circumvented rather than adopted. Trust in the process erodes.

Moving at the right pace is not compromise. It’s craft.

The Opposite Problem: Building Too Fast

The plateau has an equal and opposite failure mode. And it’s easy to miss because it looks like momentum.

Some organisations, having seen what capability building can do, push too hard and too fast. The roadmap becomes aggressive. Releases come before the previous one has been properly embedded. The team is always building the next thing while users are still figuring out the current thing. Change fatigue sets in, not because people don’t want the capability, but because they haven’t had enough time to absorb it and make it part of how they actually work.

The result is the same as the plateau, just arrived at by a different route: a set of capabilities that nobody is fully using.

A system that’s been deployed is not the same as a system that’s been adopted.

Deployment is the beginning of the adoption process, not the end of it. If the next release arrives before that process is complete, you’re building on a foundation that hasn’t fully set.

The signals are different from a plateau but just as readable. People are using workarounds around the new system rather than through it. The help requests are still about basics. The user feedback from the last release is still unresolved when the next one arrives. Training for the current release is still in progress when development of the next one starts.

The right pace is the pace the organisation can genuinely absorb, not the pace that’s technically possible, and not the pace that feels safe because nothing is being challenged. Both extremes produce the same outcome.

The Capability Growth Cycle

The antidote to the plateau is a deliberate, recurring cycle of activity that keeps the capability moving forward without overwhelming the organisation.

I think of it in four stages: design, build, embed, expand.

Design is the thinking work: understanding where the next opportunity lies, what the next phase should deliver, how it connects to the broader roadmap, and what it will take to build it. This is not a one-time activity at the beginning of the engagement. It happens at the start of every cycle.

Build is the development work: taking the design and turning it into a working capability. This is the stage most people think of when they think about technology projects, and it’s the smallest part of the value in a mature capability build.

Embed is the adoption work: making sure the capability is genuinely used by the people it was built for. Training, documentation, support, user acceptance, refinement based on real-world feedback. This is where most first-time capability builders underinvest, and where most plateaus are born.

Expand is the growth work: taking what’s been embedded and extending it. New users, new use cases, new departments, new layers added to the capability. This is where the compounding effect kicks in.

The Optima project at News Ltd is a good illustration of how this plays out in practice. It started as a single point solution for a single small department: a tool that gave one team better visibility of their own results. That was it. The problem it solved was real, the scope was contained, and the first release didn’t try to be everything.

But once one department had visibility, others could see what was possible. The next phase extended that visibility across the business, giving every department a view of how their results connected to the whole. And from there, the work became more specific: each department getting tooling designed around how they actually worked, not just a shared view of shared data. Sales had what sales needed. Finance had what finance needed. Editorial had what editorial needed. Press configuration was built to match the reality of press operations.

What became a genuinely significant capability for the entire organisation started because one small department had a problem worth solving. Nobody tried to build all of it at once. They designed the first phase, built it, embedded it, expanded it, and then let what they’d learned shape what came next.

The cycle then repeats. Design the next phase. Build it. Embed it. Expand it.

The key insight is that these four stages are always happening, just at different points of the roadmap. While you’re building the next release, you’re embedding the current one. While you’re expanding what’s already embedded, you’re designing what comes next. It’s not a linear sequence. It’s a perpetual motion.

Organisations that understand this don’t plateau, because there’s always something in each stage. The work is never done. It’s always moving.

The Living Roadmap

A capability roadmap is not a document you produce once and archive.

It’s a living artefact, something that reflects the current state of the organisation’s thinking about where it’s going and how it’s going to get there. It evolves as the business evolves. It changes when circumstances change. It’s reviewed regularly, updated deliberately, and owned by the people who are going to act on it.

In practice, this means scheduling regular roadmap reviews. Not every week, that’s too frequent to produce meaningful change. But at least quarterly: what’s been delivered, what’s being built, what’s coming next, what’s shifted in priority, what’s been learned that changes the picture.

These reviews serve multiple purposes. They keep the investment active in the minds of the people who control the budget. They surface emerging priorities before they become crises. They create a regular cadence of decision-making that prevents the “we’ll get to it eventually” drift that produces plateaus.

And they give the team, internal and external, a regular checkpoint to raise what they’re seeing. Things that the design didn’t anticipate. Opportunities that emerged from the work that wasn’t visible at the outset. Adjustments that would make the current capability significantly more valuable with relatively little additional investment.

The roadmap review is a discipline. It requires someone to own it, schedule it, facilitate it. In my experience, this is best owned internally, not by the development team, but by a senior person in the organisation who has genuine authority to make decisions.

When that ownership is present, the roadmap stays alive. When it isn’t, the roadmap collects dust.

Managing the Organisation’s Capacity for Change

I want to spend a little time on this because it’s the constraint that surprises people the most.

Leaders often assume that the bottleneck in a capability build is technical: the development team’s capacity, the platform’s limitations, the complexity of the integration requirements. And those constraints are real.

But in a mature, ongoing capability build, the bottleneck is usually the organisation itself.

Not in a negative sense. People are busy. They have jobs to do. A significant system change requires them to learn something new, to adjust habits they’ve built over years, to potentially work differently with their colleagues. That takes time and cognitive bandwidth that isn’t unlimited.

If you try to build and deploy too many changes at once, you overwhelm the system. People can’t keep up. Quality of adoption drops. The changes don’t stick. And you end up with a lot of half-embedded capabilities rather than a smaller number of fully embedded ones.

The art is pacing.

Understanding how much change the organisation can absorb in a given period, taking into account seasonal pressures, organisational changes, other initiatives running in parallel, and calibrating the build cycle to match that capacity.

This is partly a numbers problem (how many releases in how many months?) and partly a culture problem (how quickly does this organisation typically adopt change?). Both dimensions matter.

I’d rather deliver three perfectly embedded releases in a year than six half-adopted ones. Slow and solid beats fast and superficial, every time.

The Department Budget Model

One of the practical structures that helps prevent plateaus in larger organisations is the decentralised budget model I mentioned in the previous chapter.

It’s worth elaborating on here because of how directly it relates to momentum.

In a centralised model, all technology investment decisions sit with leadership. Every new phase has to go through a formal approval process. The organisation’s appetite for investment is a single decision made by a small number of people at a central level.

That model creates bottlenecks. The people who most want to invest in the next phase of their capability, the department heads who are seeing the value up close every day, are dependent on decisions being made by people who are further from the evidence. Approval timelines are long. Other priorities compete. The momentum that should be building slows down.

In a decentralised model, each department controls a portion of the technology investment budget for capability that primarily serves their team. The head of operations can invest in operations capability. The head of sales can invest in sales capability. They don’t need central approval for every decision.

Leadership maintains a coordination budget: the investment that affects the whole organisation, that requires integration across departments, that serves strategic priorities rather than departmental ones. Leadership makes the decisions that only leadership can make.

This creates a remarkable shift in energy. Department heads who own their own capability investment are motivated in a completely different way from department heads who are waiting for a central decision. They’re proactive rather than reactive. They surface opportunities rather than complaints. They champion the capability because it’s theirs.

And critically: the work keeps moving. Not because there’s urgency, but because there’s ownership.

The Signals That a Plateau Is Coming

I’ll close this chapter with something practical: how to recognise, early, that a capability build is heading toward a plateau.

The roadmap review gets cancelled or postponed. When it stops being a priority to look at where you’re going, you’re already drifting.

The user feedback stops coming. When the team stops surfacing problems and suggestions, it usually means one of two things: either everything is perfect (almost never), or people have disengaged from the idea that their input matters (much more common).

The language shifts from “what’s next” to “what we’ve done.” When the conversation is primarily about celebrating what was built rather than planning what comes next, momentum is already slowing.

The development team is being used for maintenance rather than growth. If most of the technical work is bug fixes and minor adjustments with no new capability in progress, the growth cycle has stalled.

The sponsor has moved on. When the person who championed the original investment leaves the role or shifts focus, and no one has picked up that ownership, the capability is at risk.

Lilydale Books is a good illustration of what happens when you resist the plateau. After building the initial back-office capability that handled booklist coordination, the easy decision would have been to stop there, the immediate pain had been resolved. But Ayesha recognised that the relief of fixing one problem shouldn’t become an excuse to stop.
Layer by layer, the business extended its capability: from internal coordination to parent-facing ordering, from a single school’s workflow to a platform that could serve thirty schools as easily as ten. Each phase built on the last. The business that exists today is fundamentally different from the one that started the journey, not because of one big project, but because nobody let it plateau.

None of these signals means a plateau is inevitable. But any of them, left unaddressed, will produce one.

The organisations that build great long-term capability are not the ones who avoid these signals, they come for everyone. They’re the ones who recognise them early, name them honestly, and take deliberate action to restart the cycle.

That’s the discipline. And it’s worth every bit of the effort it requires.

Tool: The Plateau Risk Assessment

Use this tool at your quarterly roadmap review to take an honest read of the current health of your capability build and catch plateau signals before they become a plateau.

Step 1 — Check for plateau signals. Mark each that currently applies:

• The immediate pain that drove the original investment has been resolved and urgency has faded
• The roadmap review has been cancelled, postponed, or hasn’t happened in more than three months
• User feedback has slowed, the team isn’t hearing suggestions or complaints
• Most technical work is maintenance and bug fixes rather than new development
• The project sponsor has moved on or shifted focus
• Budget for the next phase has not been confirmed

The more you’ve marked, the more urgent the action needed.

Step 2 — Check the opposite risk. Building too fast is as damaging as not building. Mark each that currently applies:

• Releases are arriving before the previous one has been fully adopted
• Users are still on a learning curve from the last release when the next one launches
• Help requests are still about basics from the current release
• Training for the current release is still in progress when development of the next starts

If you’ve marked two or more of these, consider slowing the build cycle to allow better embedding of what’s been delivered.

Step 3 — Rate the growth cycle. For each stage, rate current health from 1 (poor) to 5 (strong):

• Design — Is there active thinking happening about the next phase?
• Build — Is development progressing at a sensible pace?
• Embed — Is existing capability genuinely being adopted?
• Expand — Is the organisation extending what’s already embedded to new users or use cases?

Any stage scoring below 3 needs specific attention, it will eventually become the bottleneck for the whole cycle.

Step 4 — Define your three actions. Based on the above, what are the three most important things to address? Name them, assign an owner, and set a date.

Want to go deeper?
The online version of this tool includes a full capability growth cycle health dashboard, a guide for running a quarterly roadmap review, a department budget model template, and a facilitation guide for restarting momentum after a plateau.
Available in the members area at [website]