Capacity Allocation for Platform, Data, and AI

A fictional online marketplace had a group led by a vice president, with three directors reporting to her: platform engineering, data engineering, and AI. Each director brought a plan for the quarter, and each plan was reasonable. Platform had to upgrade the streaming ingestion layer before its current version leaves vendor support at the end of the second quarter. Data wanted to move its nightly pipelines onto that layer. AI had told the risk team that a fraud-scoring model fed by real-time features would launch at the end of the first quarter. All three plans depended on the same five senior engineers, and none of the directors had padded a request. When the vice president added up the days requested, the group needed 240 person-days from specialists who had 185 free days, and the largest gap sat with the two engineers who could change the ingestion layer in production. Every number in this example is invented for the illustration. The question is how a leader should count capacity, order the work, staff the gap, and decide in advance when to move people.

Operational commitments come off the top

Operational work is owed to people who already depend on the platform, and a missed page or a late security patch costs something this week. The vice president therefore subtracts it before counting what is available for new work. In the marketplace it has three parts: incident response and on-call duty, security patching and version maintenance, and support requests from teams that consume the platform. The group estimates 90 person-days for the quarter.

Capacity belongs to a skill, not to a headcount. The five engineers are not interchangeable: two of them, called the ingestion-qualified pair here, can diagnose and change production ingestion; the other three cannot yet. A quarter has 13 weeks, or 65 working days. After 10 days each for leave, holidays, and training, every engineer has 55 days, so the five have 275, of which the pair holds 110 and the other three hold 165. Of the 90 operational days, 45 involve production ingestion and can only be done by the pair. The other 45 can be done by anyone and fall to the other three. Free capacity is therefore 110 − 45 = 65 days for the pair and 165 − 45 = 120 for the others, 185 in all. Before any project starts, operations takes 45 of the pair’s 110 days, about 41 percent.

Google’s site reliability engineering (SRE) organization sets limits for this kind of load: at least half of each engineer’s time on engineering project work, and no more than a quarter of time on call. It sets them because operational work expands to fill whatever time it is given. The entries on toil and on-call rotations explain how those limits are defined and measured. They are Google’s targets for its own teams, not general norms, but they show that a ceiling on operations is a leadership decision made in advance. The pair’s 41 percent is under a 50 percent ceiling, and it is a plan rather than a measurement. It also falls on two people.

Operations grows with success, because each launched service adds pages, patches, and support requests. Suppose the AI director estimates that the fraud model will add six days a quarter to the pair’s operations. Their free days then fall from 65 to 59 the following quarter. A director who asks for capacity to launch something should also state what it will cost to run.

Why a fully booked specialist makes everyone wait

Specialists also receive work that cannot be scheduled: a consuming team needs a production change, an incident needs a second engineer, a design needs a qualified reviewer. If the pair is booked to 100 percent of its free time with planned projects, those requests queue behind the projects. Queueing theory says how long. In the simplest model, requests arrive at random, one server handles them one at a time, and handling times vary at random. If \(\rho\) is the share of time the server is busy and \(E(s)\) is the average time to complete one request, the average wait before work starts is

\[ W_q = \frac{\rho}{1-\rho}\,E(s) \]

At 50 percent utilization, a request waits one service time. At 80 percent it waits 4 service times, at 90 percent 9, and at 95 percent 19. If the average request takes two days, those waits are 2, 8, 18, and 38 days. Little’s law turns the wait into a queue length: at 90 percent utilization with two-day requests, arrivals run at 0.45 per day, or 2.25 per five-day week, and 0.45 × 18 = 8.1 requests are waiting on average. Two specialists drawing from one shared queue do better than one. At 90 percent utilization each, the average wait in the same model falls to about 8.5 days, still more than four times the length of a request. Real work is less regular than this model, but the shape carries over: waiting grows slowly at moderate utilization and steeply near full.

The vice president therefore adopts a planning rule: commit projects to 80 percent of a group’s free days and leave the rest for arriving requests and estimating error. The 80 percent is a leadership choice, not a constant. A group with steady request flow can plan higher, and one with spiky incidents needs more. Here the rule gives project ceilings of 0.8 × 65 = 52 days for the pair and 0.8 × 120 = 96 days for the others, 148 in all. The pair keeps a reserve of 13 days.

Limiting how many projects each specialist carries at once protects the ceiling from the other direction, because splitting attention across projects adds switching cost that no spreadsheet shows. The WIP limit entry explains how to set a limit from usable capacity. DORA’s guidance on work-in-process limits adds that idle time exposed by a limit should be spent removing the waits behind it, not filled with new work.

