Organisational design and leading change

Organisational design is the decision of who owns what: team boundaries, charters, the layers between leaders and the work, and the decision rights that go with them. Leading change is what happens when that design changes — a reorganisation, a merger, an acquisition, a transition of leadership — and it is the part most designs get wrong, 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 of its own, in Strategy & Vision, because the organisation is the strategy's implementation: a new strategy announced over the old structure leaves the old structure as the real strategist. It matters because a reorganisation is the most consequential and least reversible decision most engineering leaders make, because chronic delivery friction at the same boundary is usually structure presenting a bill, and because repeated reorganisations that do not stick teach an organisation that nothing will. The examinations assess it from EMP-II upward; there is 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 the durable clarity of ownership it produces.
2. A team boundary and a system boundary are one decision. Systems mirror the organisations that build them. Design teams and architecture together, or the one you did not design will reshape the other.
3. Design around cognitive load and ownership, not around the chart's tidiness. A team's scope is bounded by what it can hold; a platform exists to reduce the load on the teams that ship; spans of control follow the maturity of the managers and the stability of the work.
4. Separate structural problems from people problems, in both directions. Chronic friction at a boundary that survives process fixes is structural. A single struggling manager is not. Treating either as the other wastes a year.
5. Change is led, or it is suffered. The why, what changes and what does not, the effect on every leader whose scope moves, and presence through the transition. Announcement is not leadership.
6. The change has to stick. Repeated reorganisations that are reversed or diluted teach cynicism, and cynicism is the most expensive organisational property to repair. Design for the structure you will hold, then hold 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

The observation in Melvin E. Conway, How Do Committees Invent? (1968) that a system's structure mirrors the communication structure of the organisation that built it. In this unit it is the design principle rather than the diagnostic: the boundaries drawn between teams will become the boundaries in the system, so they are drawn on purpose and together. The reverse manoeuvre — shaping teams to produce the architecture wanted — is the practical form. Its limit is that it says the structures correlate, not which to change to fix the other; that is the manager's judgment.

Team topologies and cognitive load practice

The design vocabulary in Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019): four team types — stream-aligned, platform, enabling, complicated-subsystem — and three interaction modes, with a team's cognitive load as the constraint the design serves. For this unit its value is that it makes "which teams should exist and how should they relate" a question with a vocabulary rather than an argument, and that it names the platform team's purpose as reducing the load on the teams that ship product.

Sizing teams and spans practice

The systems view in Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019) of how large a team should be, how many teams a manager can lead, and the argument that structure should follow from those constraints. Span of control is a function of the managers' maturity, the stability of the work and the coordination each report requires, not a constant; a span that works in steady state fails during change, which is exactly when reorganisations happen.

Structure follows strategy practice

The thesis of Alfred D. Chandler Jr., Strategy and Structure: Chapters in the History of the American Industrial Enterprise (1962), from a historical study of large firms, that changes in strategy precede and require changes in structure, and that structures which outlive the strategy that produced them become the obstacle to the next one. Its use here is the principle that the organisation is the strategy's implementation, and its corollary that a strategy announced without a structural change has probably not been implemented.

Leading change practice

The eight-step model in John P. Kotter, Leading Change (1996) — urgency, a guiding coalition, a vision, communication, removing obstacles, short-term wins, consolidation, anchoring — offered here not as a procedure to follow but as a checklist of what reorganisations leave out. The steps most often skipped in engineering reorganisations are the last two: consolidating the change so that it is not quietly reversed, and anchoring it in how decisions are actually made. The model is prescriptive and its evidence is case-based; it is graded as practice.

The ownership map, before and after

Before any structural change, a map of every system, capability and decision and who owns it now; after the design, the same map with the new owners. Anything that has no owner in the second map is where the next incident lives. The map is what is published, not the chart.

The design questions

For any proposed structure: what does each team own, what is its cognitive load, which boundaries in the system will this create or remove, who has to coordinate with whom because of it, what is each manager's span, and which decisions move to where. A design that cannot answer these is a chart.

The leader-impact review

For every leader whose scope changes, before the announcement: what they gain, what they lose, what they will be told and by whom, and what the organisation needs from them in the transition. Reorganisations that surprise their own leaders are led by nobody.

The change narrative

One written page: why the change, what changes, what explicitly does not, what people can expect in the first month, and what the leadership will visibly do differently. Delivered by the leader, in person, repeated, and embedded in the first decisions made under the new structure. The check is whether a team lead can explain the why a month later.

Reading the boundary

When delivery friction recurs at the same boundary despite process fixes, the question asked is structural: is this two teams that should be one, one that should be two, an ownership gap, or a system boundary in the wrong place. A working group is the answer only if the structural question has been asked and answered no.

