Resource Allocation

When planning meetings set targets and stopped there, the targets mostly went unmet. The conclusion is that next quarter the team will double new customers, ship the enterprise permissions feature, and rebuild the mobile app. All three are good things, so there's nothing to object to.

The problem is that the same people would do all three. Six engineers split across three initiatives is two each. Unless each one is a two-person, three-month job, all three end the quarter somewhere around halfway. At the next planning meeting the three are still there and two new ones have arrived.

There's a reason this stays invisible. Setting targets is addition and setting resources is division, and meetings only do the addition. Without writing down who spends how many weeks on what, six people get counted as twelve, and nobody in the room has to say anything untrue for that to happen.

Resource allocation pulls that division into the planning session. Put a column for people and money next to each target and the fact that a fourth initiative requires removing one of the first three becomes visible in the room.

Count what you have first, then divide inside it. Reverse the order and the arithmetic stops working.

1. Count available capacity — the headcount an organization is allowed to carry, and the budget. Count what can actually work this period rather than who is on the roster. If one of six people starts next month, they're two of the three months, and the first month counts as half while they ramp.
2. Take out the maintenance share first. Support responses, incident handling, security checks — work that goes out whether or not anything new happens. Twenty to thirty percent of engineering capacity is typical. Divide without removing it and every initiative lands late, by roughly the amount you failed to subtract.
3. Attach what's left to initiatives, writing both people and duration. Three engineers for three months is nine person-months. That unit is what makes two initiatives comparable, and it also makes an overcommitment arithmetically obvious instead of arguable.
4. When nothing is left, decide what comes out. This is where the decision actually happens. Adding a fourth initiative means pushing one of the first three to next quarter or cutting its scope.
5. Communicate what was written down. Announce only what's being done and the person who owned the dropped initiative never learns it was dropped. Say what isn't happening, and why. A plan that only lists the yes items gets quietly re-expanded by everyone who assumed their item survived.

One more thing needs setting: the ratio between new bets and growing what exists. Put everything into new initiatives and what's working today gets neglected; put everything into maintenance and there's nothing new to sell next year. The common approach is fixing the share for new work first, then choosing initiatives inside it.

The decision gets made in three settings.

1. Annual planning. This is where the large numbers get set — how far headcount can grow, how much marketing spends across the year. The totals fixed here become the floor that quarters divide.
2. Quarterly planning. Choosing what these three months do inside the annual totals, and the place where changed circumstances get absorbed. If enterprise inquiries came in higher than expected, the decision to move people there happens here.
3. Mid-quarter. Circumstances shift after a plan exists. One large customer making a specific feature a condition moves that work to the front. What matters then isn't adding the work but deciding in the same breath what gets deferred.

It travels with prioritization, deciding what to do first with limited resources. The difference is setting order versus setting amount. Set only the order and how many people go on the first item is still open; set only the amount and what to do with it is still open. In real meetings the two judgments alternate, and a session that only ever does one of them ends without a plan anyone can execute.

It also connects to company priority, ordering initiatives across several organizations. Past three organizations, allocating inside each one separately hides both overlaps and gaps — two teams building adjacent things, and nobody owning the work between them.

"To add a fourth, one of the first three comes out. Which one do we defer?"

Turning an addition meeting into a division meeting.

"Twenty-five percent of engineering goes to maintenance. We have to plan off what's left."

Correcting a miscount of available capacity.

"This quarter runs seven to three, new work against maintenance."

Fixing the ratio before choosing the work.

At Pagedeck, Grace builds the table in person-months at quarterly planning. Six engineers across three months is eighteen person-months, four go to maintenance first, and fourteen remain. Last quarter six went to enterprise permissions, five to app improvements, and the remaining three to data work.

The cell that changes most often is the maintenance share. One quarter it was planned at four and came in at six. All three initiatives that quarter landed late, and the cause turned out to be that time spent on support and incidents was never recorded, so it never made it into the plan. Since then maintenance hours get logged every quarter and used as the basis for the next one.

A common belief is that resource allocation means dividing a budget. Money is the visible resource, so that's where attention goes. But what's genuinely scarce at a software company is usually not money but one particular person's time. You can get approval to buy a tool; you cannot double the three months of the one engineer who can build that feature. In meetings that finish allocation by looking only at the budget sheet, that person is assigned to three initiatives at once.

The other belief is that a fair split is a good allocation. Give each organization a similar amount and there are fewer complaints and it's easier to explain. But the purpose of allocation is outcomes, not fairness. If the decision was to produce results on the enterprise side this quarter, more than half should go there, which means other organizations get less this quarter. Quarters divided evenly tend to end with every organization slightly further along and no initiative finished, which reads as a busy quarter and reports as nothing shipped.