Strategic Prioritization and Resource Allocation Questions

Direct answer

I would not split the difference between 40 and 60 by negotiation. I size the platform work to the drag it measurably puts on feature delivery, require each platform item to name the outcome it will change, and set a time-boxed split with a data review. For a 10-person team I would start at 30% platform and 70% features for two quarters and review after six weeks. The disagreement is settled by agreeing the measures first, then letting one named person break ties. (Platform work is internal engineering investment such as build pipelines, deployment tooling and reliability, as opposed to features customers see.)

How I decide the split

1. Measure the drag. Lead time for a change (how long a finished change takes to reach customers), build and test time, share of time spent on unplanned work (urgent bugs and incidents that interrupt planned work), and incident hours.
2. Convert it to engineer-weeks lost, so it can be compared with feature work in the same unit.
3. Size the platform share to that drag plus any named non-negotiables (security, reliability obligations).
4. Time-box and review, because the split should respond to evidence.

Worked example (illustrative numbers)

10 engineers x 12 weeks = 120 engineer-weeks a quarter.

Suppose the team measures about 20% of its time lost to slow builds, flaky tests and manual deploys: 0.20 x 120 = 24 engineer-weeks a quarter. Platform items for the 36: faster builds 12, deploy automation 10, flaky-test cleanup 6 (flaky tests are tests that fail at random and waste reruns) which is 28 aimed at the drag, and incident-driven reliability 8 (12 + 10 + 6 + 8 = 36). The 28 is above the 24 because 24 is the loss every quarter while 28 is the one-time cost of removing it: if the fixes work, the 28 is earned back in about 28 / 24 = 1.2 quarters, and the capacity keeps coming back after that. The 8 covers a reliability obligation the drag figure does not capture. A 40% share (48) is double the measured drag, so the 12 engineer-weeks beyond my 36 need their own named outcome. If the team can name one, I move toward 40%.

What the platform work is held accountable for

