Prioritization and Trade-Off Decisions Questions

Direct answer. Put security and features into one currency (the same unit, so they can be ranked side by side): expected dollars protected or unlocked per engineer-week. Score both the same way, ring-fence a baseline of capacity for non-negotiable items (regulation, contractual), and let the rest compete on that number. Present it to leaders as revenue at risk and revenue unlocked, not as "best practice".

Terms. Annualized loss expectancy (ALE) is how much loss you expect per year from one risk: ALE = annual rate of occurrence x single loss expectancy. The annual rate of occurrence is how often per year you expect the event (10% means about once in ten years). The single loss expectancy is the dollar cost each time it happens. So 10% x $1.2M = $120k expected loss per year. Expected value is the probability-weighted average of outcomes. A threat is what could go wrong, a control is the fix that reduces it, and ring-fencing means reserving capacity that other work cannot take. Frameworks such as FAIR (Factor Analysis of Information Risk) break the same estimate into event frequency and loss magnitude, which is useful when leaders push back on a single guess.

Process.

1. List candidate security investments with a threat, a control and a cost in engineer-weeks.
2. For each, estimate event probability and loss before and after, and the reduction.
3. Add revenue effects: deals blocked by missing certifications, weighted by win probability.
4. Rank by expected value per engineer-week, next to feature work on the same scale.
5. Treat regulatory deadlines as fixed constraints funded first.
6. Reserve a standing slice of capacity for security and re-justify it each year.

Worked example (all figures illustrative; ranges would be shown in practice):

With 23 engineer-weeks of security capacity the first three fit (3 + 14 + 6) and log retention waits. The feature outranks log retention, showing security does not always win.

Basis check. The two loss rows are annual expected losses avoided, which recur every year the control stays in place, while the certification and feature rows are one-time expected revenue. On an illustrative three-year view (controls keep working, revenue counted once) the per-week figures become $108,000 for the injection fix (3 x $108k / 3 weeks), $75,000 for multi-factor login, $32,143 for the certification, $15,000 for the feature and $12,000 for log retention. Multi-factor login then moves above the certification, but the same three security items are funded and the feature still outranks log retention, so the decision holds on either basis. State the basis in the table header so a leader cannot read an annual figure and a one-time figure as the same kind of number.

Communicating. Say: "These three items are worth about $708k of expected value for 23 engineer-weeks: $258k a year of expected loss avoided, plus $450k of expected pipeline revenue that arrives once, before cost of delivery; the feature brings $150k for 10." Show ranges and the assumption that would flip each call.

Pitfalls. Treating guessed probabilities as precise, and counting an expected loss as a cash saving.

Direct answer. Replace lobbying with a standing, quarterly intake process that ranks every request on one shared rubric against one shared capacity number, with a named person holding the tie-break. I would give the final say to the executive accountable for the whole portfolio (for example, the chief product officer or the general manager), with the engineering manager owning capacity truth.

The process.

1. One intake and one currency. Every ask is written in a standard template with the problem, evidence, owner, and estimate in person-weeks.
2. Capacity first. Example: 10 engineers x 13 weeks = 130 person-weeks. Reserve 20% (26) for reliability, maintenance and infrastructure, so 104 remain for product work.
3. Visible gap. Illustrative asks: 70 + 60 + 50 = 180 person-weeks against 104. The 76 person-week shortfall is what the group must trade.
4. Scoring. A cross-functional review applies the same rubric (customer impact, revenue or cost, strategic fit, evidence, effort) to all asks. Product leads present; engineering challenges estimates.
5. Decision and publication. The accountable executive signs the split, for example 44 / 36 / 24 = 104, and publishes it with reasons and the work that did not make it.
6. Cadence. Re-review quarterly or on a defined trigger; mid-quarter additions require something to be dropped.

Where 44 / 36 / 24 comes from (illustrative). Score each request item with the rubric (1 to 5 per criterion, weights 30% impact, 25% revenue or cost, 20% fit, 15% evidence, 10% effort where 5 means cheap). Example: impact 5, revenue 5, fit 5, evidence 4, effort 3 gives 1.5 + 1.25 + 1.0 + 0.6 + 0.3 = 4.65. Then fund items from the top score down until the 104 weeks run out:

