--- name: "org_design_options" description: "Generate organisation design options before a restructure and test each one against strategy fit, customer segmentation, capacity, spans and layers, role clarity, and transition risk, with a runnable scoring model, a structural checker, and a worked comparison of three designs for the same 48 person team. Use when asked to design restructure options, compare org structures, build an operating model options pack, or judge whether a proposed reorganisation is ready to recommend." --- # Org Design Options ## Purpose Build an options pack a decision maker can actually choose from. This skill generates two to four real design options for the same team, scores every option on the same six criteria with the same weights, checks the structure of each option with a tool, runs a sensitivity check when the result is close, and ends with a recommendation that carries its conditions in writing. It also sets out what staff need to hear and when, because an options pack that ignores the announcement is only half finished. One preferred chart with no alternatives, no scoring evidence, and no transition plan is a preference, not an options pack. ## Workflow 1. Fix the decision before drawing any charts. Write down the team in scope and its headcount, the problem the restructure exists to solve in one sentence, the strategic outcome it serves, the decision maker, and the date the decision is needed. McKinsey's operating model guidance starts in the same place: find the root causes of the gap between strategic objectives and real performance before redesigning. If the problem sentence could describe any team in any year, it is too vague to design against, so sharpen it with demand, customer, or service data until it names this team and this problem. 2. Record the fixed facts every option must live with. Demand by work type and by customer segment, current headcount and roles with named owners, current layers and reporting lines, sites and working patterns, budget limits, and any duties or agreements that constrain the move. Options built on different facts cannot be compared, so one fact base serves all options. 3. Generate the options from grouping bases, not from personalities. Use `references/grouping-and-tradeoffs.md` and build options that differ in how work is grouped: by function, by customer segment, by product or service, by geography, by process, or a matrix or hybrid of two bases. Include the current design with targeted fixes as one option, so doing little is priced honestly against doing more. Aim for three options. Two options usually collapse into change against no change, and more than four cannot be scored with real evidence in one pack. Never build an option around a named person. If an option only works with one person in one role, say so as a risk in that option. 4. Describe each option in the same shape. For every option write: the grouping basis, the units it creates, headcount and manager count per unit, layers from top to front line, where each kind of work lives, who owns each outcome, what processes and rewards change to match the new grouping, and who moves, in counts by kind of move (new manager, changed role, changed location). Galbraith's Star Model is the check here: a grouping change with no matching change in processes, rewards, and people practices will be pulled back to the old design by the parts that stayed the same. 5. Run the structural check on every option with the bundled tool, on a CSV shaped like `references/example-structure.csv` (columns: option, headcount, managers, layers, demand_hours, capacity_hours, roles_total, roles_with_named_owner, duplicated_accountabilities). ```bash python3 scripts/org_design.py structure --input references/example-structure.csv ``` Read the output per option: estimated average span, layers, manager share of headcount, capacity utilisation, and role ownership share, plus flags the tool raises. Treat every threshold in the tool as a planning heuristic for this method, not as a published standard. No verified universal ideal span exists, so judge spans against the work using the span factors in `references/grouping-and-tradeoffs.md`, and test each layer against whether it helps planning, coordinating, controlling, or allocating resources. The tool exits with code 1 when flags are present, so a flagged option cannot be presented as clean. Each flag needs a fix, a mitigation, or a written acceptance in the pack. 6. Score every option on the six criteria with the bundled tool, on a CSV shaped like `references/example-scores.csv`. The criteria and default weights are strategy fit 25, customer segmentation 20, capacity 15, spans and layers 15, role clarity 15, and transition ease 10, where transition ease scores 5 for low risk and 1 for high risk. Use the anchored scale and evidence rules in `references/criteria-and-evidence.md`, and agree the weights with the decision maker before scoring. ```bash python3 scripts/org_design.py score --input references/example-scores.csv ``` Apply the gates: an option scoring 2 or below on strategy fit, capacity, or role clarity fails a gate and must not be recommended on its total. The tool marks gate fails and exits with code 1. Either redesign that option until the gated score rises, or drop it and record why. 7. Run a sensitivity check whenever the top two options finish within 5 points, which the tool flags as a close call. Move weight toward the criterion the decision maker cares most about if their stated priorities change, using `--set-weight`, and report both rankings. ```bash python3 scripts/org_design.py score --input references/example-scores.csv --set-weight strategy_fit=15 --set-weight transition_ease=20 ``` If the ranking flips or ties under a plausible weighting, the pack must say so and must name what actually decides it, such as a funded mitigation or a dated trigger. The full worked example is in `references/worked-comparison.md`: three designs for one 48 person customer operations team scoring 79.0, 75.0, and 66.0 under base weights, then tying at 73.0 at the top under risk averse weights, with the recommendation written as Segment Pods on two named conditions and the Hybrid as the fallback if either condition is refused. 8. Write the transition risk register and the communication sequence for the recommended option, using `references/transition-and-communication.md`. Check consultation and notification duties for the jurisdiction and agreements that apply before anything is announced, and get local advice where roles may be removed or terms changed. The reference gives the UK collective consultation threshold from Acas as a labelled example of one jurisdiction. It is not a rule for other countries. The communication sequence names what staff hear at each step: why change is being considered, the options and the criteria, what is not changing, when consultation happens and what it can change, when the decision lands, what it means per group, and what gets checked at 30, 60, and 90 days. 9. Close the pack with the decision record. State the recommendation, its conditions, the fallback if a condition is refused, the scores and structure results behind it, the risks accepted, and the measures that will show within one quarter whether the chosen design is working, with the result that would trigger a fix. A recommendation with no conditions and no failure measures asks the decision maker to trust it. A good pack makes trust unnecessary. ## Output Contract Deliver an options pack containing, at minimum: - The decision header: team and headcount in scope, the problem in one sentence, the strategic outcome served, the decision maker, and the decision date. - The shared fact base: demand by work type and segment, current roles with owners, current layers, and the constraints every option was built under. - One description per option in the same shape: grouping basis, units, headcount and managers per unit, layers, where each kind of work lives, outcome owners, matching process and reward changes, and move counts by kind. - The structural check per option from the tool: estimated span, layers, manager share, utilisation, role ownership, every flag, and the fix, mitigation, or written acceptance for each flag. - The scoring table per option: every criterion score with its evidence, the weights agreed before scoring, totals, gate results, and the ranking. - The sensitivity result when the top two are within 5 points: both weightings, both rankings, and what decides between them. - The recommendation with its conditions, the fallback if a condition is refused, and the risks accepted in writing. - The transition risk register for the recommended option: each risk with an owner, a mitigation, and a date. - The communication sequence: each message, its audience, and its date or trigger, including what is not changing and the 30, 60, and 90 day checks. - The legal gate note: which consultation or notification duties were checked, for which jurisdiction and agreements, and where local advice is still needed. ## Operating Rules - Compare options on one fact base, one criteria set, and one weight set. An option scored on friendlier facts or weights has not been compared, it has been promoted. - Keep scores tied to evidence. Name the data behind each score, and label any score that rests on judgement alone as judgement. A precise total built on guessed scores is still a guess, and the pack should not hide that. - Do not present tool thresholds as industry standards. Span, utilisation, layers, and ownership flags in the tool are heuristics that force a question. The answer comes from the nature of the work, the workforce, and the coordination the work needs. - Never design around a named person, and never score an option on private information about individuals. Options are about work, roles, and capacity. Decisions about real people's jobs follow the chosen design, through the proper process, and need human review and local legal advice. - Do not announce or imply a chosen design before the consultation gate has been checked and any consultation that could change the design has closed. Calling a decision a consultation destroys trust in the next one. - State the cost of each option honestly, including duplicated roles, manager count, and parallel running during the move. An option that only wins when its costs are left out will lose later, in public, at a worse time. - Keep the pack's underlying data on a need to know basis until the communication sequence starts. Headcount, role, and cost detail by small team can identify individuals, and early leaks reach staff as rumour with none of the context the sequence exists to give.