To review a reorg proposal before you commit to it, put the proposal, the problem it claims to fix, the evidence for that problem, and any alternatives that were considered into one request. Then instruct Pingpong to judge whether the proposal is ready for a decision: whether the evidence shows that structure causes the problem, whether a smaller change would fix it, what result the reorg should produce and by when, and what it will cost during the transition. Ask for a verdict first, ready or not ready, and a list of what is missing. Do it before anyone drafts the new chart, because once people are assigned to new roles it is hard to reopen whether to reorganize at all.
This page is for chief executives deciding whether to restructure, and for the board members or executives reviewing a proposal someone else wrote. Once the decision is made and you are planning the rollout, see war-game a reorg before you announce it. More decision guides live under work decisions before you commit.
What a ready proposal answers
- What problem it solves, with numbers from the last two or three quarters.
- Why the structure causes that problem, and why a change in process, incentives, or one leader would not fix it.
- Which alternatives were considered and why each was rejected.
- Which measure should improve, by how much, and by what date.
- What the transition costs, including the months when teams are learning new reporting lines.
- What result would show the reorg did not work, and what happens then.
Most proposals answer the first item and skip the second. A reorg changes reporting lines. If the problem comes from how decisions get made, how work is planned, or how people are paid, it usually continues under the new lines.
Smaller changes to test first
Before a restructure, it is worth asking whether one of these would fix the problem with less disruption: moving a single decision right to a different leader, changing an incentive that pulls two teams apart, replacing one manager, standing up a cross-functional team for a fixed period, or changing how quarterly plans account for dependencies. A useful review names which of these the proposal ruled out and on what evidence.
A worked example
This example is illustrative and does not describe a customer. At a 220-person data infrastructure software company, the chief operating officer proposes merging product management and engineering under a single chief product officer. The reason given is roadmap reliability: over the last two quarters the company shipped 4 of the 11 features it committed to customers, and the board has asked twice what the plan is.
The chief executive pastes the proposal, the two quarters of roadmap commitments with their status, the team list, and notes from the last two board meetings, and asks Pingpong whether the proposal is ready.
A useful pass says it is not ready. Six of the seven missed features depended on the same 9-person data platform team, which had no spare capacity and was not consulted when the commitments were made. The proposal does not touch that team or the planning process that committed its time without asking. It names no measure of success and no alternative. It also assumes the merged organization delivers at full speed from the first month.
The chief executive defers the reorg by one quarter. Four engineers move to the platform team, and quarterly planning adds a dependency review before any customer commitment. The measure is the share of committed features shipped on time. If it stays below 70 percent at the end of next quarter, the reorg comes back to the leadership team with that data. The board hears this plan at its next meeting as the answer to its question, along with the date for reconsidering.
A request you can copy
Below are a reorganization proposal, the problem it is meant to fix, the evidence for that problem, and any alternatives that were discussed. Start with a verdict: is this proposal ready for a decision, yes or no. Then say whether the evidence shows the structure causes the problem, and quote the data that supports or contradicts that. List smaller changes that might fix the problem and whether the proposal rules them out. Name what is missing: a measure of success, a date, transition costs, or a point at which we would reverse course. Don't redesign the org chart for me.
Paste the underlying data so the pass can check whether the problem is where the proposal says it is.
How Pingpong runs the review
The web review app sends your request through several models in order. Each later model receives the original request and every earlier answer, with instructions to assess the work so far. Check every flagged pattern against the source data before you act on it. For the steps inside the app, see running your first review.
What a model can't review
A model does not know the history between the leaders involved, which managers are already stretched, or what the board has said privately about the executive team. Employment and compensation questions belong with your head of people and counsel.
When the decision goes to a board vote, see war-game a decision before the board meeting. Executive starting points live under Pingpong for executives.