Organisational design and leading change

Organisational design decides who owns what: the team boundaries, the charters, the layers between leaders and the work, and the decision rights attached to each. Leading change is what happens when that design changes, through a reorganisation, a merger, an acquisition or a change of leadership. Most designs go wrong at this stage, because a structure that is right on paper is only as good as the way it is introduced. v2.0 treated ownership through structure as the executive form of delegation. v3.0 makes it a competency in its own right, within Strategy & Vision, because the organisation is how the strategy gets implemented; announce a new strategy over the old structure and the old structure remains the real strategist. A reorganisation is the most consequential and least reversible decision most engineering leaders make. Chronic delivery friction at the same boundary is usually the structure presenting its bill. And repeated reorganisations that fail to stick teach an organisation that nothing will. The examinations assess this competency from EMP-II upward. It has no team-scope form.

1. Ownership is designed, not assigned conversation by conversation. Structure, charters and decision rights determine who owns what. A reorganisation is above all a redesign of ownership, and it is judged by how clear and lasting the ownership it produces turns out to be.
2. A team boundary and a system boundary are one decision. Systems mirror the organisations that build them. Design the teams and the architecture together, or whichever one you left undesigned will reshape the other.
3. Design around cognitive load and ownership, not around the chart's tidiness. A team's scope is limited by what it can hold. A platform exists to reduce the load on the teams that ship. Spans of control depend on how mature the managers are and how stable the work is.
4. Separate structural problems from people problems, in both directions. Chronic friction at a boundary that persists after process fixes is structural. One struggling manager is a people problem. Mistaking either for the other wastes a year.
5. Change is led, or it is suffered. Leading it means explaining why, saying what changes and what does not, attending to every leader whose scope moves, and staying present through the transition. An announcement on its own leads nothing.
6. The change has to stick. Reorganisation after reorganisation, each reversed or diluted, teaches cynicism, and cynicism costs more to repair than any other property of an organisation. Design the structure you intend to keep, then keep it.

Organisational design has an old research literature and a recent practitioner one. The unit draws on both and grades each.

Conway's law practice

Melvin E. Conway, How Do Committees Invent? (1968) observed that a system's structure mirrors the communication structure of the organisation that built it. This unit uses the law as a design principle, not as a diagnostic. The boundaries drawn between teams will become boundaries in the system, so they should be drawn deliberately and at the same time. The practical form is the reverse manoeuvre, in which teams are shaped to produce the architecture you want. The law says the two structures correlate. It does not say which one to change to fix the other, and that choice is the manager's judgment.

Team topologies and cognitive load practice

Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019) provides a design vocabulary of four team types (stream-aligned, platform, enabling and complicated-subsystem) and three interaction modes, with the team's cognitive load as the constraint the design has to respect. Its value here is that it gives a vocabulary to the question of which teams should exist and how they should relate, so it no longer has to be settled by argument. It also states the platform team's purpose plainly: to reduce the load on the teams that ship product.

Sizing teams and spans practice

Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019) takes a systems view of how large a team should be and how many teams one manager can lead, and argues that structure should follow from those constraints. Span of control is no constant. It depends on how mature the managers are, how stable the work is and how much coordination each report needs. A span that works in a steady state breaks during change, which is exactly when reorganisations happen.

Structure follows strategy practice

Alfred D. Chandler Jr., Strategy and Structure: Chapters in the History of the American Industrial Enterprise (1962) drew its thesis from a historical study of large firms. Changes in strategy come first and require changes in structure, and a structure that outlives the strategy that produced it becomes the obstacle to the next one. Here it supports the principle that the organisation is the strategy's implementation, along with its corollary: a strategy announced with no change in structure has probably not been implemented.

Leading change practice

John P. Kotter, Leading Change (1996) sets out an eight-step model: urgency, a guiding coalition, a vision, communication, removing obstacles, short-term wins, consolidation, and anchoring. This unit offers it as a checklist of what reorganisations leave out, without prescribing it as a procedure. Engineering reorganisations most often skip the last two steps, which are consolidating the change so that it is not quietly reversed and anchoring it in how decisions are in practice made. The model is prescriptive and its evidence comes from cases, so it is graded as practice.

The ownership map, before and after

Before any structural change, map every system, capability and decision against its current owner. Once the design is done, draw the same map with the new owners. Anything left without an owner in the second map is where the next incident will come from. The map gets published. The chart does not.

The design questions

Any proposed structure has to answer these questions. What does each team own, and what is its cognitive load? Which boundaries in the system will it create or remove? Who will have to coordinate with whom as a result? What is each manager's span? Which decisions move, and to where? A design that cannot answer them is only a chart.

The leader-impact review

