Restructuring will not fix the queue
Reorgs move the boxes. The waits live on the lines between them, and they survive the announcement untouched.
There is a moment in many engagements when the sponsoring executive, reading the findings, says some version of: maybe we need a reorg. It is worth writing down why our answer is almost always not yet.
A reorg redraws ownership boundaries. The delivery problems a diagnostic finds mostly live in the traffic across boundaries: review queues, environment contention, handoffs where context evaporates, the recurring retro items no team can fix alone. Moving the boxes changes which boundary the traffic crosses. It does not change that the traffic waits, because the waits are properties of the process, and the process is usually copied faithfully into the new structure by the same people who ran it in the old one.
Reorgs also charge upfront. Months of context loss, re-formed teams re-learning each other, roadmaps paused politely, and every existing measurement series broken at the seam, so the change can never quite be evaluated. An organization that reorgs to fix delivery has spent its year's change budget before touching a single queue.
The sequence that works runs the other way. Fix the two or three worst waits inside the current structure, where causality is still traceable. If, after that, the structure itself is visibly the constraint (a team owning two unrelated systems, a dependency crossing four boundaries on every change), then reorganize, once, with the queue data as the design brief. Structure should follow diagnosis. The announcement email is not a treatment.