Prioritization and Trade-Off Decisions Questions

Short answer

I would let each team decide as much as possible, set a few clear thresholds that decide where a choice is made, ask for a one-page input only when a decision crosses a team boundary, and review on a fixed rhythm instead of ad hoc meetings. The test of "not bureaucracy" is that most decisions are made quickly at the lowest level.

Decision rights (illustrative thresholds)

Decision rights means who is allowed to make which call. 12 teams across 4 product lines is 3 teams per line.

Each tier has one named decider so a tie cannot stall: the team's product manager at team level, the line head at the council (the three team leads advise), and at the cross-line forum one chair, for example the head of product, who decides after hearing the four line heads and records the reasons. A forum that can only vote can deadlock two to two; a chair cannot.

One decision traced through the tiers

Take a team of 5 engineers over a 13-week quarter: 5 x 13 = 65 person-weeks, so the 20% threshold is 13 person-weeks.

• Fixing onboarding copy takes 8 person-weeks (about 12% of the quarter) and touches no other team. The team decides alone, same day.
• Building a data export feature takes 20 person-weeks (about 31%). That is over the threshold, so the team writes the one-page brief and the product-line council decides, typically within a week.
• A third item needs the shared platform team, which another line also wants. Two lines compete for the same people, so it goes to the cross-line forum.

Required inputs (kept small)

A one-page brief only for items above the team threshold or that cross a team boundary: the problem, options, estimated effort, expected benefit with confidence, and the cost of waiting. A shared scoring rubric helps comparison but is a guide, not a formula that decides.

Cadence

Quarterly planning for allocations, a monthly product-line review, and a fast lane for urgent items decided within a few days. Meetings have a written agenda of decisions needed; if there is none, cancel.

Guards against bureaucracy

• Default to the team; the burden of proof is on pulling a decision up.
• Time limits on every escalation.
• Review the process itself twice a year and remove steps nobody uses.
• Require written input only above the thresholds.

Adherence metrics

Start with three: median days from request to decision, share of decisions made at the team tier, and reversal rate (the share of decisions undone within a quarter, a sign they were made on weak information). As an illustration, a healthy median is a few days and a majority of decisions at the team tier; a median of weeks, or most decisions climbing to the forum, signals bureaucracy. Add the rest once the first three are trusted:

• Share of roadmap changes with a written record.
• Share of capacity lost to unplanned interrupts.
• A pulse survey (a few quick questions every quarter, for example "how much time does process cost you?").

I would track outcomes as well as compliance, because a team can follow every step and still decide badly.

Other situations

• Tiered councils: as above; do not add a tier unless the one below is overloaded.
• Executive reporting: executives do not join individual decisions. They get one shared, read-only dashboard of the same few measures (decision time, capacity use, outcomes), reviewed quarterly, which gives them visibility without making them a decision body.
• 50 teams: at the same ratio that is 50 / 3 = about 17 product lines, too many for one forum. Add a division tier, roughly four divisions of four or five lines each, and keep each forum small enough to decide.

Direct answer. Agree the criteria, their weights, and the definition of each score before anyone sees the options. A good rubric is short, has anchored scales, and is signed off by decision makers in advance, so the meeting debates evidence, not rules.

What a good rubric contains.

1. A handful of criteria (4 to 6) tied to the company goals and strategy.
2. Weights that sum to 100%, set before scoring.
3. A scale with written anchors, for example 1 means no evidence, 5 means validated by data.
4. An explicit owner for each score and a note of the evidence behind it.
5. A rule for ties and close calls.

Example (illustrative).

Weights sum to 100. Weighted score = sum of weight x score / 100. A: (30x4 + 25x3 + 20x4 + 15x2 + 10x5) / 100 = 355 / 100 = 3.55. B: (30x3 + 25x5 + 20x2 + 15x4 + 10x3) / 100 = 345 / 100 = 3.45.

The 0.10 gap on a 1 to 5 scale is within the noise of subjective scoring, so treat it as a tie and discuss the one assumption that decides it, for example whether A's weak evidence (score 2) can be raised cheaply.

Making it work.

