Delivery Prioritization: Scope, Speed, Quality, and Cost Questions

My first response: do not say yes or no yet

I ask what the demo has to achieve and what the stakeholder wants the audience to see. Example: a sales lead asks for a new "export to PDF" report in next week's customer demo, and the real need is that customers see the reporting story. Often the idea has to be shown, not a working production feature.

Offer instead (in order of preference)

1. A scripted demo path: a clickable prototype or hard-coded flow, clearly labelled as a preview. Roughly 2 days, not 3 weeks.
2. A roadmap slide with a dated commitment.
3. Move the demo, only if the audience's decision depends on the feature working for real.

Is the extra value worth the disruption? (a quick scoring, with illustrative numbers)

I score each option 1 to 5 on how much it changes the audience's decision (value) and how much it risks (broken live demo, work pulled from committed items, rushed QA):

One week remains and the feature needs three, so a real build cannot fit; the choice is only which preview to show. I also ask how much the feature would change the audience's decision, because that sets how much disruption is justified.

Getting agreement from the people affected

A late request touches several teams, so I walk the critical path (the longest chain of dependent steps, which sets the earliest finish) with engineering, QA, product and whoever owns the demo environment. Steps marked (CP) are on it. Every step here waits for the one before it, so all five days are on the critical path and there is no spare time (float): a one-day slip anywhere moves the rehearsal into the demo day, which is why the freeze on day 4 is not negotiable:

When a senior stakeholder wants the real feature released immediately instead

If the team needs time to harden it (fix rough edges and test under real load), I propose partial delivery: release behind a feature flag (a switch that turns the feature on for chosen users only) for internal users or a small percentage of customers. A monitoring plan (what we watch, such as error rates) and a rollback (switching it off or reverting quickly) make that safe. I say it as protecting the stakeholder: "this gets you a first result this week and avoids an incident in front of your customers."

Direct answer
Technical debt is the future cost you take on when you choose a quicker, less clean way to build something. In product terms: you ship sooner today, and every later change in that area costs extra time, which shows up as slower features and more bugs. Ward Cunningham coined the metaphor in 1992: a little debt speeds things up if it is repaid promptly, and the danger is leaving it unpaid, because the extra effort every change costs is the "interest" (the loan is the shortcut itself).

When taking it on is acceptable

• It is a deliberate choice, not an accident from missing knowledge.
• The date is worth something real (a conference, a contract, a market window).
• The shortcut is contained and reversible, in an area few other things depend on.
• There is a named payback plan with a date and an owner.
  Not acceptable: shortcuts on security, data integrity or payments, or in a shared platform that many teams build on.

Track it
Keep a debt register (a simple shared list) with one row per item: where it is, what it costs us per week (interest), what breaks if we ignore it, rough fix effort, owner.

Prioritize it
Rank by interest relative to fix cost, plus risk. Illustrative item: a payment workaround costs 2 engineer-days (one person's working days) per release, with 2 releases a month, so 4 engineer-days a month. Fixing it takes 10 engineer-days, so the fix pays for itself in 10 / 4 = 2.5 months. That beats a cleanup that costs 10 days and saves 1 day a month (payback 10 months). Also reserve a recurring slice of capacity for repayment, for example 15% of each sprint: a team of 6 with 10 working days per sprint has 60 engineer-days, so 15% is 9 engineer-days per sprint. The percentage is a team policy you agree with product, not a benchmark; it keeps debt from competing with every roadmap item.

Communicate to the business
Avoid code talk. Say, using the same example: "Every release that touches payments takes 2 extra days because of a shortcut we took last year; with two releases a month that is 4 days a month. Fixing it costs 10 days once and pays back in about 2.5 months." Show cost, risk and payback, offer options (fix now, fix after the launch, live with it), and ask for the decision.

Pitfalls
Calling everything debt (messy code that never changes costs nothing), hiding debt from the business, and having a register nobody schedules from.

Would it help? Sometimes, if I choose where they go

Brooks's law (from Fred Brooks's book The Mythical Man-Month) says that adding people to a late software project tends to make it later, because new people need onboarding and more people means more coordination.

