Comparing two org structures means answering four questions about each\noption against the other: how many positions it has (and how many are\nfilled), what it costs, which positions it adds, removes or changes, and who\nends up reporting to whom. Get those four answers on one screen, from the\nsame starting data, and most reorg debates get much shorter. Here is how to\nset the comparison up so the answers are honest.
\n"Compare org structures" can mean two different jobs. One is comparing\nstructure types: functional against divisional, a flat org against a\nlayered one, a matrix against a single line of command. That's a design\nquestion, and the textbooks are right that no type wins everywhere. The\nother job, the one a reorg actually needs, is comparing two concrete\noptions for your own team: "Platform team" against "Two divisions", or\neither of them against today. This post is about the second job. Choosing a\ntype is only useful once you can see what it does to your positions,\nreporting lines and budget.
\nBe clear which pair you're comparing, too. Each option against the current\norganization tells you what it would take to get there. The two options\nagainst each other tell you what you give up by picking one. You usually\nwant both readings.
\nA comparison is only as fair as its inputs. If one option was sketched from\nlast quarter's headcount and the other from an HR export, every difference\nyou find is partly noise. Start both from one faithful picture of today:\nevery team, every position (filled or open) and every reporting line.
\nIn Resorcerer each option is a model:\na full copy of the organization, with its own units, positions, reporting\nlines and assignments, that you can rearrange without touching any other\nmodel. Copy the real organization once per option. Copy it with\nassignments when the question is "next quarter, starting from where we\nare", or without assignments when the shape is the question and the\nnames aren't yet. A copy remembers where it came from, so its comparison\ndefaults to the model it was copied from.
\nKeep the options private while they name people. A\nprivate model is visible\nonly to organization admins and the people you grant access to.
\nThe fastest way to rig a comparison, by accident or not, is to cost the two\noptions differently. One option gets the real salary of each named person,\nthe other gets a round number per new hire, and the cheaper option is\nsimply the one with the friendlier assumptions.
\nPrice both from one set of rules instead. A\ncost profile gives\na price to a shape of position (an Engineer, at Senior, in London) and every\nmatching position is costed automatically, with the most specific rule\nwinning when several match. Cost profiles live at the organization level\nand are shared by every model, so both options are priced by exactly the\nsame rules, and the cost follows as you keep editing.
\nTwo checks before you trust a total:
\nOpen one option's Compare view and pick the other model. The top of the\ncomparison is the number the conversation usually turns on: total\npositions, filled positions and total cost for each model, and the delta\nbetween them.
\nRead those first, against the goal you wrote down for the reorg (see\nHow to plan a reorg for setting one). If an\noption misses the budget by a wide margin, the detail below won't save it.\nIf two options land within a rounding error of each other, the decision is\nabout structure, not money, and you know where to spend the meeting.
\nTotals hide trade-offs. Two options can add the same number of positions\nand cost the same, yet one moves a dozen people and the other moves three.\nBelow the totals, Resorcerer classifies every difference as added,\nremoved, changed or unchanged, for units and positions alike.\nFilter to one change type, or to one part of the tree, to answer questions\nlike "what happens to Engineering?". Open a changed position and you see\nthe before and after of each attribute that differs: role, level, location,\ncompany, occupant, units and reporting line.
\nThat last one is where structure comparisons usually go wrong. A new\nreporting line is a real change for the person on the end of it, even when\ntheir title, level and pay stay put. Reading the reporting-line changes per\nmanager is the quickest way to see who gains a team, who loses one, and\nwho ends up with a much wider or narrower span than before.
\nTo say a position changed rather than was removed and another added, a\ncomparison has to recognize the same position in both structures. Resorcerer\nmatches on the strongest signal available, in this order: the same person\nassigned (high confidence), the same attributes and the same reporting line\n(high), the same attributes and the same unit (medium), and the same\nattributes alone (low). Anything left unmatched shows as an addition or a\nremoval.
\nThis matters when you compare two heavily rewritten options. The more you\nchange at once, the less certain the matching gets, so a comparison that\nlooks stranger than expected is usually two big rewrites being matched on\nweak signals. Copying each option from the model you mean to compare it\nagainst keeps the matching on its strongest footing. The table is in\nCompare and merge.
\nEach option is a full model, so every analysis view works on it. Open the\nsame view on both options and you get the comparison at a level the totals\ncan't:
\nThe views are described in\nAnalyse a model.
\nFew reorgs land in one day, so a single snapshot can flatter an option that\nfront-loads its hires. Give each option's positions start and end dates, or\nlay its phases out as dated points on a\ntimeline, and\nthe Counts and Costs views plot headcount and cost as a trend. Two options\nwith the same end state can look very different in March.
\nThe same Compare view also works backwards. Pick one of a model's own\nsnapshots as the other\nside and you see exactly what has changed since it was taken, which is how\nyou check the reorg you shipped against the one you approved.
\nWhen an option wins, the comparison you used to choose it becomes the\nchange list. Merge the winning model into the real organization and review\neach change on its way in: accept the new team, reject the hire that isn't\nfunded yet. The losing option stays as it was, so if the decision is\nrevisited next quarter, the alternative is still fully worked out rather\nthan a half-remembered slide. That whole loop, from copy to merge, is what\norg scenario planning in Resorcerer is built\naround.
\n","summary":"Compare two org structures or reorg scenarios on positions, cost, headcount and reporting lines, priced by the same rules, before you commit to either.","tags":["reorg","scenarios"]},{"id":"https://www.resorcerer.ai/blog/how-to-plan-a-reorg/","url":"https://www.resorcerer.ai/blog/how-to-plan-a-reorg/","title":"How to plan a reorg without breaking your team","date_published":"2026-09-27T00:00:00.000Z","content_html":"A reorganization is a set of changes to who reports to whom, which teams\nexist, and what all of that costs. Planning one well means being able to\nanswer three questions before anyone hears a rumour: what exactly changes,\nwhat it costs, and when each part happens. Here is a sequence that keeps\nthose answers honest from the first sketch to the day it goes live.
\nEvery reorg plan is a diff against today, so the first job is a faithful\npicture of today: every team, every position (filled or open), every\nreporting line, and who sits where. Pull it from the HR system or a CSV\nrather than from memory, and check it with the managers who own each\nbranch. Then freeze it. In Resorcerer that means\nprotecting the model of\nyour real organization: nobody can edit it by accident, and the only way it\nchanges is by a reviewed merge. Make it live\nand it stays current as well: joiners, leavers and manager changes in your\npeople directory arrive as proposals to review. If that picture is wrong,\nevery comparison you make later inherits the error.
\n"Flatten the org" is a slogan; "no manager with fewer than four direct\nreports, and engineering under one leader by Q2" is a goal you can test a\nplan against. Pick the two or three measures that define success (spans of\ncontrol, cost per team, one accountable owner per product, time to fill the\nopen roles) and write them at the top of the plan. Every option you draft\ngets judged against the same list, which is what stops the loudest option\nfrom winning by default.
\nThere is always more than one way to reach the goal, and the way to find\nout which is best is to build each one properly. Copy the real organization once per\noption: "Platform team", "Two divisions", "Hiring freeze". Copy it with\neveryone assigned when the question is next quarter starting from today, or\nwithout assignments when the shape is the question and the names aren't yet.\nEach copy is a full organization you can rearrange freely without touching\nthe real one, which is the whole point of org scenario\nplanning. Keep the drafts private while they name\npeople; a restructure that isn't approved shouldn't be readable by everyone\nit affects.
\nSlides hide the cost of a reorg because nobody adds it up. Compare each\nscenario against the real organization and read the totals first: positions, filled\npositions, and cost, with the delta. Then the detail: which positions were\nadded, removed or changed, and for each change the before and after of role,\nlevel, location and reporting line. Two things fall out of this quickly.\nOptions that looked similar on a slide turn out to differ by a dozen hires,\nand options that looked bold turn out to move three people. Costing every\nposition by rule, with a\ncost profile per\nrole and level, means the totals stay right as you keep editing, and a\nproblems report tells you when a position is priced by nothing.
\nFew reorgs happen on one day. A new team forms in March, its manager is\nhired in May, a contractor rolls off in August. Put the plan on a\ncalendar: give each position a start and end date, and if the reorg lands in\nphases, hold each phase as its own dated snapshot on a\ntimeline.\nHeadcount and cost then read as a trend across the year rather than a single\nnumber, and each position carries its own history, so "when does this role\nopen?" has an answer that everyone can see.
\nPeople don't fear reorgs; they fear not knowing what a reorg means for them.\nThe comparison you used to choose the option is also the clearest thing you\ncan show a manager: exactly which positions in their branch change, what\nthey change to, and what stays. Walk each leader through their part of the\ndiff before the announcement, correct what they catch, and let the same view\nbe the source for the all-hands. A plan that lives in the structure has one\nversion; a plan that lives in slides has one per meeting.
\nWhen the option is approved, don't retype it. Merge the scenario into the\nreal organization's model and review each change on its way in: accept the new team, reject\nthe hire that isn't funded yet, resolve anything both models changed. Because\nthat model is protected, the merge is the only route, so what went live is\nexactly what was reviewed. Keep working in the scenario afterwards and the\nnext merge brings only what changed since, so phase two lands the same way\nphase one did. The full workflow is in\nCompare and merge.
\nA reorg planned this way is still hard. The judgment about who leads what\ndoesn't get easier. But the mechanics stop getting in the way: every option\nis fully worked out, every number is real, and the day it goes live nothing\nis a surprise.
\n","summary":"A practical sequence for planning a reorganization: map today's org, draft the options as scenarios, compare cost and headcount, merge in stages.","tags":["reorg","planning"]}]}