Before the announcement, the review covers every leader whose scope changes. What do they gain and what do they lose? What will they be told, and by whom? What will the organisation need from them during the transition? A reorganisation that surprises its own leaders has nobody leading it.

The change narrative

A single written page covers why the change is happening, what changes, what explicitly does not, what people can expect in the first month, and what the leadership will visibly do differently. The leader delivers it in person, repeats it, and makes it part of the first decisions taken under the new structure. The check is whether a team lead can explain the reason a month later.

Reading the boundary

When delivery friction keeps recurring at the same boundary despite process fixes, the question to ask is structural. Are these two teams that should be one, or one that should be two? Is there a gap in ownership? Is a system boundary in the wrong place? A working group is the answer only if that question has been asked and the answer was no.

This competency has no team-scope form. A first-line manager works inside a structure someone else designed, and the EMA-I outline lists SV-6 as not assessed. At organisational scope the manager deals with team boundaries and ownership within a department, such as reorganising several teams, settling a charter dispute at the level that sets charters, or defining what a platform team is for, and leads those teams through the change. At executive scope the subject is the shape of the organisation itself: aligning structure with strategy; transitions, mergers and acquisitions; the layers between leaders and the work; and the cynicism that repeated change breeds. The general pattern is in How Judgment Scales. Delegating within the structure is covered in PL-1 Delegation, ownership, and decision rights, and the managers who sit in it in PL-6 Leading through leaders.

• Designs team boundaries around ownership and cognitive load, and treats a team boundary and a system boundary as one decision. org
• Names what a platform team is for, and holds it to reducing the load on the teams that ship. org
• Leads several teams through a reorganisation, explaining why, what changes and what does not, and staying present through the transition. org
• Settles a charter dispute between teams explicitly, at the level that sets charters. org
• Recognises when a structural problem is being treated as a people problem, and the reverse. org
• Reads chronic friction at the same boundary as a structural signal, and asks the structural question before adding a working group. org
• Checks the ownership map after any change and closes the gaps before the next incident finds them. org
• Failure mode: reorganising to tidy the chart instead of to clarify ownership. org
• Failure mode: announcing the change and calling it leadership. org
• Failure mode: patching with process a boundary the structure created. org
• Failure mode: a platform team with no stated purpose, or one that has become a bottleneck for everyone it was meant to unblock. org
• Failure mode: treating a rivalry between two teams as a personality problem when their charters overlap. org
• Aligns structure, skills and architecture with a new strategy all together, instead of announcing the strategy over the old chart. exec
• Weighs reorganisation options by their effect on leaders' scopes, ownership clarity and coordination cost, and not by who is asking. exec
• Leads a merger or an acquisition as a deliberate integration (which platform consolidates, which teams merge, on what timeline), with the cost of retaining the people the company bought priced in. exec
• Designs the layers between leaders and the work so that decisions are made at the level that has the information. exec
• Makes a change stick by consolidating it, anchoring it in how decisions are made, and holding it against pressure to reverse. exec
• Repairs the cynicism left by repeated reorganisations by making the next change smaller, explained, and held. exec
• Failure mode: new strategy, old organisation chart. exec
• Failure mode: repeated reorganisations, each reversed or diluted, until nobody believes change will stick. exec
• Failure mode: "let both stacks live" after an acquisition, which is a decision in itself and usually the most expensive one. exec
• Failure mode: reorganising without weighing the impact on the leaders whose scopes change. exec
• Failure mode: confusing empowered leaders with nobody being accountable. exec

Clarity versus flexibility. Sharp ownership boundaries make accountability clear and make anything that crosses them slow. The judgment is in placing the boundaries to suit how the work in fact flows, and in designing how teams interact across them instead of pretending they will not need to.

Structure versus people. The structure that is right on paper may shrink a strong leader's scope or enlarge a weak one's. Designing only around the people freezes the structure to today's roster. Designing only around the work throws away what the people are good at. Both are weighed, and the weighing is written down.

Stability versus adaptation. An organisation that never changes its structure gets outgrown by its strategy, and one that changes every year cannot execute any strategy. Change has a real cost, paid in cynicism. So the structure is designed to be kept, and changed rarely and well.

Speed versus consent. A reorganisation decided quickly and announced without warning surprises the leaders it depends on. One negotiated with everyone it affects ends up designed by committee and satisfies nobody. The answer is to consult the leaders whose scopes move on the design questions, and to leave the decision with the person accountable for the outcome.

Integration versus disruption. After an acquisition, integrating fast destroys what was bought, and integrating slowly lets two stacks and two cultures harden. The judgment is a deliberate sequence with an explicit bill, so that neither direction is reached by drift.

