Strategic Prioritization and Resource Allocation Questions

Direct answer

I would not promise 20% as a point estimate. I would fund five initiatives that fit inside the engineering capacity, show leadership the risk-weighted contribution of each, and say plainly that the plan lands near 15% expected with 20% reachable only if the uncertain bets land. The new-market option does not fit the capacity, so it is left out.

Illustrative setup: current revenue $50M, so 20% growth means +$10M. Engineering is fixed at 20 engineers x 46 working weeks = 920 engineer-weeks. I reserve 20% for keep-the-lights-on work (bugs, on-call, upgrades), leaving 736 engineer-weeks to invest.

How I estimate each contribution: gross revenue if it works x probability it works (my confidence, based on evidence such as a pilot or comparable launches) = risk-adjusted contribution. Then I compare it to the engineer-weeks it needs.

Totals for the five funded items: risk-adjusted $7.45M (14.9% of $50M); gross $13M if every one succeeds (26%); 560 engineer-weeks used, leaving 176 (about 24% of 736) as buffer.

Timing basis. I read each Gross $M figure as revenue booked inside the next 12 months, which already allows for build time (the premium tier needs 300 engineer-weeks, so it cannot contribute a full year if it ships mid-year). If a figure is an annualized run rate instead, only the part booked inside the year counts toward the 20%, and the 14.9% forecast falls.

Chance of the stretch. Treating the five outcomes as independent, the chance that the five funded items together reach the $10M needed is about 24%, and the chance they reach the $7.45M expected figure is about 52%, so 20% is roughly a one-in-four outcome, not something to plan on.

Why the new market is left out: it would need 400 more engineer-weeks (960 total, over the 736 available) for 0.9 of risk-adjusted value, the worst return per engineer-week. Even adding it would reach 8.35, or 16.7%, not 20%.

What I tell the CFO: commit to about 15% with a stretch to 20%, because the gap to $10M is $2.55M and no honest combination of the available engineering closes it. To close it faster, the lever is not engineering: sales capacity, pricing discipline or partner revenue that needs little code. I would also check that pricing and the sales-side items are not double-counting the same customers.

How I decide what to leave out: value per engineer-week, probability, and whether the item blocks others. I revisit quarterly. I also checked the swap: dropping the premium tier to fit the new market (560 - 300 + 400 = 660 engineer-weeks) gives only 6.35 risk-adjusted, worse than 7.45. A better pricing result raises the forecast but frees no engineering, so the new-market item is reconsidered only if capacity opens up, for example a cut-down pilot version of 176 engineer-weeks or less, or a partner building part of it.

Direct answer

I would give teams their own base headcount (the number of people on each team) and budget, and keep a small central reserve that leadership allocates each quarter. Team-held capacity gives ownership and continuity (the same people keep knowing the same system); the reserve gives the company a way to move people when strategy shifts without a reorganization. I would switch toward a central pool if the company's priorities change faster than teams can adapt.

How to decide: evidence from last year

Applying it (illustrative): a 120-engineer company where last year the payments, search and onboarding teams kept the same missions, only one team's priorities changed mid-year, and teams rarely shared work. Three of the four rows point to team-held (the scenario does not say whether leadership can see the work well, so the fourth row is unknown and I would check it), so I choose team-held plus a reserve. If instead the same company had changed priorities three times mid-year and half its work crossed teams, the table would point to a central pool.

Worked example (illustrative): 120 engineers: 10% reserve is 12 people held centrally; 108 sit in teams. In January a compliance deadline needs 5 engineers for two quarters and search needs 4 for a launch. The reserve covers both (9 of 12), leaving 3 for emergencies, and no team is reorganized.

The cost of moving people. A lent engineer is not free: they spend weeks learning the borrowing team's code (Brooks's law, from The Mythical Man-Month, 1975, says adding manpower to a late software project makes it later, from ramp-up time and communication overhead; Brooks himself called it an oversimplification, and it concerns projects that are already late, so a planned loan is a milder version of the same cost, not an instance of the law), and the lending team loses context. So I lend for a whole quarter or more, never for a few weeks, prefer people who already know the system, and count roughly the first month of a loan as partly lost output when comparing options. In the January example the 9 engineers on loan would deliver less than 9 engineers' worth in the first quarter. The borrowing team's budget bears the ramp-up cost, which discourages casual requests.

Problems to expect under my choice (team-held plus reserve)

• Hoarding (teams keep spare people as a private cushion): measure utilization, meaning the share of each team's capacity spent on its planned priorities, and publish it by team each quarter.
• Uneven teams: some overstaffed. Rebalance yearly using the reserve: if a team of 14 needs only 10 for its roadmap, 4 move into the reserve, and from there are lent to teams that are short.
• Local optimization (each team doing what is best for itself, not the company): tie the reserve to company goals.
• Reserve politics: set criteria and a decision date.

