The org chart updates in a day. The ownership graph — the thousands of small assertions about who owns which service, which alert, which repo, which vendor account — doesn't move with it. Makmel describes the result well: for months after a reorg, the org has two charts, the one on the slide and the one the pager believes, and incidents happen in the second one.
If you just inherited a team through a reorg, this is the actual job in front of you. Not "build trust" in the abstract, not "set a vision." Figure out what this team actually owns right now, as distinct from what the announcement said they own, and close that gap before it costs you an incident, a stalled PR queue, or a vendor contract nobody's paying attention to.
The gap is bigger than you think, and it's not evenly distributed
The failure mode isn't dramatic. It's an alert routed to a rotation staffed by people who moved teams two weeks ago. A code owners file that routes reviews to someone who hasn't touched that repo since the split. A runbook that says "escalate to the platform team," and the platform team doesn't exist anymore (Makmel). None of this shows up on day one. It shows up in week one as alerts going to the wrong people, in month one as review queues quietly stalling, and in month two as orphaned systems nobody remembers claiming.
Collective Genius frames the underlying issue as a distinction most reorg announcements skip entirely: responsibilities and decision rights are not the same thing. You can tell someone they now own a service without anyone agreeing on who gets to decide its roadmap, who approves its deploys, or who signs off when it conflicts with another team's priority. People keep making decisions they used to own because nobody explicitly took that authority away — they just got a new box on the chart.
The practical implication: don't start by redrawing responsibilities. Start by finding the orphans and the shadow owners, because those are where the actual damage accumulates while you're busy running your first team offsite.
Diagnose before you reassign anything
This is where most new managers get the sequencing backwards. The instinct is to come in with a plan — new ownership map, new on-call rotation, new review structure — presented in week one as a show of competence. MATSH's guide to inheriting a team makes the case for the opposite order: observe the existing workflows before touching them, because what looks dysfunctional from outside sometimes has a reason behind it, and what looks fine sometimes conceals a problem the team stopped mentioning because raising it never changed anything.
The same discipline applies to the technical ownership audit. filipeeduardo.dev's first-30-days sequence for taking over a codebase puts access and ownership facts before any architectural judgment: who controls the repos, the cloud accounts, the domains, the secrets, and whether those are tied to a company account or a person who may be gone in a month. A near-identical first-week checklist for inherited systems — can you build and ship it yourself, where does the truth live, what breaks silently — shows up independently in a separate first-week audit framework. The convergence matters: both treat ownership as a factual question you answer by testing the system, not a social question you answer by asking around and taking the first confident answer.
Translate that to the team level and the order looks like this: map who currently has write access and on-call duty for each system, not who the announcement assigned it to. Find the services with two claimed owners and the ones with none. Then, and only then, start resetting decision rights explicitly — in writing, not implied by the org chart.
The signal that tells you it's working
Watch what still escalates to you or to the CEO six weeks in (Collective Genius). If the same categories of decisions keep landing on your desk that should now belong to a lead on the new team, the reassignment didn't actually take — you redrew boxes, not authority. If orphaned systems keep surfacing in incident reviews past month two, your ownership audit missed edges in the graph that nobody remembered to mention because nobody remembered they existed.
A reorg is finished when the behavior changes, not when the chart does. Most of them never get checked against that bar.