Strategic Prioritization and Resource Allocation Questions

Direct answer. Decide by commitment strength and cost of delay (what each week of delay costs), not by who shouts loudest. Deprioritize exploratory bets first, then lower-value internal work, protect customer and contractual commitments, tell affected parties within days (before dates slip), and cut scope rather than spread thin or cut quality. A hiring freeze means open roles stay unfilled; the roadmap was sized for headcount that will not arrive.

Step 1: Size the gap (illustrative). Roadmaps assumed 40 engineers across the squads (small teams that each own a product area); the freeze leaves 34 (85%). Demand is grouped into tiers, ordered by how firm the promise is, in engineer-quarters (one engineer for one quarter): committed customer or contractual (promises written into customer contracts) 12, reliability and security 8, growth bets (investments to win new customers or revenue) 10, exploratory bets (early ideas not yet promised to anyone) 6, internal tooling 4 = 40. Supply is 34, so the gap is 6.

Step 2: Deprioritize in this order.

1. Exploratory (6): cutting it closes the gap exactly. Stop it, do not slow it, because half-staffed exploration produces nothing.
2. If attrition (people leaving) continues: internal tooling (4), then halve growth bets.
3. Last: committed and reliability work; renegotiate scope or date with the customer before missing silently.

Step 3: Who to tell and when. Within the first week: the executive sponsor with the table above and the one decision needed. Then squad leads and product owners (days), then affected customers and partners, with the new date and what stays in scope, before the original date arrives. Teams hear it from me, not by rumour.

Step 4: Limit damage. Reduce work in progress (things started but not finished), assign people to fewer things, keep a buffer for incidents, and use contractors only for bounded work with a clear spec because they need ramp-up time; adding people to late work often slows it (Brooks's law, from Fred Brooks's 1975 book).

The same method applied to other situations.

• Inherited over-committed roadmap, first 30 days: list every commitment with its owner and promisee (the person or customer who was promised it), find which are real promises versus assumptions, then run the tiers above before taking on anything new.
• Two senior iOS engineers out for a month on an MVP (minimum viable product, the smallest release that tests the idea): 20 person-weeks of work remain; 5 engineers would finish in 4 weeks. During the month only 3 are available, so 3 x 4 = 12 get done and 8 remain. The 2 engineers then return, so all 5 finish the remaining 8 person-weeks in 8 / 5 = 1.6 weeks, a slip of 1.6 weeks (assuming linear work, ignoring senior review load). To hold the date, cut about 8 person-weeks of scope.
• Chronically understaffed analytics team: 5 analysts at about 30 productive hours is 150 hours per week against 210 logged demand, a 60-hour gap. Fund one hire (adds about 30 productive hours), retire the lowest-tier recurring reports (frees 30 hours), and use a vendor only for spike work (short bursts of extra demand). 30 + 30 = 60 closes the gap.

What flips it: a customer escalation making an exploratory bet urgent, or the freeze lifting within a quarter.

Direct answer

