Resource Allocation

Origin & evolution

Allocation as a formal discipline comes from operations research and capital budgeting, where finite resources were assigned across competing projects to maximise return. Product organisations inherited the problem at portfolio scale: a fixed engineering headcount, more worthwhile initiatives than it can staff, and a quarterly ritual of dividing the first across the second.

The thinking matured once teams noticed a recurring failure. Allocating every available person to committed work, aiming for full utilisation, reliably made delivery slower. Donald Reinertsen's The Principles of Product Development Flow (2009) gave the reason from queueing theory: as utilisation climbs, queues grow exponentially, so an organisation allocated to 100% has no slack to absorb variability and work piles up waiting. Allocation and utilisation pulled apart as concepts. You can allocate people to initiatives without committing them to constant full load, and the gap between the two is where flow lives.

Practice now treats allocation as a continuous portfolio decision, revisited as bets pay off or fail, with deliberate slack built in. The annual carve-up gave way to a standing question.

How it works in practice

A 40-engineer organisation runs three programmes: core platform, a new mobile surface, and a growth experiment🧫ExperimentValidationA test designed to validate a hypothesisView reference → track. Demand for the next quarter, summed across requests, would need🫀NeedUserA user need, pain, desire, or constraintView reference → 58 engineers. The allocation decision divides the 40: 22 to platform, 12 to mobile, 6 to growth, none of which can fully satisfy its programme.

The naive move is to load each engineer to 100% of the allocation. The team that has read its queueing theory holds two engineers in reserve and targets roughly 80% committed load, because the growth track is volatile and unplanned incidents🚨IncidentDevOps & PlatformA production incidentView reference → are certain. Two quarters on, the reserved capacity is what lets them respond to a competitor🥊CompetitorMarket IntelligenceA competing product or companyView reference →'s launch without freezing every other programme. The allocation held; the deliberate under-commitment is what made it deliverable.

Resource allocation vs. its neighbours

• Capacity plan🗓️Capacity PlanTeam & OrganisationA plan for allocating team capacityView reference → models how much a single team can actually take on, given velocity and time off. Resource allocation decides how much each team gets in the first place. Allocation distributes; capacity planning tests whether the distribution is achievable.
• Prioritisation ranks initiatives by value. Allocation is what makes a ranking real, by attaching people and money to the top of the list and withholding them from the bottom. A priority order with no allocation behind it changes nothing.
• Utilisation measures how fully allocated capacity is being used. Treating high utilisation as the goal of allocation is the trap: it optimises the wrong number and lengthens the queues that allocation was meant to clear.

In the graph

In the Unified Product Graph, resource_allocation🥧Resource AllocationProgram ManagementAn allocation of team capacity sits in the programme-management region and connects to its subject through program_resourced_via_resource_allocationProgramresourced viaResource Allocationhierarchy, a hierarchical edge from program🛋️ProgramProgram ManagementA program coordinating multiple projectsView reference → to the allocation that staffs it. That placement frames allocation as a property of a programme rather than a standalone spreadsheet, and it sits beside capacity_plan🗓️Capacity PlanTeam & OrganisationA plan for allocating team capacityView reference → and team🫂TeamTeam & OrganisationA cross-functional teamView reference → so the portfolio question stays answerable: which programmes are resourced, which teams carry the load, and where the committed total has quietly outrun the capacity that exists to deliver it.