Product and Engineering Collaboration Questions

Direct answer

In the meeting I would not say "no". I would say what I can do by Friday, name the specific harm of the rushed version, and offer a safer path to the same outcome. Then I would write the agreed trade-off down before leaving the room, so the decision and the accepted risk have names on them.

In the meeting

1. Ask what the 48 hours protects (a customer promise, a demo). Understand the goal before arguing about the date.
2. State the risk concretely, in the PM's language: "If we ship this migration unreviewed, it can overwrite customer addresses, and we cannot restore them." A migration is a script that changes existing stored data in bulk. Another line I would say: "I can have Thursday's version ready that only shows what it would change and writes nothing. That gives you something to show on Friday, and the real run follows after review." The words "hard to undo" are the heart of it: a mistake that can be reversed is a cheap risk; one that cannot is expensive.
3. Separate the reversible part from the irreversible part.

What I offer instead

• Option A: in 48 hours, ship the reversible part (for example, read-only or dry-run output: the feature runs and reports what it would change, but writes nothing), behind a feature flag (a switch that turns the feature off without a new deploy).
• Option B: the full feature in about 5 working days with a review and a rollback plan (the exact steps to return to the previous state if it goes wrong).
• Option C: the full feature in 48 hours only if the PM's manager accepts the named risk in writing, with a tested backup of the data first.

I recommend A, then B. If the PM chooses C, I record it and do what I can to reduce harm, not refuse.

Recording the trade-offs

Post a short decision record in the team channel or ticket the same day:

Decision: Ship dry-run address cleanup Thursday behind a flag; real write after review (target 5 working days out).
Context: Sales wants it for Friday's customer call. The write step cannot be undone without a backup.
Options considered: A) dry-run now, write later  B) full in 5 working days  C) full in 48h, no review
Chosen by: PM (what and when), tech lead (risk statement)
Risk accepted: Customer sees a preview, not the cleaned data, on Friday.
Revisit: review at the 5-day mark, owner: tech lead

Trade-offs and pitfalls

• A bare refusal teaches product to stop asking engineers early.
• Do not bury the irreversible risk in jargon; the PM cannot weigh what they cannot picture.
• If the PM overrules me, I still write the record. It protects the relationship as much as the team: everyone later sees the same facts.

Direct answer

I chose neither extreme. Technical debt is the accumulated cost of earlier shortcuts in code, which makes every later change slower and riskier. A refactor is restructuring existing code, without changing what it does, so it is easier and safer to change. I did a short, targeted refactor of only the code the new feature had to touch, then built the feature on it, and logged the rest of the debt with an owner and a date. I explained the trade to the PM in terms of mispriced orders and launch risk, not code quality. The story uses illustrative numbers; use your own when you tell it.

Context

Product wanted a promo-code feature to be live for a seasonal campaign in 5 weeks. It had to live inside the pricing service, a large, untested function where small changes often produced pricing bugs.

Worked example: the options and their timelines

How I assessed the trade-offs

I pulled the previous quarter's bug tickets: 9 of the 14 pricing bugs (about 64%) were in the discount code path, the exact area the feature would change. That data, not my feelings about the code, made the case. A had the lowest cost and the highest chance of mispricing during the campaign; B was safe but late; C bought tests around the one area we were about to change for half a week more than A.

Communication

• PM: "Half a week buys confidence that campaign discounts will not misprice orders, and we still launch with a week and a half of buffer."
• My manager: asked for the first week to be protected from other requests.
• Peers: agreed a review plan for the extracted code so the knowledge spread.

Decision and outcome

I took C. The campaign launched on time. Over the next quarter, pricing bugs fell from 9 in the discount path to 3 (illustrative), and the remaining refactor sat in a dated ticket with an owner rather than in my head.

Other situations where business value competes with technical debt

• A model shipped with a manual step: ship the model now with a feature script that someone runs by hand (the script that turns raw data into the inputs the model reads), but log the cost it adds. Illustrative numbers: 6 hours of manual retraining each month is 72 hours a year, about 1.8 engineer-weeks at 40 hours. Track both sides, the near-term business metric and that long-term cost, and review them next quarter.
• Making the case for a refactor to someone who wants a revenue feature: make the case in lead time (the elapsed days from starting a change to it being live), not neatness. Show how long the last three changes in that area took compared with similar changes elsewhere, and propose folding the refactor into the feature.
• Quality already compromised to hit a deadline: write down what was skipped, create a dated ticket with an owner, and schedule remediation before the next deadline, or it never happens.
• Platform work (shared infrastructure that other teams build on) deliberately postponed for a strategic opportunity: say what was postponed, until when, and which signal would reopen the decision. Example: "We postpone the deploy-pipeline upgrade to ship the partner integration. If deploys exceed 30 minutes or the share of failed deploys passes 10% (illustrative), we reopen the decision."
• A scaling problem versus user-facing work: use data. For example, if a database is at 60% of its connection limit and grows 5 points a month, the limit arrives in (100 - 60) / 5 = 8 months. Compare that with the cost of delaying the user-facing work, and track p95 latency (the time within which 95% of requests finish) and error rate (the share of requests that fail) against the traffic forecast: for example, if the forecast says traffic doubles in six months, check whether p95 latency stays under the agreed limit at double the load.

Trade-offs and pitfalls

• A refactor with no stated business reason sounds like a preference.
• Compromised quality without a dated remediation plan becomes permanent debt.