Steering at two speeds

A white paper by Stijn Koopman (Jester Strategy)

In knowledge-intensive firms, the same people carry both the daily operation and the renewal. That makes the standard way of steering unsuitable. This white paper shows why, and what a governance model looks like that lets run and change exist side by side.

The project that has been in motion for a year, and still is not moving forward

On an average Monday it is somewhere on the agenda in every directors' room. A change project that started ambitiously a year ago (a new client segment, a revised service offering, a platform renewal) and which despite good intentions just does not pick up the acceleration that was foreseen.

The steering group meets faithfully. The project manager reports. People nod. And still the thing does not move.

The reflex is familiar: there has to be more focus, more governance, tighter planning. But anyone who looks a bit longer sees that the problem rarely sits in the plans. The problem sits in the people who have to carry it.

The same senior consultant who has to lead the pilot project has four client engagements to deliver this week. The same solution architect who has to work out the new service is fully booked on billable hours. The same team lead who has to embed the change in their department has a sales target to meet.

It is not a lack of ability or motivation. It is a governance problem. And in our experience it is the governance problem that gets in the way of knowledge-intensive firms most.

Two processes, one group of people

A production company can separate run and change relatively cleanly. The factory runs, and those working on the new product line sit elsewhere in the building. A bank can set up an innovation lab that is separate from the regular business. A fast-moving consumer goods company can set up an R&D department with its own people, its own budgets, its own rhythm.

In knowledge-intensive firms that does not work. Here the organisation is the sum of people who turn knowledge into value: for clients in engagements (the run) and for the own organisation in renewal (the change). And the painful truth is: those are largely the same people.

That is not an organisational shortcoming. That is the business model.

The senior consultant who can best design the new proposition platform is exactly the senior consultant who realises the highest rates on client engagements. The engineer who has the most authority to define a new technical standard is exactly the engineer most in demand on projects. The architect who has to work out the new design philosophy is exactly the architect whom clients most like to work with.

Whoever wants to source the change from people who are not on the critical path of the run gets a change that does not matter. Whoever tries to source the change from the same people gets a change that does not move forward.

That is the dilemma. And solving it begins with acknowledging that run and change are fundamentally different processes, even when they are carried by the same people.

How different are run and change really?

In practice, run and change are regularly thrown together. That is understandable, because they are both "things that need to be done". But anyone who tries to manage both from the same steering logic gets stuck. A few contrasts help.

Run is aimed at predictability; change is aimed at learning. In the run you know what you are doing, and you do it as efficiently and reliably as possible. A deviation from the plan is a problem that has to be solved. In change you do not yet fully know what you are doing, and that is precisely the reason it is a change project. A deviation from the original plan is then often an insight that has to be embraced. Whoever steers change on variance against a plan smothers the learning process. Whoever steers run on learning instead of executing gets clients waiting on their delivery.

Run is incremental; change is in leaps. The daily operation becomes a little better every quarter: costs a percent lower, lead time a day shorter, customer satisfaction half a point higher. Change projects work differently. There little visibly happens for months, and then suddenly a breakthrough. Whoever imposes the same progress rhythm on both processes forces change into a pseudo-progress that helps no one.

Run is department-bound; change crosses departments. A well-run organisation has clear responsibilities per department, with clear KPIs. But the truly strategic change projects (a new client segment, a revised service offering, a new market) almost by definition cut across several departments at the same time. Whoever tries to lodge change with one department gets a change that gets stuck in the line as soon as it has to cross the departmental boundary. Whoever forces change into a matrix gets endless consultation.

Run has a fixed rhythm; change knows phases. The month-end closing comes every month. The annual planning comes every year. Run lives on cyclical rhythm. Change lives on phases that each have their own pace and their own issues: exploration, design, pilot, scaling, embedding. Whoever tries to capture change in monthly steering group meetings forces the phase into a calendar it does not fit.

These are not academic distinctions. They are the reasons why change projects in knowledge-intensive firms so often get bogged down, not because they were poorly set up, but because they are steered as if they were run work.

Three patterns we see

In organisations that do not explicitly steer on this, we almost always see the same three patterns emerge.

The first pattern is run displacing change. Client engagements have deadlines. Change projects have end dates that are "internal". With every peak in workload, change shifts. First a week, then a month, then a quarter.

No one says explicitly that the change is less important. On the contrary, in every directors' meeting its importance is emphasised. But in the quiet choices professionals make every day, the client wins. At individual level that is understandable. At organisational level it is fatal.

The second pattern is change isolating itself. To escape the first pattern, change is housed in a separate team. An innovation team, a transformation programme, a strategy office. That structure solves the first problem, but creates a new one: what the team comes up with does not reach the line.

The pilot becomes magnificent, the concept becomes convincing, but on handover to the departments the innovation dies. Not because the departments do not want it, but because they were not involved when it was designed, and because the design does not take account of the reality of their run.

The third pattern is wanting to steer everything at the same time. The directors try to discuss run and change in the same review meeting, in the same report, with the same KPIs. The agenda becomes overcrowded. Conversations become shallow.

Run topics get too little depth because the change discussions take longer than planned; change topics get too little room because the run issues simply feel more urgent. The result is steering that really serves neither one process nor the other.

None of these three patterns is solved by working harder or demanding more focus. They are solved by recognising run and change as different processes, with different steering logics, and then connecting them explicitly in one governance model.

What a governance model does

A governance model is, in our definition, the structured framework with which an organisation gives direction, makes choices and coordinates activities to realise its objectives. In a knowledge-intensive firm, that model has to do three things at once.