Three reasonable plans, one set of people

A request that says “two engineers for the quarter” cannot be compared with capacity. The vice president asks each director for days by skill, the earlier work each request waits on, and the reason for its date. The directors’ answers, split into days that need the pair and days anyone can do, are below.

Quarter 1 demand and capacity (person-days)	Pair (ingestion-qualified)	Other three	Total
Platform: ingestion upgrade	60	30	90
Data: pipeline replatform	15	55	70
AI: real-time fraud features	25	55	80
Requested	100	140	240
Free after operations	65	120	185
Requested as a share of free days	154%	117%	130%
Project ceiling (80% of free days)	52	96	148
Requested as a share of the ceiling	192%	146%	162%

The group total, 162 percent of the ceiling, understates the problem for the one skill that cannot be replaced. The pair is at 192 percent. Nobody planned badly: each director assumed the pair would be available for their own work, and no one below the vice president has authority over all three requests. Allocation across directors is therefore the vice president’s decision right. The directors’ reviews prepare the inputs, but the tradeoff is settled above them.

Dependencies decide the order

Three kinds of dependency shape the plan. The first is sequence: AI’s real-time features and Data’s pipelines both run on the upgraded ingestion layer, so their production work cannot start until the upgrade is finished. The second is shared people: the upgrade and its dependents all draw on the same pair. The third is outside the group: the vendor’s support date and the AI commitment to the risk team. When a team’s work waits on another team’s queue, the delay comes from scheduling more than from effort, which the entry on backlog coupling describes.

Sequence and shared people together set a minimum calendar time that more staff elsewhere cannot shorten. At the ceiling, the pair’s project capacity is 52 ÷ 13 = 4 days a week. The upgrade needs 60 pair days, which is 15 weeks, and all 100 pair days requested take 25 weeks. Even if the other three engineers were free, the ingestion work cannot finish in a 13-week quarter.

The vice president orders the work by what each item blocks and what it owes outside the group. The upgrade goes first, since the dependents wait on it and it carries the only hard external date, the end of the second quarter. That date allows it to run past the first quarter by 8 days. AI’s real-time path is next, because the risk commitment makes it costly to miss. Data’s ingestion work has no outside date and goes last. The AI director’s launch date in the first quarter cannot hold for real-time features, so the vice president proposes launching the model in the first quarter with features refreshed nightly, work the other three can do, and adding the real-time path in the second quarter. The risk team must agree that nightly features meet its requirement. If it does not, the choice is between delaying the launch and letting the upgrade run past vendor support, and the vice president takes that to the executive who owns the commitment instead of settling it quietly inside the group.

Two-quarter plan (person-days)	Q1 pair	Q1 others	Q2 pair	Q2 others
Platform: ingestion upgrade	52	30	8	0
Data: pipeline replatform	0	11	15	44
AI: fraud features (nightly in Q1, real-time in Q2)	0	55	25	0
Committed	52	96	48	44
Ceiling	52	96	52	96
Slack	0	0	4	52

The plan fits. The two quarters together have 296 days of project ceiling against 240 requested, and the sequence respects the dependency. It has costs that the directors must accept in writing. Data’s replatform finishes at the end of the second quarter, not the first. AI’s real-time path arrives a quarter late. In the second quarter the pair has 4 days of slack, one week, and the dependents have 40 pair days to complete after the 8 remaining upgrade days. At 4 days a week that is 2 weeks plus 10 weeks, ending in week 12 of 13. Any miss in the pair’s work spills into the third quarter.

The alternative to a shared pair is to make the specialists a team of their own with a single intake queue, which Team Topologies calls a complicated-subsystem team, one that holds expertise other teams consume as a service. The post on organizational design and team interaction covers when that fits. It makes the allocation visible and gives the specialists one set of priorities. It also creates a fourth backlog for the three directors to wait on, so the allocation decision still has to be made by someone with authority over all of them.

Staffing the gap

Before adding people, the vice president asks whether the demand is temporary or lasting. The upgrade is a one-time block of 60 pair days. The 45 days of production operations recur every quarter and are concentrated on two people. A permanent hire to cover the upgrade’s peak would be staffing for demand that disappears, while the lasting concentration of operations and knowledge is a real structural problem.

