What else will change?
Designing for flow-on effects before you restructure

The purpose of this piece is to describe a way of assessing the flow-on effects of a change before it is approved, drawn from a discipline in systems engineering called interface control and applied here to an organisation's eight capability domains. I call the principle Capability Interaction Design, and the question it asks is a modest one that is rarely asked early enough: if this capability is altered, what else will change, and where will the effects land?

It is fair to concede that no organisation can predict every consequence of a change, and that some effects only emerge once people begin working in the new arrangement. Planning more thoroughly will not remove that uncertainty, and methods that favour small experiments and fast feedback are a reasonable response to it. This piece does not argue against them. It argues that a large share of the surprises that cost most are not unpredictable at all, because they occur at the boundary between two domains and could have been anticipated by asking the people on either side of it.

Where the idea comes from

In systems engineering, a system is made of components that interact through defined interfaces, and interface control is the practice of defining those interfaces and managing changes to them, so that when one component is altered the effect on every component connected to it is assessed first. The reasoning is practical, since problems in complex systems are commonly found at the interfaces between components and not inside them. Organisations are not machines, but their domains are connected in comparable ways, and a change to one is felt in the others whether or not the plan anticipated it. I describe the method and make no claim to an engineering title, and the three principles it belongs to are set out in The Living Organisation.

What flow-on looks like

The table sets out a few common changes, the domain each one primarily alters, and the domains that in my experience are most often found to have moved late.

Change made	Primary domain	Often discovered late
A restructure	Structure	Governance, where decision rights no longer match the new reporting lines; Data, where ownership of measures was never reassigned; Information Flow
A new system	Technology	Process, where workarounds appear; Data, where definitions differ; People, where skills and capacity were assumed
A simplified process	Process	Governance, where a control point was removed; Information Flow, where a hand-off was carrying information nobody had listed
A new strategic priority	Purpose and Objectives	Data, where measures still reflect the old priority; Structure, where resourcing has not moved
A new reporting regime	Information Flow	People, who now spend time producing it; Data, whose quality is exposed; Governance, whose forum now sees something different

None of these effects is exotic, and each is the kind of thing that, once discovered, somebody will say was obvious. The reason it was not seen earlier is typically that the change was designed by the people in the domain it primarily affected, who understood their own domain well and had no particular reason to know the assumptions held in the others.

An interaction pass before approval

What I suggest is a short interaction pass, run before a change is approved and with someone representing each of the other domains in the room.

The delivery system and the operating system

This matters more where change is delivered through a program, since the program is building one thing while the organisation is running another, and the two share the same people. A program can design a change that is internally consistent and still incompatible with the operating system it will land in. For that reason I would treat the boundary between the delivery system and the operating system as an interface in its own right, with a named owner, and I would expect it to be the interface most often found without one. The distinction is described further in What an operating system is.

Two views on how much to plan in advance

There are two reasonable positions on how much of this to do before the change goes live. The first, which draws on plan-driven methods, holds that the cost of correcting a flow-on effect rises sharply once the change is live, so the interaction pass should be thorough and early. The second, which draws on adaptive and agile practice, holds that effects in a complex system cannot be fully foreseen, so the better response is small changes that are cheap to reverse and fast feedback on what moves. I describe myself as methodology agnostic and have seen each approach work and fail, and my own view, for what it is worth, is that they are complementary, in that the interaction pass reduces the blind spots that can be found by asking, while a monitored and reversible rollout deals with those that cannot.

If most of the expensive surprises in a change occur at boundaries that nobody was asked to look at, and the people who could have named them were in the organisation the whole time, would it not be more economical to ask them before the change is approved, and to give each boundary an owner, than to discover the effects one at a time after the change has gone live?