It has to keep run and change conceptually separate. Everyone in the organisation has to know: this belongs to the run, this belongs to the change. They are different routines, different forms of consultation, different information. A good governance model therefore has a decision framework: when is something an improvement that belongs in a team's OGSM, and when is something a change project that belongs in the "change engine"? Without that decision framework everything goes on the same pile, and the run wins.

It has to let the same people work at two speeds. The architect who works on a client engagement on Monday and a change project on Tuesday should not switch between two organisations, because that is exhausting. They have to switch between two modes within the same organisation. That calls for explicit capacity arrangements (what percentage of whose time is reserved for change?), a calendar that accommodates both rhythms (client deliveries and sprint reviews), and honest conversations about priority when it really chafes.

It has to have a connecting cycle in which run and change feed each other. The results of change have to land in the run at fixed moments, not as standalone projects thrown over the wall, but as new ways of working that are taken up in the OGSMs of departments. And the signals from the run have to feed the change agenda at fixed moments: what we learn about clients, markets and our own shortcomings forms the input for the next round of change projects.

That connecting cycle is not an additional body; it is a design of the annual routine. In practice it means: a planning and control cycle that evaluates not only budget and operational results, but also the validity of the strategy itself.

At fixed moments in the year there is looking back (what have we learned from run and change?) and looking forward (what does that mean for our priorities?). The outcome of that lands in a framework letter that feeds both the departmental plans for the coming year and the change-engine agenda. In this way one rhythm emerges in which two speeds have their place.

Three design choices when building such a model

Anyone setting out to design such a governance model faces a number of choices. Three of them are, in our experience, decisive.

The first is how you organise the change. Not whether you organise it, that you must, but in what form. The common choice is a change engine: a light structure in which change projects are prioritised, multidisciplinary staffed, and worked out in iterations (often agile, often in sprints).

It is crucial that this structure remains light. A change engine should not become a second organisation. It is a mechanism that temporarily draws capacity from the line to design, test and, once it is mature, hand back to the line. Whoever sets this up too heavily creates the second pattern from above: change that isolates itself.

The second is how you formulate the decision framework. What is run, what is change? In practice we see that a lot of unclarity exists on this. A process optimisation of an existing process is run; a fundamental revision of that same process is change. A product improvement within the existing proposition is run; a new proposition for a new segment is change. The difference lies in two criteria: complexity (can one department pick it up on its own?) and novelty (do we know how to do it?). Whoever makes this decision framework explicit and agrees it across the organisation prevents endless discussions about where something belongs.

The third choice is how you organise the planning and control cycle. In many knowledge-intensive firms this cycle is mainly financial: budget, forecast, progress reporting. A governance model that wants to connect run and change calls for a richer cycle.

At fixed moments (for instance once per quarter) not only the figures are looked at, but also the progress of change projects, learning insights, and what that means for the strategy. Once per year (often in the summer) there is more thorough looking back and forward, and the framework letter is drawn up that feeds both the departmental plans and the change-engine agenda for the coming year. This is not extra work; it is the existing P&C work, more cleverly organised.

The handbook principle

A governance model that exists only on paper as a directors' concept dies in the first hectic month. What works in practice is what we internally call the handbook: a concrete working instruction setting out how the governance model runs in practice. Which meetings are there? Who sits on them? What is their rhythm? Which information is discussed where? What is the annual routine? Which decisions are made where?

That sounds bureaucratic, and that is precisely the pitfall. A good handbook is not a rulebook but a shared reference point. It is concise, it describes what actually happens, and it helps new employees (and experienced employees) know where they stand. Its most important effect is not the content, but that its existence compels explicitness about choices that would otherwise remain implicit.

Who in your organisation could give a clear answer this week to the question: how do we decide which change projects we start? How do we know when a change project is ready to land in the line? How does information from change projects find its way into the annual planning?

If those answers are not clear (and in our experience they rarely are), then that is the signal that the governance model has remained implicit, and the patterns from above are doing their work.

Three questions for the boardroom

For anyone who feels that the governance problem described above is at play in their own organisation, there are three questions we advise directors to ask themselves.

One: in our steering, are run and change really two different processes, or do we treat them as variations of the same thing? Look at the agendas of director and management team meetings. Are change topics discussed in the same slot as operational topics? Do they get the same format, the same rhythm, the same steering information? If the answer is yes, that is rarely consciously chosen, and rarely effective.

Two: do we know of our key people what part of their time is for change, and what part for run? Not as a wish, but as an agreement to which they commit and on which the organisation holds them. In most knowledge-intensive firms this is implicit. The consequence is that the run pressure eats up the change time, because the client has a name and a deadline, and the change project only has a deadline.

Three: does our planning and control cycle have a mechanism to let results of change projects land in the annual plans of departments, and to let signals from the operation feed the change agenda? Or do the strategic conversation and the operational conversation live in separate worlds that only meet at the annual strategy day?

Anyone who has answered these three questions sharply has the basis for a governance model that connects run and change not only organisationally but also in daily practice. And that is, in our conviction, what makes knowledge-intensive firms ultimately different: not that the people are different, but that they have to be able to work in two modes at the same time, and that they deserve an organisation and a steering around them that recognises this.

About the author

Stijn Koopman is a strategist at Jester Strategy. He works for knowledge-intensive firms on issues at the intersection of strategy and steering.

This white paper has been written on the basis of practical experience with designing and implementing governance models at knowledge-intensive organisations. The insights described are observations of the author, based on the practice of Jester Strategy in this sector.