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. Decide on facts, not on whose request is louder: is the vulnerability reachable (can an attacker actually get to the flawed code, for example from the internet) and being exploited, what does a breach cost, and is the revenue tied to a date that cannot move? If it is internet-facing, exposes customer data or is being exploited, remediate first, but look for a one-week mitigation first so the feature need not wait four.

How I decide

• Exposure: exposed to the internet, exploit known, sensitive data behind it? Any yes pushes it to the front.
• Cost of delay (value lost per week the work is late): for the feature, the revenue slipping; for the vulnerability, probability of exploitation times impact.
• Mitigation: can a config change, an access restriction or a feature flag (a switch that turns a capability off without redeploying) cut the risk in days?

Worked numbers (illustrative). Put both sides on the same basis: the same four-week window. The sale is $480k and a four-week delay gives a 50% chance of losing it, so $240k expected loss. If breach impact is $3,000k and the percentages are the chance of a breach during those four weeks while the flaw stays open (if the feature ships first, it stays open for at least that long), a 2% chance gives $60k, 5% gives $150k and 20% gives $600k. The breach estimates straddle $240k ($60k and $150k are below it, $600k is above it), so the arithmetic alone does not settle it; the exploit status does. With no known exploit, 2% to 5% is a fair guess and the feature risk ($240k) is larger. If the flaw is already being exploited against similar systems, 2% is no longer credible: at 20% the expected loss is $600k, 2.5 times the deal risk ($600k / $240k), so security goes first. I would also weigh that breach impact includes customer trust and legal duties that are hard to price.

Commit: if actively exploited or exposing data, do a one-week mitigation, then remediate fully, shipping the feature after; if internal-only with no known exploit, ship the feature and schedule the fix with a firm date.

Who needs to be in the room: the security architect (owns the risk rating), the engineering manager (capacity), the product manager, the sales lead with the real deal evidence, and legal or compliance if customer data is involved.

Other common backlog collisions.

• Urgent patch, promised customer feature, platform performance: the patch goes first if it is exploitable, because exposure grows every day and fixes are usually small. The dated promise is second because missing it has a penalty on a known date. Performance is last because it degrades gradually and can be scheduled.
• Auth refactor, caching, database upgrade: the database upgrade goes first if the version nears end of support (the date the vendor stops shipping security fixes), since that is a hard date. For example, with support ending in about 13 weeks and an 8-week upgrade, work must start within about 5 weeks. The auth refactor is next as risk reduction, and caching is last, as optimisation.

Direct answer

I would split the work into three buckets: non-negotiable (the minimum scope the law and the deadline require, plus the evidence an auditor will ask for), delayed (valuable work that does not depend on this year), and dropped (work whose value does not survive the capacity cut). Then I give the business a plain price list in features and quarters, not an apology. Steps 1 to 3 below make the decision; the cases after them apply the same method.

Step 1: Establish what the regulation actually requires

Ask legal for a written reading that separates "must" (obligations and dates) from "should" (best practice). Gold-plating (building beyond what the rule requires) is how a one-year project becomes two. Treat the legal reading as an input, not as engineering's own interpretation.

Step 2: Capacity arithmetic (illustrative)

A 12-person team where the regulation needs 7.5 FTE (full-time-equivalent people) leaves 12 - 7.5 = 4.5 FTE, so compliance takes 62.5% of capacity. If 1.5 of the remaining 4.5 FTE go to keeping existing systems running, new product work is 3.0 FTE, or 25% of the original team.

Step 3: Sort the work

Scoring example (severity and likelihood each 1 to 5, illustrative):

The cleanup job looks low priority to product but scores 20, so it is protected first; the banner wording is a candidate to batch.

Applying the same method to common situations

• Conflicting requests on personal data. Legal wants data minimization (collect and keep only what you need), product wants analytics, sales wants customer-specific retention. Legal's mandatory constraints are fixed, and product and sales get the closest compliant alternative: aggregated data (totals, not individuals), anonymized data (identity removed), or opt-in (the user explicitly agrees).
• Region-specific legal rules. Build one configurable control, for example a data-location setting per region, instead of one code fork per region.
• High-value feature competing with compliance. Compare its dated revenue with the penalty and the delay risk of missing the deadline, and phase it behind the compliant core.

Quantify market entry

Entering a region that carries heavy compliance cost: compare expected gross profit (say $1.5M ARR, annual recurring revenue, x 80% margin = $1.2M per year once ramped) against the build (say 2 FTE x $200k = $400k) and an assumed ongoing audit burden of $200k a year. Net is $1.2M - $0.2M = $1.0M a year, so the build repays in about 0.4 years, roughly 5 months of ramped profit ($400k / $1.0M x 12 = 4.8). Entry is worth it on these numbers; delay it only if the ramp is slow or the compliance team cannot be spared this year.

Contingency for lost velocity (the amount of work the team ships per period)

Contractors help, but Brooks's law (Fred Brooks, 1975: adding people to a late software project makes it later) warns that new people need onboarding from existing staff. Assume 3 contractors deliver about half their capacity (1.5 FTE) in the first quarter and full capacity (3.0 FTE) later, and put them on well-bounded work, not on the critical path (the chain of tasks that sets the finish date). Phase delivery so partial compliance ships in quarter order.

Telling the business

Tell them in one page: what stops, what slows, what continues, when it returns, and what they could choose to trade back. Brief key customers before they hear it second-hand, and re-forecast every quarter.

Illustrative one-page price list, using the capacity arithmetic above: Stops: experiments with low confidence and nice-to-have refactors, for the full year. Slows: new product work falls to 3.0 FTE, 25% of the original team, so a feature set that took the whole team one quarter now takes about four quarters (1 / 0.25), before any help from contractors. Continues: keeping existing systems running (1.5 FTE) and features with a dated customer or revenue commitment. Returns: normal capacity in the quarter after the compliance deadline, re-forecast each quarter. Choice offered: the business can buy back capacity with contractors (about 1.5 FTE in the first quarter, 3.0 FTE later) or by narrowing the compliant scope the legal reading allows.