Watch a leader prepare for a planning cycle and you will see the same two artifacts every time. There is a slide with boxes: teams, names, open seats, maybe a dotted line or two. And there is a spreadsheet with rows: salaries, start dates, a SUM at the bottom that someone promises is current.

The slide is the one people argue over, because structure is what leaders actually reason about. Who reports where, which team grows, what gets split. But the slide cannot add. Every change to a box means someone reopens the spreadsheet, finds the matching rows, edits them, and re-checks the total. In practice this reconciliation happens late at night before the review, and it is wrong more often than anyone admits.

The spreadsheet has the opposite problem. It can add, and it cannot see. A row that says L5 · 1.0 FTE · $260,000 carries no information about what happens to the platform team if that person moves to infra. Structure lives in the slide, money lives in the sheet, and the actual plan lives in the head of whoever edited both most recently.

One object, both natures

The fix is straightforward to state: the box on the chart and the row in the budget should be the same object. When you drag a team under a new leader, the totals should follow. When you add a role, it should arrive with a defensible price attached. When you ask what the plan costs in March versus October, the answer should come from the plan itself, with start dates and allocations applied, and no one should have to maintain that by hand.

Once the plan computes, better questions become cheap. What does the growth version cost against the flat version? Which people are committed to two teams at once? Does this fit the envelope finance gave us? Those are the questions the meeting is actually about, and today most teams answer them with manual reconciliation and hope.

Decisions deserve the same treatment

There is a second artifact that never survives the cycle: the decision itself. Someone approved three engineers for Platform in June. By November, nobody can say who, or under what conditions, or which version of the plan they saw. The plan moved on and took the context with it.

So a computing plan should also keep its history. Proposals should be reviewable against the exact version they were made from. Approvals should record names, dates, and conditions. The current plan should be traceable back through every decision that produced it. None of this is exotic; it is how software teams have handled changes to code for decades. Team budgets, which are usually larger and harder to reverse, get less rigor than a CSS fix.

We are building Arrange around these two ideas: a plan you can draw that prices itself, and a record of how it came to be. You can try it in your browser, on your own org, free.

Start a plan and see what your current structure actually costs.