• Lead time for changes and build time, each against a baseline taken before the work starts.
• Change failure rate (the share of deployments that need immediate intervention, such as a rollback or a hotfix) and failed deployment recovery time (how long it takes to recover from a deployment that fails; DORA's earlier name for this measure was time to restore service). Cycle time, the time from starting a work item to finishing it, should fall as well.
• Share of the sprint spent on unplanned work.
• Feature items that were waiting on the platform and then shipped.

A weekly view of these, next to features delivered, shows quickly whether the platform share is paying off.

Settling the disagreement

1. Agree the problem statement and the measures first, before arguing about percentages.
2. Treat the split as an experiment with a review date.
3. Name one decider (the product and engineering leads jointly, with their shared manager as tiebreaker within a day).
4. Once decided, both sides commit and report against the same dashboard.

Related situations

Pitfalls

• Treating the split as a permanent ratio instead of a decision with a review date.
• Platform items with no named outcome ("improve tooling").
• Counting only platform cost and not the feature capacity it returns.

Direct answer

I would set funding in envelopes from the bottom up: core first (committed run cost plus its plan), then adjacent bets, then an experiment pool capped at an amount we could lose entirely. Each experiment earns money in stages by showing evidence at defined gates, and I rebalance every quarter, returning unspent money to the pool and moving graduating bets into the adjacent envelope.

Terms. An envelope is a fixed pot of money a group may spend freely without asking for each item. Core product is the business that pays the bills today. An adjacent product is a newer line near the core (same customers or same technology) that has some traction but is not yet proven. A bet that graduates has passed its last gate and moves to the adjacent envelope.

Illustrative envelopes (made up): a $30M budget.

Where the numbers come from (bottom up): core is $15M of committed run cost (people, hosting, support) plus $4.5M of planned improvements, so $19.5M. Adjacent is three products at about $2.5M each, $7.5M. Experiments get what the company could lose entirely without harm, here $3.0M. The percentages are the result of that sizing, not the starting rule, and they would change if the core needed more to protect revenue or the business could absorb more risk.

Stage-gated funding (releasing money in steps as evidence arrives)

• Gate 1, seed ($250k, about 8 weeks): evidence that customers have the problem, such as signed pilot commitments.
• Gate 2 ($500k more): retention (the share of pilot users who keep coming back) and usage in a real pilot.
• Gate 3 (moves to adjacent funding): unit economics (profit per customer after the cost of winning and serving them) clear a ceiling. Payback is the months needed to earn back the cost of acquiring a customer. Example: acquisition cost $3,000 and gross profit $200 a month gives payback of 15 months, inside an 18-month ceiling (illustrative).

The $3.0M pool therefore covers 6 seeds x $250k = $1.5M plus 3 follow-ons x $500k = $1.5M (so half the seeds are expected to pass Gate 1).

Decision rights and cadence

• Product owners spend freely inside their envelope; the portfolio council (a small group of senior leaders from product, engineering and finance) meets quarterly to move more than about 10% between envelopes.
• Contention for shared engineers resolves in order: core commitments, bets that passed a gate, then others; unresolved after two weeks escalates.
• Exceptions to the payback ceiling need a written case, executive approval and an expiry date.
• The same tiers apply to a research portfolio: strategic bets, incremental work and time-boxed investigations of technical debt (shortcuts in the code that make future work slower) inside core capacity. Mapped to the envelopes: strategic bets are the experiment pool, incremental work is the adjacent envelope, and the technical-debt investigations are a small time-boxed line inside the core envelope.

Rebalancing: a bet that misses a gate is stopped with its money freed; a bet that passes keeps funding and may be released more money from the unspent balance of the experiment pool; the core envelope changes only with evidence it can absorb it.

A graduating bet needs a line in the adjacent envelope, which is already fully committed ($7.5M across three products), so the council funds it in this order: the unspent experiment-pool balance first, then the budget of the weakest adjacent product if that product has missed its own gates, then a transfer from core approved on evidence. None of these is automatic, which keeps the envelopes honest.

Pitfalls: funding bets as annual entitlements, letting the core starve experiments, and judging bets by the core's metrics.

Decision: cut in tiers by return and reversibility, protect what drives growth, and make the trade-offs visible to all stakeholders.

1. Set the target in dollars. Assume (illustrative) $40M annual operating expenses. A 10% cut is $4M of run-rate savings (the yearly rate of saving once the cuts are fully in place, i.e. annualised).

Accelerate the few programs with clear short payback: for example, a billing fix that costs $0.2M and recovers an illustrative $0.6M a year of failed payments gets more money, not less.

2. How to choose. Score each cut from 1 to 5 on three things, where for every column 5 means safe to cut: little return lost, little strategic fit lost, and easy to reverse (a pause you can restart is cheaper than a cut you cannot). The highest total goes first. Illustration: the backfill freeze scores return lost 4, fit lost 3, reversibility 4 (total 11) and goes first; cutting the customer-retention team scores 1, 1, 1 (total 3, because it would lose a lot of return and fit and is hard to rebuild) and stays off the list. Data: spend by program, return per channel, cost of restarting. Process: finance and function heads review one list together, with one owner for the call.

3. Short-term savings vs long-term damage. Cutting hiring or R&D saves quickly but harms for years. Prefer reversible pauses to irreversible cuts, and protect customer retention and security.

4. If the cut is phased: 15% over six months. 15% of $40M is $6M a year, or $0.5M a month at full run-rate. Ramping evenly means month 1 saves 1/6 of that, month 2 saves 2/6, up to month 6 at the full amount:

months 1 to 6: 0.5 x (1 + 2 + 3 + 4 + 5 + 6) / 6 = 0.5 x 21 / 6 = $1.75M
months 7 to 12: 6 x $0.5M = $3.0M
first 12 months: 1.75 + 3.0 = $4.75M, not $6M

The run-rate says $6M, but the money actually saved in the year is $4.75M. Count the in-year effect. The same timing applies to the 10% plan above: a backfill freeze only saves as people leave, so the $4.0M is a run-rate and the in-quarter saving is smaller. The $0.2M spent on the billing fix is also spent first, so the plan nets about $3.8M of run-rate before the $0.6M a year it recovers.

Direct answer

Treat the DBA's (database administrator's) week as a budget. Reserve a slice for shared work and emergencies, divide the rest by a published weighting of each team's SLA (service-level agreement, the response and availability promise) and business impact, settle urgent clashes with a fixed severity rule, and check fairness with hours and wait-time data each month.

Dividing the time (illustrative)

A 40-hour week: reserve 10 hours (25%) for shared health work (backups, patching, on-call interrupts, the upkeep that keeps every team's database running); allocate 30 hours using weights built from SLA tier and revenue exposure.

How a weight is built: SLA points (2 for a strict SLA such as minutes-level response, 1 for a standard one) plus revenue-exposure points (2 if an outage stops sales, 1 if it slows a revenue process, 0 if internal only).

Weights total 10, so 30 x 4/10 = 12, and so on; the hours sum to 30. The points are published so a team can argue with an input, not with the outcome.

When two teams both have an urgent need

1. Severity rule first (a written ranking): customer-facing outage, then revenue risk, then internal.
2. If tied, the stricter SLA tier goes first.
3. The other team gets a stated ETA and a runbook (a step-by-step guide) for a safe workaround, and the lost hours are repaid the following week.
4. If still tied, the DBA's manager decides within minutes, not the teams.

Is it fair and working? Check weekly hours worked versus allocation, request wait time per team, SLA breaches, and a quarterly review of weights with the team leads.

Reducing the dependency: runbooks, self-service for routine tasks, and a trained backup.

The same logic applies to specialist solutions-architect time (a pre-sales technical expert shared across sales deals): give high-touch hours to opportunities by expected value (value x chance of winning) per specialist hour. Example: $400k at 40% win is $160k over 20 hours = $8k/hour; $150k at 70% is $105k over 10 hours = $10.5k/hour, so the second goes first.

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.