A senior manager runs five teams, and two of them are locked in a rivalry that has started to damage collaboration. They block each other's changes and escalate disputes they should settle between themselves. Each team's manager, separately, has described the other team as the problem. Six months ago the senior manager's first instinct was to treat this as a people problem. They arranged a facilitated conversation between the two managers and a shared retrospective, and set an explicit expectation that the two would cooperate. It helped for a month.

Looking again, the senior manager asks the structural question they skipped the first time. The two teams' charters overlap. Both own parts of the same customer-facing capability, divided along a system boundary drawn three years ago when the capability was smaller. Every significant change touches both teams' code, every release needs both of them to coordinate, and each team is rewarded for shipping its own part regardless of the other. What looks like a clash of personalities is two teams asked to share ownership of one thing, behaving exactly as the structure rewards them for behaving.

The senior manager writes down the design options. The first is to merge the two teams into one that owns the whole capability. The second is to split them again along a different boundary that matches how the capability is changed in practice. The third is to keep the structure and impose a shared cadence, which is the working-group approach already tried. A merger would produce a team of fourteen, more than one manager can serve well. Splitting along the boundary that matches the work gives each team something it owns entirely: one team takes the capability end to end, and the other takes a separate area that has lacked a clear owner.

The senior manager consults both managers on the design questions. One of them will lose scope, so that conversation comes first. It happens in private, names what they gain as well as what they lose, and the senior manager stays present through the transition instead of disappearing after the announcement. Both teams hear the reason for the change, which is that the structure was rewarding the rivalry, along with what explicitly stays the same. The ownership map is published again, and over the following quarter the system boundary is moved to match the team boundary, because the two are one decision.

A third facilitated conversation would have missed the point. The people were behaving as the design rewarded them for behaving, so the design was what had to change.

• PL-1 Delegation, ownership, and decision rights: ownership through structure as the executive form of delegation, and the hub-and-spoke bottleneck.
• PL-6 Leading through leaders: the managers who sit in the structure, and span of control as a design constraint.
• SV-1 Engineering strategy: the strategy the organisation implements, since structure follows strategy.
• DE-4 Managing scope, risk, and dependencies across workstreams: chronic friction at a boundary as the delivery symptom of a structural cause.
• TJ-1 Evaluating architectural decisions and their organisational consequences: architecture and organisation as two views of one decision.
• CC-4 Motivation, recognition, and sustainable pace: leading distributed teams through change, and motivation and pace during a transition.

1. Why is a team boundary and a system boundary one decision? org
   Answer

   Because systems mirror the organisations that build them. The boundaries drawn between teams become the boundaries in the system, so both are drawn together and on purpose. Otherwise the one left undesigned reshapes the other.
2. Two teams are in a rivalry that is hurting collaboration. What question is asked before the facilitated conversation? org
   Answer

   Whether the structure is rewarding the rivalry. Do their charters overlap? Do they share ownership of one thing? Does every change need both of them? If so, the problem is one of design, and the people are behaving as the design rewards.
3. What is a platform team for, and what is the sign that it has stopped doing it? org
   Answer

   Reducing the cognitive load on the teams that ship product. The sign that it has failed is that it has become the bottleneck for everyone it was meant to unblock.
4. What do reorganisations most often leave out, and what does leaving it out cost? org
   Answer

   Leading the change. That means explaining why, saying what does not change, attending to each leader whose scope moves, staying present through the transition, and consolidating the change so it sticks. Without it the result is a chart nobody believes and a change that is quietly reversed.
5. Why is announcing a new strategy over the old organisation chart a failure of implementation? exec
   Answer

   Because structure follows strategy. The organisation is how the strategy is implemented, and a structure left unchanged becomes the obstacle to a strategy it was not built for.
6. After an acquisition brings a redundant engineering organisation with its own stack, what is "let both stacks live"? exec
   Answer

   A decision, and usually the most expensive one. Integration is led as an explicit strategy with a bill: which platform consolidates, which teams merge, on what timeline, with the cost of retaining the people the company bought priced in.
7. Repeated reorganisations have left an organisation cynical that change will stick. What repairs it? exec
   Answer

   A next change that is smaller, explained, consolidated, and held against the pressure to reverse it. Only a change that sticks repairs cynicism, and cynicism is the most expensive property of an organisation to rebuild.
8. How are two reorganisation options weighed? exec
   Answer

   By their effect on leaders' scopes, by how clear and lasting the ownership each produces is, and by the coordination cost each creates. Who is asking for which option does not come into it.

• Melvin E. Conway, How Do Committees Invent? (1968): systems mirror the organisations that build them.
• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019): team types, interaction modes, cognitive load.
• Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019): sizing teams and spans; structure from constraints.
• Alfred D. Chandler Jr., Strategy and Structure: Chapters in the History of the American Industrial Enterprise (1962): structure follows strategy.
• John P. Kotter, Leading Change (1996): the steps of leading change, and the ones most often skipped.