Kubair Shirazee

Transformation delivery · Enterprise agility · AI-enabled decision systems



7 min read
,

Nail it before you scale it

The design philosophy underneath this entire series.

Six posts in this series have described specific pieces of scaffolding: a protocol for challenge, shared evidence, a conflict wall, criteria built from experience, an ownership map, a follow-up rhythm. Each one is a practical structure that changes how a team decides.

This final post is about the posture underneath all of them. Why they were built this way. Why the engagement was designed as a contained intervention rather than a transformation programme. And why that distinction matters more than anything in the individual posts.

The principle is five words: nail it before you scale it.

Why transformation programmes fail

I’ve spent enough years inside transformation programmes to say this plainly: most of them fail. Not because the thinking is wrong or the people aren’t committed. Because they scale before they prove.

A typical programme looks like this. A leadership team agrees on a new way of working. A rollout plan covers the whole organisation. Training is delivered broadly. Governance is redesigned. New tools are introduced. The programme runs for twelve to eighteen months. At the end, engagement scores have improved, some language has changed, and the underlying decision behaviour is largely the same.

The J-curve is the polite name for this. Performance dips during the transition, then supposedly recovers. In practice, many programmes never clear the dip. They plateau in the middle, declare success based on adoption metrics, and move on. The teams that were supposed to change are left holding a framework they were trained on but never owned.

This happens because scale creates dependency. A large programme needs external consultants, programme managers, change teams, and governance structures to sustain itself. The moment that support is withdrawn, the organisation reverts. Not because people resist change. Because the system was never redesigned to make the new behaviour rational without the scaffolding the programme provided.

What a contained intervention looks like

The alternative starts small and earns the right to grow.

One day. Real teams. Real work. A vertical slice of the organisation from the people who set priorities to the people who deliver them, in the same room at the same time. Not a training day. A working day where the room builds the artefacts it will use starting the following week.

The day is followed by a short coaching cadence: four sessions across four weeks where the decisions made in the room meet real operating conditions. Internal enablers are built from the first session, not trained after the programme ends. The engagement has a defined start, a defined end, and no automatic extension.

That is the entire structure. No programme office. No twelve-month roadmap. No transformation governance board. The intervention is designed to deliver value independently, in weeks rather than quarters, and to leave behind capability rather than dependency.

Five design principles

I went back and forth on whether to name these explicitly or let them sit inside the series. They deserve to be named.

Start with decision clarity, not process change. Most interventions begin by redesigning how work flows. This one begins by redesigning how decisions get made. Prioritisation criteria, ownership maps, entry criteria: these are decision artefacts, not process artefacts. Fix the decisions and the process follows. Fix the process first and the decisions stay broken underneath.

Build internal capability from day one. The exit strategy is not a handover document. It is people inside the organisation who can run the conversations themselves, because they were in the room when the conversations happened. Change champions self-select by volunteering, not by being assigned. That self-selection is the strongest predictor of whether the capability transfers.

Test in real working conditions. Nothing in this series was designed in theory. The criteria were built from a live trade-off exercise using real initiatives. The conflict wall was populated with real examples. The coaching sessions worked through real cases the team was facing that week. The artefacts are grounded because the work they were built from was grounded.

Use contained phases to reduce risk. The engagement was deliberately scoped as a single phase that could proceed independently. No dependency on a second phase. No assumption of scale. If it works, there is evidence to support a decision to expand. If it doesn’t, the organisation has lost weeks, not quarters, and has learned something specific about where the system holds and where it doesn’t.

Generate evidence before any scale decision. This is the principle that separates a contained intervention from a pilot. A pilot is a smaller version of something you’ve already decided to do. A contained intervention is a test of whether the thing works at all. The evidence comes from real operating conditions, not from a training evaluation. Did the criteria hold under pressure? Did the ownership map clarify decisions? Did the follow-up rhythm prevent decay? Those are the questions that earn the right to scale.

Design principle card showing nail it before you scale it approach to prioritisation interventions

The translation framework

Underneath every piece of scaffolding in this series is a sequence I’ve used for fifteen years, across enterprise transformation and community change work. Four questions, in a specific order: What are we trying to change? Why does it matter? What does good look like when it’s working? How do we get there?

The order matters. Most teams jump from What straight to How. They identify a problem and start building a solution before they’ve agreed on why it matters or what success looks like. That jump is where most interventions lose coherence.

I call it the What-Why-How-Done Canvas. Except the sequence is deliberately WHAT, WHY, DONE, HOW. You define what success looks like before you design how to get there. That reversal is what stops teams from building solutions to problems they haven’t fully understood.

Every exercise in this series follows that sequence. The survey gallery answers WHAT (what is actually happening). The conflict wall answers WHY (why prioritisation breaks where it does). The criteria and ownership map answer DONE (what good prioritisation looks like when it’s working). The trade-off exercise and follow-up rhythm answer HOW (how to get there and how to hold it).

The canvas is open source, freely available, and has been tested in contexts ranging from enterprise boardrooms to community projects in Karachi, Cairo, and Arusha. If the series has been useful, the canvas is the structure underneath it.

What this series was for

Seven posts. One engagement. One argument: prioritisation is not a people problem. It is a design problem. And design problems have design solutions.

The scaffolding described in this series is specific. A protocol for purposeful challenge. Shared evidence that gives the room a common picture. A conflict wall that makes the hidden rules visible. Criteria built from experience rather than theory. An ownership map that answers five questions with names rather than roles. A follow-up rhythm that holds decisions in place while the new behaviour becomes normal.

None of it requires a transformation programme. None of it requires a new tool. None of it requires anyone to become braver than they were last Tuesday.

It requires a room, a wall, real work, and the willingness to see what’s already there.

If you’ve read all seven posts and found something worth testing, I’d welcome hearing what you try. Not what worked. What you learned.


This is the seventh and final post in the prioritisation series by Kubair Shirazee, architect of the Decision System Tune-Up. Previously: Prioritisation is a scaffolding problem, What your team knows about prioritisation, The wall where the hidden rules live, The criterion you’re already using, Who can say yes, and Scaffolding is never an event.


More writing