A hire takes time to help. Suppose recruiting takes 12 weeks, so a decision at the start of the first quarter yields a start at the beginning of the second. In that quarter the new engineer spends eight weeks learning and contributes about 20 productive days in the last five. Mentoring takes 12 days from the pair, so the net gain in the engineer’s first quarter is 20 − 12 = 8 days. In the next quarter the engineer has 55 days and mentoring takes 4, for a net 51. These are assumptions to replace with the group’s own history. A hire is the right answer to a lasting gap, but it does nothing for the first quarter and adds only 8 days to the second.

Cross-training creates no days. It moves the constraint and reduces dependence on two people. Suppose one of the other three, S3, pairs with the pair during the second quarter. Mentoring costs the pair 6 days, and S3 takes 10 of Data’s 15 pair days under supervision. The pair’s second-quarter commitments become 8 + 25 + (15 − 10) + 6 = 44 against the ceiling of 52, so slack rises from 4 days to 8, two weeks. The group has the same total days, and the schedule has more room for a miss.

The bus factor of the ingestion layer is 2, since both qualified engineers must be gone for the work to stop. That understates the exposure. If one leaves, ingestion capacity halves, and with demand already at 154 percent of free days, that ends the plan. The post on conflict, underperformance, and organizational health works through such a dependency on a single engineer. The readiness evidence used for succession in building a leadership team and succession bench applies to specialists too: S3 counts as qualified after performing supervised production changes, not after being named as a backup.

Contracting or borrowing an engineer from another group has similar limits. Access, context, and review time come before output, and the pair absorbs that cost. Narrowing scope is the cheapest option when it is acceptable: the nightly-features launch removes 25 pair days from the first quarter without adding a person. The vice president chooses in that order here. Narrow the scope, cross-train now, and open a requisition only if measured operations load stays above the ceiling after the upgrade ends. Whether a request deserves the capacity at all is a portfolio question, covered in choosing among approved projects.

Reallocation triggers and who decides

A plan is a forecast, and the useful question is what breaks it. DORA’s 2024 report finds that unstable organizational priorities cause meaningful decreases in productivity and substantial increases in burnout. Reallocation should therefore be rare, based on defined evidence, and agreed before pressure arrives. The vice president and the directors settle four triggers in advance, each with a measurement, a first response, and a decider.

Trigger	Evidence	First response	Decides
Operations overrun	The pair’s operations rate over the trailing four weeks, projected across the quarter, exceeds plan by more than half the 13-day reserve. The plan is 45 ÷ 13 ≈ 3.5 days a week; the line is 51.5 ÷ 13 ≈ 4 days a week.	Pause Data’s pair days. Move operations that anyone can do to the other three.	Vice president
Upgrade slip	The upgrade is not finished by the end of week 3 of the second quarter. After that, the dependents have exactly the 10 weeks they need and no slack.	Defer Data’s pair days first. Reopen the AI real-time date with the risk team if that is not enough.	Vice president; the executive who owns the commitment for the AI date
Loss of a qualified engineer	Departure, or absence beyond two weeks, of either pair member.	Freeze new commitments that touch ingestion. Rebuild the plan with the Platform director and use S3 for supervised routine work.	Vice president; hiring approval follows the company’s normal approvers
External date or obligation changes	The vendor extends or shortens support, or a security finding sets a deadline.	Re-sequence from the obligation backward. Mandatory work precedes discretionary work.	The obligation’s owner sets the date; the vice president re-plans

Directors can move work inside their own allotment without asking. A move that takes pair days from one director’s commitment and gives them to another’s goes to the vice president, because it changes a commitment someone else is counting on. Each reallocation is recorded with what moved, what it displaced, the new date, and the approver. The record keeps the cost of a move visible, and it supplies the evidence for the next quarter’s ceiling and for whether a trigger was well set.

At the start of the second quarter the vice president repeats the arithmetic with measured numbers: how many days the pair actually spent on operations, how much of the upgrade is done, what the AI launch added to the operating baseline. If those differ from the assumptions in the tables, the plan changes. The directors are then asked to explain the differences in days by skill, not to defend their original requests.

References

• Google, Site Reliability Engineering, Chapter 5: Eliminating Toil.
• Google, Site Reliability Engineering, Chapter 11: Being On-Call.
• DORA, Capabilities: Work in process limits.
• DORA, Accelerate State of DevOps Report 2024.
• Matthew Skelton and Manuel Pais, Team Topologies: Key Concepts.
• University of Florida, Elementary Queuing Theory Notes (M/M/1 queue).