There is no team-scope form of this competency; a first-line manager works inside a structure they did not design, and the EMA-I outline lists SV-6 as not assessed. At organisational scope the object is team boundaries and ownership within a department — a reorganisation of several teams, a charter dispute settled at the level that sets charters, a platform team's purpose — and leading those teams through the change. At executive scope the object is the shape of the organisation itself: structure aligned 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 PL-1 Delegation, ownership, and decision rights, and the managers who sit in it are PL-6 Leading through leaders.

• Designs team boundaries around ownership and cognitive load, and sees 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: the why, what changes and what does not, presence through the transition. org
• Settles a charter dispute between teams at the level that sets charters, explicitly. 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 rather than to clarify ownership. org
• Failure mode — announcing the change and calling it leadership. org
• Failure mode — process-patching 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 together, rather than announcing the strategy over the old chart. exec
• Weighs reorganisation options by their effect on leaders' scopes, ownership clarity and coordination cost, 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 retention of the people actually bought priced in. exec
• Designs the layers between leaders and the work so that decisions are made at the level with the information. exec
• Makes a change stick: consolidates it, anchors it in how decisions are made, and holds it against the pressure to reverse. exec
• Repairs cynicism from repeated reorganisations by making the next change smaller, explained, and held. exec
• Failure mode — new strategy, old organisation chart. exec
• Failure mode — repeated reorganisations that are reversed or diluted, until nobody believes change will stick. exec
• Failure mode — "let both stacks live" after an acquisition, which is a decision 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 where the boundaries fall relative to the work that actually flows, and in designing the interaction modes across them rather than pretending there will be none.

Structure versus people. The right structure on paper may put a strong leader in a smaller scope or a weak one in a larger. Designing purely around the people freezes the structure to today's roster; designing purely around the work discards what the people are actually good at. Both are weighed, and the weighing is written down.

Stability versus adaptation. An organisation that never changes its structure is outgrown by its strategy; one that changes every year cannot execute any strategy. The cost of change is real and paid in cynicism, so the structure is designed to be held, and changed rarely and well.

Speed versus consent. A reorganisation decided quickly and announced surprises the leaders it needs; one negotiated with everyone it affects is designed by committee and satisfies nobody. The resolution is consultation on the design questions with the leaders whose scopes move, and decision by 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 calcify. The judgment is a deliberate sequence with a bill, made explicit, rather than drift in either direction.

A senior manager with five teams has two of them in a rivalry that has begun to hurt collaboration. The teams block each other's changes, escalate disputes that should be settled between them, and their managers have each, separately, described the other team as the problem. The senior manager's first instinct, six months ago, was to treat it as a people problem: a facilitated conversation between the two managers, a shared retrospective, and an explicit expectation that the two would cooperate. It helped for a month.

Looking again, the senior manager asks the structural question they had skipped. The two teams' charters overlap: both own pieces of the same customer-facing capability, split along a system boundary that was drawn three years ago when the capability was smaller. Every significant change touches both teams' code, every release requires both to coordinate, and each team's incentives reward it for its own piece shipping regardless of the other. The rivalry is not a personality problem. It is two teams who have been asked to share ownership of one thing, and who are behaving exactly as the structure rewards.

The design options are written down: merge the two teams into one that owns the whole capability; re-split them along a different boundary that matches how the capability is actually changed; or leave the structure and impose a shared cadence. The third is the working group the senior manager already tried. Merging would create a team of fourteen, beyond what one manager can serve well. Re-splitting along the boundary that matches the work — one team owning the capability end to end, the other taking a genuinely separate area that has been under-owned — gives each team something it owns whole.

The senior manager consults both managers on the design questions, and one of them loses scope. That conversation is had first, privately, with what they gain named as well as what they lose, and with the senior manager present through the transition rather than absent after the announcement. The change is explained to both teams with the why — the structure was rewarding the rivalry — and with what explicitly does not change. The ownership map is republished; the system boundary is moved to match the team boundary over the following quarter, because the two are one decision.

What the senior manager does not do is run a third facilitated conversation. The people were behaving as the design rewarded, and the design was the thing to change.

• PL-1 Delegation, ownership, and decision rights — ownership through structure as the executive form of delegation; 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; structure follows strategy.
• DE-4 Managing scope, risk, and dependencies across workstreams — chronic boundary friction 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; 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 they are drawn together and on purpose, or the one not designed 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 require both. If so, it is a design problem 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 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: the why, what does not change, the effect on each leader whose scope moves, presence through the transition, and consolidating it so it sticks. Leaving it out produces a chart that 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 the strategy's implementation, and a structure left unchanged becomes the obstacle to the 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 retention of the people actually 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. Cynicism is repaired only by a change that sticks, and it is the most expensive organisational property to rebuild.
8. How are two reorganisation options weighed? exec
   Answer

   By their effect on leaders' scopes, the durable clarity of ownership each produces, and the coordination cost each creates — not by who is asking for which.

• 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.