What it costs in the first weeks (illustrative numbers)

• Each contractor ramps: 25%, 50%, 75%, 100% productive across weeks 1 to 4.
• Existing engineers spend time onboarding them. These are the totals for all three contractors together, not per contractor: 1.0, 0.5, 0.3 and 0 person-weeks in weeks 1 to 4.
• Communication paths grow: a team of 6 has 6x5/2 = 15 paths between people; a team of 9 has 9x8/2 = 36. More paths means more questions, handoffs and review requests, so each person spends more of the week coordinating and less building.

After 4 weeks: net +5.7 person-weeks, against 12 nominal. Each contractor delivered 1.9 effective weeks over a 4-week paid period, so I pay about 2.1x per effective week in the first month. Compare the 24 person-weeks of the existing team (6 x 4): the gain is about a quarter.

If ramp is slower (0, 25, 50, 75%) and onboarding doubles, the same month nets only +0.9: roughly nothing.

My recommendation

Add at most one or two contractors, on separable work (tasks with a clear boundary that need little knowledge of the rest of the system, such as test automation, a data migration, an integration adapter), not on the critical path (the chain of dependent tasks that sets the launch date). Cut scope as well; people alone will not protect the date if less than about a month remains.

Questions for a skeptical engineering manager: Which modules can be handled with little context? How long to get a first merged change? What does review load (the time existing engineers spend reviewing the newcomers' code) look like?

Business case: cost per effective week = contractor weekly cost / (net effective weeks / paid weeks) for the first month. Worked with an assumed $4,000 per contractor per week: paid weeks are 3 x 4 = 12, so paid cost is 12 x 4,000 = $48,000. Net effective weeks are 5.7, so the ratio is 5.7 / 12 = 0.475 and cost per effective week is 4,000 / 0.475 = about $8,400, versus the $4,000 sticker price.

Telling within a month: a first merged change within about a week; review turnaround not rising; the team's own weekly throughput (how much finished work it completes per week) back to its earlier level by week 3; defect rate in contractor code close to the team's. If the team's throughput is still down at week 3, stop adding people.

Direct answer
Keep the date by launching on it, but in controlled steps with a ready way back. A feature flag (an on/off switch in code) lets me deploy the code early with the feature off, then turn it on for a growing share of users. The date means "released and monitored", not "everyone exposed at once".

Worked example: a one-click reorder that charges the saved card. Launch deadline Thursday 18 March 2027

• Thu 25 Feb: code deployed, flag off (zero exposure).
• Tue 2 Mar: staff only.
• Thu 4 Mar: 1% of customers.
• Tue 9 Mar: 10%.
• Tue 16 Mar: 50%.
• Thu 18 Mar: 100%, on the deadline.
  Why these steps: 1% keeps the damage of an unknown bug small, 10% gives enough orders to notice rarer problems, and 50% shows how it behaves under heavier load. If a problem appears at 10% on 9 March, there are 6 working days (10 to 17 March) to fix and re-test before the date.

What I watch

• Guardrail metrics (harm measures that must not get worse): duplicate or wrong charges, payment failures versus customers not given the feature (the control group), error rates, support contacts.
• Success metric: reorder completion rate.

Pull-back rules, agreed in advance (illustrative thresholds)

• Observation window: each step runs at least 2 full business days and at least 1,000 reorders, so a small sample does not mislead.
• Roll back immediately (flag off): any confirmed double charge or incorrectly written data. One is enough, because money is involved.
• Hold at the current percentage and investigate: payment failures more than 0.5 percentage points above the control group, or support contacts per 1,000 reorders more than double the control group's, over the window.
• Proceed: all guardrails within those limits and no open severity-1 or severity-2 issue (severity levels rank incidents by customer harm: 1 means money or data is wrong, 2 means a major function is broken) for the full window.
  Real thresholds are set with engineering and finance before the first step, not in the heat of an incident.

Check the thresholds against sample size (illustrative). With 1,000 reorders in the exposed group and a payment-failure rate near 2%, the random noise in a comparison with the control group is about 0.6 percentage points (square root of 2 x 0.02 x 0.98 / 1,000 = 0.0063). That is larger than the 0.5-point hold trigger, so at the minimum sample the trigger would fire or stay quiet largely by chance. So I treat 1,000 reorders as a floor for the double-charge check only, and for the 0.5-point comparison I either wait for a larger window (about 10,000 reorders brings the noise to about 0.2 points) or hold on a trend that persists across two consecutive windows. Zero double charges in 1,000 reorders is also weak proof: it only rules out a rate above roughly 0.3% (3 / 1,000, the rule of three), which is why the early 1% and 10% steps are about catching gross failures, and why the 50% step must run the longest. At 1% exposure, reaching 1,000 reorders may take longer than the 5 days from Thu 4 Mar to Tue 9 Mar, in which case the step is extended or the next step is cut, never the sample rule relaxed.

Minimum acceptable quality (the launch bar): tests for the charge path, the flag proven to switch off in under a few minutes in a rehearsal, no irreversible data change, and an on-call owner (the engineer who is reachable and responsible for responding to alerts out of hours).

Rollback plan and user trust: turning the flag off must stop new exposure; for already-affected users there is an automatic refund path and a plain-language message. We keep the old reorder route live.

Who agrees up front: product (owner), engineering (rollback works), on-call/operations, support (script ready), finance (charges), and the executive sponsor, who accepts that if a guardrail fails we ship at the percentage that passed rather than force 100%.

Pitfall: treating "launch" as all-or-nothing, which turns a recoverable problem into a missed date.

Direct answer
When resources are tight I lean toward shipping an incremental slice first, because it starts earning (and teaching) sooner and limits what we can get wrong. I switch to "complete later" only when a partial version has no standalone value or would damage trust.

Decision criteria

1. Standalone value: does the slice help shoppers by itself?
2. Cost of delay: the money lost for each week the improvement is not live.
3. Re-work overhead: extra effort because we ship twice.
4. Risk and learning: can a real-traffic test (an A/B test, where half of shoppers see the new version and half the old, so we compare results) confirm the idea before the larger spend?
5. Experience coherence: would a half-finished checkout confuse or annoy users?

Metrics: checkout conversion rate (orders divided by checkout starts), cart-abandonment rate, revenue per session, payment-error rate, and support contacts about checkout. The last two are guardrail metrics (safety checks that must not get worse even if the headline metric improves), so a faster funnel that raises payment errors counts as a loss.

Worked example (illustrative numbers)
Assume 100,000 checkout sessions a month and an average order of $60. "Percentage points" means added conversion measured directly: 3 points means 3 more orders per 100 sessions.

• Full version (one-page checkout, saved payment, address autofill): 10 weeks if built in one go (a "big-bang" release, everything shipped at once), adds 3 points: 100,000 x 0.03 x $60 = $180,000 a month.
• Slice (guest checkout plus address autofill): ships in week 4, adds 1.5 points: 100,000 x 0.015 x $60 = $90,000 a month. Building in slices costs about 15% more total effort (assumed), so the full version arrives at 10 x 1.15 = week 11.5 instead of week 10.

A month is about 52 / 12 weeks, so weekly figures are monthly x 12 / 52: the slice earns about $20,800 a week and the full version about $41,500 a week.

Compare both plans up to week 11.5, when both have the full version live:

• Slice-first: slice live from week 4 to 11.5 = 7.5 weeks x $20,800 = about $155,800.
• Big-bang: full version live from week 10 to 11.5 = 1.5 weeks x $41,500 = about $62,300.
• Net: slice-first is ahead by about $93,500, and its first slice was tested on real traffic.

What flips it: if guest checkout alone lifted conversion by almost nothing, the slice earns almost nothing and big-bang wins. If the extra effort were about 60% or more (full version at week 16 or later) instead of 15%, the slice no longer pays for the delay; I would wait.

Pitfall: judging the slice only on conversion; check the guardrail metrics too.