• Share the rubric before the review so people bring evidence.
• Score independently first, then compare, to avoid anchoring on the loudest voice.
• Keep it as an aid, not an oracle; record the decision and what would change it.
• Include a vision or strategy-fit criterion so the rubric points the same way as long-term direction.

Pitfall. Changing weights after you see the scores is the main failure; it turns the rubric into a justification tool.

Direct answer. Decide by the outcome you care about downstream, per visitor who starts onboarding, and test it. If a longer flow keeps more users even though sign-ups fall, the signup metric is the wrong target. Explain it as one funnel, not as one metric winning.

Worked example (illustrative). Out of 100 visitors who begin:

• Short flow: 60% finish and 20% of those are still active at 30 days. 100 x 0.6 x 0.2 = 12 retained.
• Long flow: 50% finish and 30% of those stay. 100 x 0.5 x 0.3 = 15 retained.

Signups fall by 10 per 100, but retained users rise by 3. The break-even retention for the long flow is 0.6 x 0.2 / 0.5 = 0.24, so it wins if its retention beats 24%.

Where the 0.24 comes from. Short flow: 100 x 0.6 x 0.2 = 12 retained. For the long flow to match that, 100 x 0.5 x r must equal 12, so r = 12 / 50 = 0.24. Above 24% retention it wins; below, it loses. Here its 30% clears the bar.

Simple two-direction matrix. "Payback" means the extra users kept later must make up for what the change costs now. A guardrail is a second metric you watch so a win on the main metric cannot hide damage elsewhere.

How to decide.

1. Run an A/B test and compare retained users per visitor started, not retention among finishers, since the long flow filters out low-intent users and that flatters its rate.
2. Set a guardrail (a second metric watched alongside the main one) on completion and on drop-off at the longest step.
3. Look for a middle path: keep the long flow's valuable steps but let people skip or defer them.

Communicating. Say: "Signups will drop, and that is expected. We are measuring retained users, which is what drives revenue." Show the trade in one chart, and ask leadership to agree the success metric before launch so the dip is not a surprise.

Direct answer. I pulled six weeks of planned feature work out of the quarter to fund a platform fix, because the platform problem was quietly taxing every feature after it. I made the case in the team's own currency (delivery speed and incident cost), named what we gave up, and checked the result against a prediction I wrote down beforehand. The story below is a representative shape, with illustrative numbers.

Situation. Our deploy pipeline and a shared service had become fragile (platform work means the internal systems other teams build on, such as build pipelines, shared services and tooling). Last quarter 8 of our 24 releases needed a manual rollback (one in three), and 6 engineers each spent about a day per week on firefighting. The roadmap had four customer features queued: bulk CSV import, saved filters, a billing export, and a partner integration.

Making the case.

• Quantified the tax: incident hours plus the delay on every feature, converted into engineer-weeks (for example 6 engineers x 1 day per week lost = 6 days, about 1.2 engineer-weeks per week of calendar time).
• Showed the compounding effect (the loss grows because each new feature adds to the fragile base): if nothing changed, next quarter's feature capacity would shrink further, so deferring only moved the cost. At 1.2 engineer-weeks lost per calendar week, a 13-week quarter loses about 15.6 engineer-weeks (13 x 1.2) to firefighting alone, and that is the figure the six-week fix was weighed against.
• Proposed a bounded fix: 6 weeks of work with a stated exit criterion (a measurable condition agreed in advance that says the work is done and stops it: rollbacks below one release in ten, no pages for the pipeline), not an open-ended rewrite.
• Pre-wired the people who would lose: I took the sales lead through which two features slipped and offered a dated commitment for each.

What we gave up. The saved-filters feature moved to the following quarter, and the customer-requested partner integration got a "not this quarter" with a firm date. I said that out loud rather than hiding it.

Outcome vs expectation. I had written the prediction down: rollbacks halve, firefighting time drops by about half. Rollbacks fell from 8 of 24 releases to 3 of 27 (about 11%, just short of the one-in-ten exit criterion). Firefighting fell from about 6 engineer-days a week to about 4, a third rather than a half, because a second flaky dependency surfaced. Measured against the prediction I wrote down, halving the rollback rate would have meant about 4 of 24 releases (17%), so the 11% result beat the prediction, while the firefighting target was missed. The exit criterion I had set (below one release in ten) was stricter than the prediction, which is why 11% still counted as just short. Both deferred features shipped on the dates I promised.