Product A funded 24 + 20 = 44, B 20 + 16 = 36, C 16 + 8 = 24, total 104. A asked for 70, B for 60, C for 50 (the 180 total), so the split follows the scores, not the size of the asks. A sample intake line: "Problem: checkout drop-off; Evidence: 3,000 abandoned carts last month; Owner: A lead; Estimate: 24 person-weeks."

Who decides. The product leads advise; the executive owner decides, and escalation stops there. The engineering manager does not pick winners but states what is feasible.

Common variations on the same setup. (A tie-break is the final call when scores are close; capacity truth is the honest number of weeks the team has; a currency is the single shared unit, here person-weeks.)

• When Sales, Product and Finance repeatedly conflict: Sales brings revenue evidence, Finance the cost view, Product the strategy fit; all feed the same rubric.
• Regional teams: use the same rubric, with a reserved slice for local needs (for example about 10% of the 104 weeks, roughly 10 person-weeks, for regional requests).
• When product work competes with infrastructure work: the 20% reserve makes it a standing allowance; anything above it competes in the rubric.
• When design time is shared across roadmaps: same process, counted in design person-weeks (for example 6 designers x 13 weeks = 78 design weeks to allocate the same way).

Pitfall. Without a tie-break owner and a published outcome, the process degrades into repeated negotiation.

Direct answer. Treat C as a prerequisite to B, so the real choice is when to do C and whether A goes before or after B. I would do C first (it is cheap and blocks B), then pick between A and B by value per unit of effort. A dependency makes you do the lower-value item first when it is cheap and gates something big, or when the dependent item sits on the critical path (the longest chain of dependent tasks, which sets the earliest finish).

Setup. The facts give values but no efforts, so I assume illustrative efforts in sprints: A 3, B 4, C 1. The conclusion depends on these assumed numbers, which is why I would ask for real estimates first (the threshold below shows how much they matter). Value is "per sprint once live", over a 12-sprint horizon, and I count C's 5 as internal value (reliability, cost) even though customers do not see it. A schedule's score is the sum of value x sprints live.

Value per effort. Dividing value by duration is the idea behind WSJF (Weighted Shortest Job First, a method from SAFe that does the shortest, highest-value jobs first; the full version also adds cost-of-delay terms, and RICE-style scores are its close relatives). Here: A: 8 / 3 = 2.67. B: 10 / 4 = 2.5. C: 5 / 1 = 5.0. C also unblocks B, so it goes first. Between A and B, A is higher.

Check by schedule (finish sprint in brackets).

• C, A, B: C 5 x (12-1) = 55, A 8 x (12-4) = 64, B 10 x (12-8) = 40. Total 159.
• C, B, A: 55 + B 10 x (12-5) = 70 + A 8 x (12-8) = 32. Total 157.
• A, C, B: A 8 x 9 = 72, C 5 x (12-4) = 40, B 10 x 4 = 40. Total 152.
  So C, A, B wins, narrowly.

What would flip it. If A needed 5 sprints, its ratio is 8 / 5 = 1.6 and C, B, A scores 141 against 123 for C, A, B. A goes first only while its effort is below 3.2 sprints (8 / e > 2.5). Always state that threshold: the ranking is only as good as the effort estimate.

Cross-team and shared-team releases. For a release with cross-team dependencies, map each task, mark the longest chain and protect it: slack on other items is free, delay on the critical path delays the release. Small example: Team X builds the API (4 weeks), then Team Y builds the screen on it (3 weeks), while Team Z writes docs (2 weeks) in parallel. The chain X then Y is 7 weeks and sets the release date; the docs have 5 weeks of slack, so a slip in docs costs nothing but a slip in the API moves the date week for week. When three initiatives all need one dependent team, that team is the constraint (the one resource that limits total output), so sequence by the same ratio on that team's time, agree the order with them in writing, and do not start the others in parallel.

Pitfall. Do not rank C last because it is invisible. Invisible enablers are exactly what dependency analysis exists to surface.