I assume a quarter is six two-week sprints (12 weeks). Two weeks of holidays leave five sprints, and 5 x 40 = 200 points of capacity. (A story point is a team's own unit of relative effort. Velocity is the average points the team finishes per sprint.) The three features total 100 points, half of capacity. I commit to all three, keep 60 points (30%) in reserve for unplanned work and overruns, and treat the remaining 40 as uncommitted stretch (extra work the team pulls in only once the committed work is on track). If estimates run 25% over, the plan still holds, and the last feature lands about 1.25 weeks later.

Building the plan

1. Capacity: 6 sprints - 1 sprint of holiday = 5 sprints x 40 = 200 points.
2. Demand: 50 + 30 + 20 = 100 points, which is 50% of capacity.
3. Commit 100 (50%). Reserve 60 (30%). Stretch 40 (20%). Check: 100 + 60 + 40 = 200. The 60/40 split is a judgment call, not a formula: the reserve is sized to cover a plausible overrun with room to spare (a 25% overrun costs 25 points, and unplanned work and the low end of recent velocity cost more), and what is left over is stretch. A team with steadier history could hold less reserve.
4. Sequence the largest and most uncertain feature first, so any estimating error shows early.

Worked example: plan versus a 25% overrun

Finishing times are cumulative points divided by 40 per sprint. At +25%, demand is 125 points (62.5% of capacity); the reserve absorbs 25 of its 60 points, leaving 35 plus the stretch. A finishing time of 2.5 means two full sprints plus half of a third, so the middle of sprint 3; 3.13 means three full sprints plus a little more, so early sprint 4. Feature C moves from the middle of sprint 3 to early sprint 4, about 0.63 sprints (roughly 1.25 weeks) later, still inside the five sprints.

How I would respond if it happens

• Detect early: check at the end of feature A. If it took well over 1.25 sprints, re-forecast (redo the schedule estimate with the real numbers) the rest before the quarter is half gone.
• Use the reserve, drop the stretch. Stretch goes first, then the reserve, before any commitment changes.
• If it goes beyond that, cut scope on feature C (the smallest piece of value) or move the date. I do not trade away quality or hold people to unpaid overtime.
• Do not add people mid-quarter. New people slow the existing team at first while they learn the code.
• Tell stakeholders at the first signal, with the new forecast and the choice (scope or date).

Checks on the inputs

Ask what the 40 measures. If it is the points finished in total, it already includes bugs, support and interruptions, which is the usual case. If it counts only feature work, the usable capacity is lower and the reserve should grow. Look at the range over the last six sprints (for example 34 to 46), not just the average. If the quarter has 13 weeks, five and a half sprints give 220 points, which only adds slack.

Pitfalls

• Planning to 100% of velocity leaves no room for the first surprise.
• Comparing points across teams; each team's scale is its own.
• Treating a forecast as a promise instead of a range.

Direct answer. Hold back a share of capacity equal to what unplanned work has actually consumed, not a round guess. For a team with a history like the one below, I would plan a 25% buffer, review it every sprint (a fixed-length work cycle of one month or less, commonly two weeks), and treat the first quarter as an experiment. A buffer is capacity deliberately left unscheduled so bugs, outages and urgent asks can use it without displacing committed roadmap items (the planned features and projects the team promised to deliver). Capacity means the person-days the team can really deliver after holidays and leave.

Step 1: Measure demand before choosing a number. Tag every ticket for four quarters as planned or unplanned, and split unplanned into bugs, outages and incidents, and urgent asks. Example: ticket "PAY-412 Fix checkout timeout, raised by on-call at 02:10" is tagged unplanned / incident; "PAY-390 Add saved cards, on the quarter plan" is tagged planned. Many teams, including analytics teams, simply agree an allowance such as "20% unplanned work" up front; the principle is the same here: the allowance is a hypothesis you test against the log. Illustrative history of unplanned share of capacity by quarter: 28%, 22%, 31%, 25%. The mean is 26.5% and the worst quarter is 31%.

Step 2: Size the buffer. Illustrative team: 8 engineers, 13 weeks, 5 days = 520 person-days gross (total before any time off). Remove 10% for holidays and leave: 468 available. A 25% buffer is 117 person-days held back, leaving 351 person-days (75%) for planned work. I pick 25%, slightly under the 26.5% mean, because part of that unplanned load can be reduced at the source (Step 4 below: fund the recurring cause as planned work, which lowers the unplanned share over time), and I would not plan to the worst quarter (31%) or the roadmap shrinks for a rare peak. Outage-heavy teams that cannot shrink the load should plan nearer the mean or higher.

Step 3: Tell whether it is too big or too small.

• Too small: unplanned work spills into planned work, meaning roadmap items slip in two or more of the last three sprints, or the buffer is empty before mid-sprint.
• Too big: less than about 60% of the buffer is used for three sprints running while planned items finish early. Release the unused part to roadmap work at mid-sprint (a pull-forward list is a short ranked list of next roadmap items, prepared in advance, ready to start).
• Track weekly: planned versus unplanned hours, buffer burn-down (how much of the buffer is left as the sprint goes on, like a fuel gauge), and the share of committed items delivered.

Step 4: Shrink the cause. If outages drive the load, fund the reliability fix as planned work; the buffer should absorb surprises, not recurring known problems.

Trade-off. A bigger buffer buys predictability at the price of visible roadmap output. What would change my call: two consecutive quarters under 15% unplanned (reduce it) or a major migration that raises incidents (raise it temporarily).

Direct answer

Treat the initiatives as a portfolio: estimate each one's expected return and its spread of outcomes, measure how much they fail together, and size each bet so a shared failure does not sink the year. Diversification helps only to the extent that failures are not correlated (they do not move together). Then fund in stages and apply a marginal rule: put the next dollar where it earns the most, taking diminishing returns into account.

1. Estimate return and risk per initiative

• Expected value (the probability-weighted average outcome) = probability of success x payoff on success, minus cost. Use ranges and a base rate (how often similar past initiatives succeeded, taken from a reference class of comparable projects), not a single hopeful number.
• Risk = how widely outcomes vary. Standard deviation is the usual number: roughly, the typical distance of an outcome from the average. A downside scenario ("what if it returns nothing") is just as useful to a non-technical audience.
• Correlation: a number from -1 to 1 for how much two bets succeed and fail together. At 0 they are unrelated; at 1 they always move together (so spreading money between them gives no protection); at 0.6 they usually do. Ask which initiatives share a failure cause (same platform migration, same team, same market assumption).

2. Worked example (illustrative, return as a multiple of money invested)

A 1.3x return means each $1 returns $1.30. Three bets:

B and C depend on the same new platform, so I assume correlation 0.6 between them; A is mostly independent (0.2 with each). Portfolio variance (the square of the portfolio's standard deviation) adds each bet's own term (weight w x its standard deviation s, squared) plus a term for every pair that grows with their correlation rho:

variance = (wA sA)^2 + (wB sB)^2 + (wC sC)^2
         + 2 wA wB sA sB rho(A,B) + 2 wA wC sA sC rho(A,C) + 2 wB wC sB sC rho(B,C)

Intuition: risk shrinks when the correlation is below 1, because bad outcomes do not line up.

Trace for weights 50/30/20 (wA = 0.5, wB = 0.3, wC = 0.2):

• Own terms: (0.5 x 0.15)^2 = 0.0056, (0.3 x 0.60)^2 = 0.0324, (0.2 x 1.60)^2 = 0.1024. Sum = 0.1404.
• Pair terms: A-B 2 x 0.5 x 0.3 x 0.15 x 0.60 x 0.2 = 0.0054; A-C 2 x 0.5 x 0.2 x 0.15 x 1.60 x 0.2 = 0.0096; B-C 2 x 0.3 x 0.2 x 0.60 x 1.60 x 0.6 = 0.0691. Sum = 0.0841.
• Variance = 0.1404 + 0.0841 = 0.2245, and its square root is 0.47.
• Expected multiple = 0.5 x 1.3 + 0.3 x 1.8 + 0.2 x 3.0 = 0.65 + 0.54 + 0.60 = 1.79.

I would pick 50/30/20 for a company that cannot afford a bad year. Make "bad year" concrete: a result two standard deviations below expected must still return at least 0.8x of the money invested. That is expected multiple minus 2 x std dev: 50/30/20 gives 1.79 - 0.94 = 0.84 (passes), while 100% B gives 0.60, 0/50/50 gives 0.38 and 20/40/40 gives 0.55 (all fail). 50/30/20 keeps almost the same expected multiple as putting everything in B (1.79 vs 1.80) at about a fifth less spread (0.47 vs 0.60). A company with deep reserves could tilt toward 20/40/40. Sensitivity: if B and C's correlation were 0, the 50/30/20 spread is 0.39; at 1.0 it is 0.52, so shared dependencies matter.

3. Deciding how much

• Diminishing returns: the first dollars on a bet earn more than later ones. Example: with 800 engineering hours, project X's first 400 hours earn $300k expected value, its next 400 only add $100k, and project Y's first 400 earn $160k. X then Y gives $460k; X twice gives $400k.
• Fund in stages so you buy information cheaply before the big money.
• Set strategic floors (a minimum for work you must do regardless of return).

Two limits on that test. First, it assumes outcomes are roughly symmetric (normal). For the moonshot alone it gives 3.0 - 2 x 1.60 = -0.2x, which is impossible because a multiple cannot go below 0, so for skewed, win-big-or-lose-it bets I would also run the downside scenario directly (what share of money is lost if the moonshot returns nothing) or simulate the outcomes. Second, the 0.8x floor is a policy choice that reflects how much reserve the company holds, not a derived number; a company with deeper reserves would set it lower and could accept 20/40/40-style weights.

Pitfalls: treating estimates as precise, ignoring shared dependencies, and funding every bet a little so nothing succeeds.

Direct answer

I treat the long-term investment as a bounded, evidence-backed ask, not a belief. I propose a capped share of capacity (as a starting range, 15 to 20%, not a rule), size it to what the problem costs the quarter's numbers today, state plainly what slips as a result, and give stakeholders an early checkpoint where they can stop it. What I bring is evidence in their units: engineer-weeks, incidents, delayed deals and churn.

Deciding how much each side gets

1. Protect real commitments first. Signed customer or revenue deliverables for the quarter come off the top.
2. Size the long-term share to the measured pain. If the problem costs the team a known number of engineer-weeks per quarter, the investment should be a fraction of that, repaid over a few quarters.
3. Cap and stage it. No more than the cap until a first milestone shows the effect, then reconsider.
4. Name the cost. List the specific quarterly items that slip, so the trade is visible and not a surprise.

What I bring to the room

• Measured cost of the problem (tickets, incident hours, deal delays), with the source.
• A payback estimate with assumptions stated.
• A staged plan with a checkpoint at four to six weeks where the work can stop.
• Leading indicators (early signals that move before revenue does), such as deployment lead time (how long a finished change takes to reach production) and incident count, so progress is visible before revenue moves.
• The honest alternative if the answer is no.

Worked example (illustrative numbers)

A team of 10 engineers has 10 x 12 = 120 engineer-weeks in a quarter. A 20% share is 24 engineer-weeks. Suppose tickets and time logs show manual deploys and incident cleanup cost 30 engineer-weeks a quarter. The investment is expected to halve that, saving 15 engineer-weeks a quarter. Payback is 24 / 15 = 1.6 quarters after it lands. If it takes the whole first quarter, savings start in the second and the work pays for itself part-way through the third (15 saved in the second quarter, the remaining 9 about 60% into the third). What stakeholders give up is 24 of 120 engineer-weeks of first-quarter feature capacity, and I say so. If I cannot produce the 30 from real data, the ask is not ready.

A variation: a sales-led deliverable that may need to scale 100 times

The same capacity question shows up when sales wants something in six weeks that might grow 100-fold in a year. I build the thin version now but pay for the few choices that are expensive to reverse later, because retrofitting them means rewriting live data and every code path that touches it. With 3 engineers for 6 weeks (18 engineer-weeks), these four cost about 3 extra engineer-weeks, roughly one sixth:

• Tenant identifiers in the data (tagging every record with which customer owns it, so customers can be separated later): about 1 engineer-week.
• Safe-to-repeat writes (making a repeated request, such as a retried payment, have the same effect as one request, so nothing is duplicated): about 1 engineer-week.
• Usage metering (counting each customer's usage for billing and capacity planning): about half an engineer-week.
• A basic load test (simulating many users at once to see where the system slows or breaks): about half an engineer-week.

Heavy scale work (splitting the database across several machines, running in multiple geographic regions) waits until demand is real, because it is costly and can be added later.

Scoring dimensions, escalation and updating the rubric

I agree weights with stakeholders before scoring anything, for example by letting each of them split 100 points across the dimensions and averaging, so the weights reflect what the business says matters this quarter. Optionality means how much the choice keeps future paths open. Each score is 1 to 5.

Example for the sales deliverable: 0.30 x 5 + 0.25 x 2 + 0.15 x 2 + 0.15 x 2 + 0.15 x 4 = 1.50 + 0.50 + 0.30 + 0.30 + 0.60 = 3.20.

The scores sit within 0.25 of each other, so I do not crown a winner. The 0.25 band is a judgment about scoring noise, not a statistical threshold. Scores are judgments good to about one point, and one point on a dimension weighted 0.25 moves the total by 0.25 (by 0.30 on near-term revenue, and by 0.15 on optionality, risk reduction or cost). Here the whole gap is 3.35 - 3.20 = 0.15, so changing the platform work's Risk reduction score from 5 to 4 alone would produce an exact tie at 3.20. A gap that small is smaller than that band, so I split capacity and treat the weights as the real argument. Escalate to the executive sponsor (the senior leader who owns the decision) when the long-term share would exceed its cap, when it would delay a committed revenue deliverable, or when scores are within that band and stakeholders still disagree. Each quarter, I compare predicted against actual (did the platform work remove the friction it claimed?) and adjust weights and confidence.

Presenting it

Product leaders hear the roadmap impact; executives hear revenue, risk and the decision needed. Both get one page: the decision, two options, the cost, and the checkpoint.

Pitfalls

• Asking for a large share with no measured cost behind it.
• Hiding what slips.
• Letting the long-term work have no stopping point, so it becomes a permanent tax.