Problems under a pure central pool: slow decisions, constant lobbying, and loss of team continuity.

What would make me change it

• Toward central: for example two or more consecutive quarters where important priorities cannot be staffed, or heavy duplicated work across teams.
• Toward more team ownership: allocation decisions taking longer than a planning cycle, or teams spending a noticeable share of every quarter (say more than a few weeks) lobbying for people.

The 10% is a starting assumption to tune against data.

Direct answer

Use a short written scorecard that every large bet (a new vertical, product line or market) must pass through, with weighted criteria, a minimum bar on the criteria that sink bets, and pre-agreed score bands. The bands separate a full go from a pilot from a no-go, so the debate is about the evidence, not the personality of the sponsor.

Criteria and weights (adjust to your company, these are illustrative)

Weights sum to 1.00. Score each 1 to 5 against written anchors (for example, "right to win = 4: three customers in the segment have said they would switch").

Decision bands

• Full go: weighted score at least 3.80, right to win at least 4, execution readiness at least 3.
• Pilot: weighted score 3.00 to 3.79, or a high score failing one gate. The pilot has a spend cap, a time box and numeric exit criteria written beforehand.
• No-go: below 3.00, or right to win of 2 or lower.

Worked example (a hypothetical healthcare vertical)

Scores 4, 3, 4, 3, 2, 4 give 0.8 + 0.75 + 0.6 + 0.6 + 0.2 + 0.4 = 3.35. That is a pilot: the market is real but right to win and readiness are weak. The pilot runs two quarters with, say, five design partners, and succeeds if at least three sign paid contracts. If the pilot lifts right to win to 4 and readiness to 4, the score becomes 3.80 and the bet moves to full go.

Making it repeatable: score independently by two reviewers, record the evidence, rescore at each stage, and track which scores were later proven right.

Pitfalls: false precision (a 3.34 vs 3.36 difference means nothing), sponsor-inflated scores, and weights that quietly encode the answer someone wanted.

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.

Explaining it simply

Opportunity cost is not what a project costs; it is the value of the best thing you gave up by choosing something else. To the sponsor I would say: "We have a limited number of engineers, so funding another project meant your project did not get built. What we gave up is the net value your project would have created (its benefit after its cost). Because the project we funded creates more net value than yours would have, the company is better off, even though your team lost."

How I would roughly quantify it (four steps)

1. State both options' cost in the same unit (engineer-months, then dollars).
2. Estimate each option's yearly benefit and your confidence in it.
3. Risk-adjust (shrink the benefit by the chance it does not happen): benefit x probability, minus cost. That result is the net value.
4. The opportunity cost of funding one project is the net value of the next-best option forgone. Compare it with the net value of what you funded to see the gain from choosing.

Worked example (illustrative, both need 6 engineer-months, $150k at $25k each)

• Dashboard project (the sponsor's): saves analysts $240k a year, 80% confident. Net = 0.8 x 240k - 150k = $42k.
• Churn-analytics project (funded): protects $600k of margin a year (margin is revenue minus the direct cost of delivering it), 50% confident. Net = 0.5 x 600k - 150k = $150k.

Opportunity cost of funding churn analytics: $42k, the dashboard's net value, which is what the company gave up. The company gains 150k - 42k = $108k more by choosing churn analytics than it would have by choosing the dashboard. So the company gave up $42k but gained $150k; the sponsor's team lost a real $42k of value, but the company as a whole is $108k better off.

Opportunity cost vs direct cost

Direct cost is cash or time spent on the item. Opportunity cost includes what that same cash or time would otherwise do. Example: a customer asked for a one-off feature worth $40k in revenue that "only" cost two engineers' time for 3 months, already on payroll. Direct cost looked free. The 6 engineer-months (about $150k at $25k each) could instead go to a platform upgrade that protects renewals from three customers worth $80k each, $240k in total, so declining the one-off was correct.

Caveat: the estimates are rough. Say so and show the range. Sunk costs (money or time already spent that cannot be recovered, such as the two weeks the sponsor's team already spent on a prototype) should not drive the comparison, because they are the same whichever project you fund.

Basis and horizon. The comparison above is a one-year view: each project's yearly benefit against its one-off build cost. If a benefit lasts several years the gap can widen or flip, so state the horizon you used. The renewals example should use the same method: if the platform upgrade has a 90% chance of saving the three renewals, its net is 0.9 x 240k - 150k = $66k, while the one-off feature, even if certain, nets 40k - 150k = -$110k. The ranking holds on the same basis.