Direct answer. Convert each weakness into expected dollars lost per year, divide by the cost to fix it, and fund in that order within a stated capacity. Everything is reduced to three inputs engineers can check (incidents, impact, fix time) and one output finance understands (expected loss avoided per dollar of fix cost).

Terms. Technical debt is shortcuts or weaknesses in the code or systems that make failures and future work more costly. Fan-out is how many other teams or services depend on a component. Expected loss is probability-weighted cost.

Scoring

annual expected loss = incidents per year x hours down per incident x cost per hour
fix cost = engineer-weeks x cost per engineer-week
priority = annual expected loss / fix cost

The formula assumes a fix removes the whole expected loss and that the loss would otherwise recur at the same rate, so priority is a first-year ratio. When a fix removes only a share, multiply the loss by that share first: if the payments-queue rework removed 70% of its incidents, 0.7 x $180,000 = $126,000 and the priority would be 126,000 / 24,000 = 5.25, still above the auth library's 3.0, so the order below holds. Fan-out goes into the cost per hour, since an outage in a shared component costs every dependent team. For the shared auth library, assume each of its 12 dependent teams loses about $1,670 of blocked work per hour: 12 x 1,670 = about $20,000 per hour. The payments queue has few dependents, but its cost per hour is the payments that cannot be processed, about $15,000. The deploy script blocks one team's releases, about $8,000. Illustrative: an engineer-week costs $4,000.

With 17 engineer-weeks this quarter, the first three fit exactly (1 + 6 + 10). The schema is close behind and I would fund it next quarter; the cron job waits unless it causes on-call pain not counted here.

Opportunity cost versus features. 17 engineer-weeks cost $68,000 at $4,000 each. Show the feature work that capacity would otherwise fund, using the same per-week measure, so the trade-off is visible.

Defending it. To engineers: the inputs come from incident history and anyone can challenge a number. To finance: this is expected loss, not guaranteed savings; show ranges and the incident count behind each frequency.

Pitfalls. Quiet but catastrophic risks (rare, severe) are underweighted by frequency, so list them separately for judgment. Example: backups that have never been test-restored. At 0.02 failures a year, 72 hours to recover and $25,000 an hour, expected loss is 0.02 x 72 x 25,000 = $36,000, which scores 3.0 against a 3-week fix of $12,000. The frequency is a guess, so flag it for a leadership decision rather than letting the formula bury it. Likewise on-call pain: if the cron job pages an engineer at night six times a year, add the cost of those interruptions (hours lost, attrition risk) as a separate line. And a cheap fix is not automatically a good fix: the score also needs a real loss.

Direct answer. I would score each module on four criteria that are published before anyone sees the results: business value, how clean its boundary is, how small the damage is if the move goes wrong, and what the team learns that helps later moves. Start with modules that score high, build the pattern on a safe one, and leave the entangled, business-critical modules for later, when the team is practiced.

Terms. A monolith is one deployable application; services are smaller independently deployed pieces. A seam is a place where a module can be cut away with few connections to the rest. Blast radius is how much breaks if the migration fails.

Scoring (1 to 5, where 5 favors moving early; weights are illustrative):

Catalog search goes first: high value, a workable boundary, and it teaches the team the deployment, data and monitoring pattern. Billing and Checkout come last despite high value, because they are tangled with other modules and a failure there costs revenue. This follows the incremental strangler fig approach (named by Martin Fowler), where new services gradually take over behavior from the old system instead of a single big replacement.

Sequence in waves, not by rank alone. If a high-scoring module needs data owned by a low-scoring one, the dependency pulls the other forward. Review the order every quarter and after every migration.

Defending the order to teams who want theirs earlier.

• Publish the criteria, weights and scores, and let teams challenge a score with evidence.
• Offer a path: "your module moves in wave 3, after the first wave has proven the deployment, data and monitoring pattern, and here is what would pull it forward."
• Where a team has a real deadline (an end-of-support date), treat that as a constraint and show the cost to others.

Pitfall. Choosing the most painful module first: it is the least forgiving place to learn.