What I would do differently. Scope an audit of dependencies before sizing the fix, and bring the sales lead in earlier. The lesson: platform work wins arguments when it is expressed as lost feature capacity with an exit criterion, never as "tech debt is bad" (technical debt means shortcuts that make future changes slower or riskier).

Decide the split with a reliability budget, not a feeling. An SLO (service level objective) is a target such as 99.9% of requests succeeding. The error budget is the unreliability it allows. Google's SRE book defines it as the gap between the SLO and measured uptime, and says releases can continue while the SLOs are met and are temporarily halted when frequent violations spend the budget. Google's example error budget policy goes further: when a service exhausts its budget over a four-week window, teams halt changes other than P0 issues (the most severe, drop-everything incidents) or security fixes until it is back within the SLO, and disagreements about it escalate to the CTO.

Worked example (illustrative). A 99.9% SLO over a 90-day quarter allows 90 x 24 x 60 x 0.001 = 129.6 minutes of failure. That is the error budget, measured in minutes of downtime. A team of 10 has 10 x 13 = 130 engineer-weeks of capacity in the quarter. These are two separate quantities (minutes of failure allowed, and engineer time available): the budget tells you WHEN to move the split, the capacity tells you WHAT moving it costs.

• Default split: 20% reliability (26 engineer-weeks), 80% features. This is a starting point to tune: it keeps feature delivery dominant while funding steady maintenance.
• Trigger: less than 25% of the budget remaining (under 32.4 of the 129.6 minutes), or a repeat incident (the same root cause causing a second outage), or a burn rate well above 1 (a threshold I would tune, for example 1.5) because that projects exhaustion before the quarter ends even while plenty of budget remains. A quarter left leaves time to react before the budget hits zero. Then move to 40% reliability (52 engineer-weeks).
• Budget exhausted: freeze feature releases except urgent fixes until reliability work restores it.

Burn rate is how fast the budget is being spent relative to the time passing. Example: 40 minutes of failure in the first 15 days of the 90 uses 40 / 129.6 = 31% of the budget in 17% of the quarter, a burn rate of about 1.9 (spending nearly twice as fast as the budget allows). At that pace the budget runs out around day 49 (129.6 / (40/15) = 48.6 days), so it is a signal to move to 40% now, even though 89.6 minutes (69%) of the budget remains and the 25% remaining-budget trigger has not fired: that is why burn rate is a trigger of its own and not only a piece of evidence.

Evidence that moves the split: burn rate, repeat-incident count, on-call hours per week (on-call is the rotation of engineers who respond to alerts), customer-visible impact (tickets, churn at risk), and the cost of the incident backlog.

Showing non-engineers. One chart, plus a two-line trade. The chart: a line of budget remaining from 129.6 minutes at day 0, falling to 89.6 at day 15, with a horizontal line at 32.4 marking the 25% trigger. The trade: "Moving 20% to 40% takes 26 more engineer-weeks, which pushes feature X (about 14 engineer-weeks) and feature Y (about 12) to next quarter, and cuts expected downtime." Those two feature sizes are illustrative; the 26 is the arithmetic: 52 - 26.

The same method in other situations.

• Fragile ETL (extract-transform-load, the pipeline that copies and reshapes data) vs a churn dashboard: if the dashboard reads the fragile pipeline, fix the pipeline first since the dashboard would be wrong.
• Automation vs incident backlog: 5 incidents a month at 2 hours is 10 hours a month, 120 hours a year; automation costing 3 engineer-weeks (120 hours at 40 hours per week) pays back in about a year. The incident fix that removes the repeating cause ranks ahead: it stops the incidents (and the customer impact) entirely, while automation only makes handling them cheaper.
• Network incident vs project work: the budget does not care about the cause. Say a network outage burns 45 minutes of the 129.6; that is 35% of the budget, the remaining budget falls to 84.6 minutes, and the same rules apply as for a code bug.

What flips it: a launch tied to revenue where the budget is healthy.