Scenarios: scope, priority, and workload

This chapter is a lookup bank, not an essay. It collects real chat exchanges about requirements, priorities, workload, and ownership, shown from both chairs: sometimes you are the engineer pushing back, sometimes you are the PM, the manager, or the person handing work over. The core move stays the same throughout: soften the person, sharpen the substance. Skim for the situation you are in and steal the line that fits.

Requirements are unclear

  • Ticket has no acceptance criteria. Q: "Can you pick up PROJ-812 today?" A: "Happy to. The ticket doesn't say what 'done' looks like, so before I start: is success that the export finishes, or that it matches the old CSV byte for byte?"
  • Ambiguous "should be fast". Q: "The search should just be fast." A: "Give me a number to aim at and I can commit to it. p95 under 200ms for a typical query? That changes whether we need the index rewrite."
  • You are the reviewer asking back. Q: "PR up, added the discount logic." A: "Before I dig in, which rounding rule did we agree on? The spec is silent and this is the kind of thing finance will notice."
  • Two readings of the same line. Q: "Just archive old records." A: "Two readings here: soft-delete with a flag, or actually move rows to cold storage. They cost very differently. Which one did you mean?"
  • PM assumes you know the edge case. Q: "You know how the refund flow works, right?" A: "I know the happy path. What should happen if the charge already settled? That branch isn't written down anywhere I can find."
  • Vague "make it like Stripe". Q: "Make the checkout feel like Stripe's." A: "Can you point at the two or three specific things you like? 'Feels like Stripe' could be the card animation, the error copy, or the retry logic, and those are three different weeks."
  • Design hands off a screen with gaps. Q: "Figma's ready, go ahead and build it." A: "The main state is clear. There's no empty state, no loading, and no error frame though. Can you sketch those, or should I fill them in and you correct me?"
  • You are the PM getting a fuzzy estimate. Q: "It'll take a while, hard to say." A: "Totally fair that it's fuzzy. What would you need to know to turn 'a while' into 'about three days' or 'about two weeks'? I can go get that."
  • Requirement written as a solution. Q: "Add a Redis cache to the profile page." A: "I can do that. What's the problem we're solving, slow loads or DB cost? If it's load, the fix might be a query index, not a new service to run."
  • Unstated non-functional need. Q: "Build the bulk importer." A: "One question that changes the design: how big is a realistic file? A thousand rows and a million rows want very different architectures."
  • Spec contradicts itself. Q: "Follow the spec on page 4." A: "Page 4 says email is required, page 7 shows an example with no email. Which one wins? I'll build to whichever you confirm."
  • You are the tech lead triaging intake. Q: "I filed a ticket, can someone grab it?" A: "Before it goes in the sprint, I need one thing: what does a user see when it works? Add that line and I'll assign it same day."
  • You are the reviewer requesting a spec link. Q: "Can you approve, it's straightforward." A: "I'll approve fast once I know the intended behavior for an empty cart. Link the ticket's acceptance criteria and I'm good to go."

Don't be confused: asking for clarity is not stalling. Stalling is going quiet; clarifying is naming the exact fork in the road and asking which way. One protects the deadline, the other risks it. If you can, offer your best guess with the question so the reader can just say "yes" instead of writing a paragraph back.

Requirements keep changing

  • Third change this sprint. Q: "Small tweak, can the filter be multi-select now?" A: "Sure, and I want to flag this is the third scope change on this ticket this week. Each is small, together they've roughly doubled it. Want me to keep absorbing them or re-estimate?"
  • Change lands mid-build. Q: "Actually, put the button on the left." A: "Easy while it's in progress, noted. If more of these come after I open the PR, they get more expensive, so send them my way now if you have them."
  • You are the PM, and you know you're churning. Q: "I keep changing this on you." A: "It's fine, this is what iteration looks like. Can we lock the data model by Thursday though? That's the part that's painful to redo, the UI I can flex on."
  • Requirement flips after code review. Q: "We decided to sort by date, not name." A: "Got it. The PR's already approved for name-sort, so this is a new small PR, not a tweak to that one. I'll have it up this afternoon."
  • Stakeholder changed their mind twice. Q: "Back to the original design, sorry." A: "No problem, I still have that branch. To save us both the whiplash next time, want to sit for 15 minutes and lock it before I rebuild?"
  • Silent scope creep. Q: "Oh and it should also email the manager." A: "That's a real addition, not part of the original ask, so I'm going to log it as its own line. Same priority, or does the ship date move?"
  • You need a change freeze. Q: "One more thing before you ship." A: "I want to get this out today. Can we call it frozen now and put anything new in a fast-follow? Otherwise 'today' quietly becomes 'next week.'"
  • Downstream churn from a moving spec. Q: "Why is this taking longer than you said?" A: "Honest answer: the requirement moved four times since the estimate. Here's the log. I'm glad to re-baseline off where it stands today."
  • Requirements changed after handoff to QA. Q: "QA is testing the old behavior." A: "Right, we changed it Tuesday. I'll update the test plan and ping QA directly so they're not filing bugs against the old spec."
  • You are the PM freezing scope. Q: "Can I still tweak the copy Friday?" A: "Copy yes, layout no. I'm freezing structure today so engineering can land it. Send copy changes as one list and I'll batch them."
  • You are the PM owning the churn. Q: "The team's frustrated with the redesign changes." A: "That's on me, I kept reopening it. I'm locking the spec today and any new idea goes to the backlog, not this sprint. I'll tell them directly."

A PM asks for something unrealistic

  • Two weeks of work, three days given. Q: "Can we get the whole billing revamp by Friday?" A: "Not the whole thing safely by Friday. I can have invoices done and tested by then, and proration the week after. Does that split work?"
  • Feature that fights the architecture. Q: "Real-time sync across all devices, this sprint?" A: "That's a genuinely hard problem, not a sprint of typing. I can spike it to give you a real number, or ship a 30-second poll now that covers 90% of the value. Your call."
  • "Just" hides a rewrite. Q: "Can you just make it multi-currency?" A: "The word 'just' is carrying a lot here. Multi-currency touches pricing, tax, refunds, and reporting. It's a project. Want me to scope it as one?"
  • You are the PM, hearing "impossible". Q: "That's not realistic this quarter." A: "Okay. What would be realistic? I'd rather ship the 70% that's doable than nothing. Tell me where the cliff is."
  • Deadline set before engineering was asked. Q: "I already promised the client Monday." A: "I understand the spot you're in. Monday isn't real for the full feature. What's the smallest version that would keep the client happy, and can you sell them that?"
  • Perfect and fast and cheap. Q: "We need it fast, and rock solid, and no new infra." A: "Pick two and I'll deliver hard. Fast plus solid means a bit of new infra; no-infra plus solid means it's slower. Which corner do we drop?"
  • Estimate compressed by fiat. Q: "Can you do it in half the time?" A: "I can't just wish the hours away, but I can cut scope. Drop the admin screen and the CSV export and I hit your date. Want me to?"
  • You are the manager backing your engineer. Q: "Sales says it has to ship Thursday." A: "I hear the pressure. Dana's estimate is a week and I trust it. Let's give Sales a Thursday version that's read-only and the full thing the following week."
  • Unrealistic quality bar for a prototype. Q: "The demo needs to be production-grade." A: "For a demo I'd cut corners on purpose and label them. Production-grade for Friday means we test nothing real. What's the demo actually trying to prove? Let's protect that part."
  • You are the PM negotiating with sales. Q: "Engineering says the date's impossible." A: "They're right about the full build. Here's a phased version we can commit to: read-only next week, editing the week after. I'll take that to the client."
  • You are the PM defending the cut. Q: "Why did we ship without the export?" A: "I cut it on purpose to hit the date, and I logged it. It's the top fast-follow, landing next week. That was my call, not the team missing it."

Pushing back on an urgent request

  • "URGENT" with no context. Q: "URGENT: can you fix the dashboard NOW?" A: "On it. Quick triage so I fix the right thing: what's broken, who's affected, and is anyone blocked right now, or is it annoying but working?"
  • Urgent that isn't. Q: "Drop everything, need this today." A: "I can, but it means the payments bug waits until tomorrow. That one's costing us failed charges. Still want me to switch, or does this hold till the afternoon?"
  • You are the one asking for urgency. Q: "How urgent is this really?" A: "Real, not fake-urgent. The vendor cert expires at 6pm and calls start failing after. That's the deadline, not a preference."
  • Interrupt during focused work. Q: "Got a sec? It's kind of urgent." A: "Give me 20 to close out what I'm mid-way through so I don't leave it broken, then you have my full attention. Or if it's on-fire urgent, say the word and I stop now."
  • Everything is priority one. Q: "All three of these are P1." A: "If everything's P1, nothing is. I can only run one at a time today. Rank them for me and I'll take the top one now, the rest in order."
  • Urgent request outside hours. Q: "Sorry to ping at 9pm, can you deploy this?" A: "For a genuine fire, yes. Is prod down, or is this something that can ship first thing tomorrow with fresh eyes? Late deploys are how we cause the next fire."
  • You are the manager protecting the team. Q: "Can your team hotfix this tonight?" A: "Depends what 'this' is. If customers are losing data, yes, I'll get someone. If it's a cosmetic bug, it waits for morning. Which is it?"
  • Pushback that offers a path. Q: "I need the API change live in an hour." A: "An hour isn't safe for a schema change. I can ship it behind a flag in an hour and flip it on after a quick check. That gets you live without the risk. Good?"
  • You are the on-call lead sizing the page. Q: "I paged you, checkout feels slow." A: "Thanks for flagging. 'Feels slow' isn't a page on its own. Is anyone failing to check out, or just waiting? If it's failures, I escalate now."
  • You are the incident commander triaging. Q: "Everyone's pinging me about the outage." A: "Good, funnel it here. I need one scribe, one person on the database, everyone else holds. What's the current error rate?"

Explaining a small change is actually complex

  • One-line change, big blast radius. Q: "It's a one-line change, why a day?" A: "The change is one line, the confidence is the day. That field feeds billing and the export, so the work is proving I didn't break those, not typing the line."
  • Toggle that touches a migration. Q: "Just add a boolean to the user." A: "The column is easy. Backfilling 4M existing rows without locking the table, and updating the three services that read users, is the actual work. Roughly two days, not two minutes."
  • You are the reviewer explaining the hidden cost. Q: "Can you rush my tiny PR through?" A: "It's tiny in diff but it changes the auth check every request hits. That earns a careful read, not a rubber stamp. Give me an hour and I'll do it properly."
  • Rename with tentacles. Q: "Simple rename, right?" A: "The symbol rename is instant. It's public in our API, so I also have to keep the old name working for six months and deprecate it. That's the part that takes real time."
  • Frontend tweak, backend consequence. Q: "Can we show the total with tax? Small UI thing." A: "The label is small. Computing tax correctly per region isn't, and we don't have that data on this page yet. So it looks like UI but it's mostly a backend fetch."
  • Third-party constraint hides in a small ask. Q: "Just let users change their email." A: "The form is easy. The complexity is that Stripe and our auth provider both key off email, so changing it means a coordinated update across two vendors plus a verification step. Worth doing, just not small."
  • "Move the button" that isn't. Q: "Move the checkout button up, quick one." A: "In one layout, quick. We have five breakpoints and an A/B test running on that exact element, so I have to not corrupt the experiment. Half a day to do it clean."
  • You are the senior explaining to a junior. Q: "Why won't they just merge my one-liner?" A: "Because that line runs on every login. The review isn't gatekeeping, it's making sure we don't lock everyone out at 2am. Worth the extra hour."

Disagreeing with your task's priority

  • Assigned low-value work over a fire. Q: "Start on the settings redesign this week." A: "I'll take it, but I want to name a tradeoff: the login timeout bug is hitting ~200 users a day. If I do settings, that keeps bleeding. Are we okay with that order?"
  • You are the manager hearing the pushback. Q: "This feels lower priority than the timeout bug." A: "Say more. If the bug's hitting real users daily, you might be right and I'll re-rank. What's the actual impact number?"
  • Priority set without the data. Q: "The mobile bug can wait." A: "It's 40% of our traffic and the bug blocks signup there, so 'wait' has a cost. Here's the funnel drop. Still lower than the desktop feature? Genuinely asking."
  • Shiny feature over tech debt. Q: "New feature first, refactor later." A: "Fine to sequence it that way. Flagging that this feature adds to the pile we keep saying we'll clean, and the deploys are already flaky. I'll build it, and I want the refactor on next sprint's board, not 'later.'"
  • You disagree but will commit. Q: "We're going with the reporting work first." A: "I'd have picked the perf work, but I get the reasoning and I'm on board. Reporting it is. I'll flag if the perf issue turns into an incident."
  • Priority conflict between two PMs. Q: "My ticket should go first." A: "You and Priya both have a P1 on me and I can't do both today. I'm not the right person to rank across your teams. Can you two align and tell me the order?"
  • Escalating a priority call, calmly. Q: "Just trust me, this is more important." A: "I might be missing context, and I could be wrong. Can we get five minutes with your lead to sanity-check the order before I switch? If they agree, I'm all in."
  • You are the manager re-ranking. Q: "Both features are due Friday, which first?" A: "Checkout first, it's revenue and it blocks the marketing push. Settings slips to Monday. I'll tell the settings stakeholder myself so it's not a surprise."

Asked to work outside your responsibility

  • Backend dev asked to do design. Q: "Can you just design the page too?" A: "I can rough out a layout, but you'll get a better result from someone who does this well. Want me to grab 20 minutes with Yuki on design, or truly just wing it?"
  • You are the manager setting the boundary. Q: "Can Ravi cover the data pipeline stuff?" A: "That's not his area and it'd pull him off the API work you're waiting on. Better to loop in the data team. Want me to make that intro?"
  • Asked to own something with no context. Q: "You take over the legacy billing service." A: "Happy to help, and I want to set expectations: I've never touched it, so week one is me learning, not shipping. If that's fine, great. If you need speed, the person who wrote it is faster."
  • Repeated one-off asks becoming a job. Q: "Can you pull those numbers again?" A: "Sure, this once. This is the fourth time though, so it's really a recurring report. Want me to build a self-serve dashboard so you're not blocked on me?"
  • Sales asks engineering to do support. Q: "Can you hop on the customer call and debug live?" A: "I can join for the technical part. I'm not the right person to manage the customer relationship on the call, so keep our AM driving and pull me in when it gets technical."
  • You accept, with a scope line. Q: "Can you handle the on-call docs? Not really your job I know." A: "I'll do it because it needs doing. Marking it as a favor, not a new standing duty, so we're clear it doesn't live on my plate forever."
  • Asked to make a product call. Q: "Should we charge for this feature?" A: "That's a product and pricing call above my pay grade, and I don't want to guess. I can tell you what it costs us to run. Take that to the PM and I'll build whatever you decide."
  • You are the platform lead protecting your team. Q: "Can your team just fix it in our repo?" A: "We'll pair with you, but we won't own changes in a repo we don't maintain. You keep the ownership, we bring the knowledge. Works?"

Asked to support production after hours

  • Non-fire ping on a Friday night. Q: "Can you look at this staging error tonight?" A: "Staging isn't customer-facing, so I'm going to look Monday morning fresh. If it were prod I'd jump now. Flag me if that changes."
  • You are on call and it's legit. Q: "Prod's throwing 500s, you're on call." A: "On it now. Ack. Give me five to get eyes on the logs and I'll post status in the incident channel."
  • Off-call and asked to jump in. Q: "You know this service best, can you help at 11pm?" A: "I'll get on because I know it, and let's fix the bus-factor after: I shouldn't be the only one who can. For tonight, what's the symptom?"
  • You are the manager, protecting recovery. Q: "Sam handled the outage till 3am, can they do the review at 9?" A: "No, Sam's sleeping in and off today. I'll run the review. People who firefight overnight get the next day, no exceptions."
  • Setting an after-hours expectation up front. Q: "Will you be around this weekend if it breaks?" A: "I'm not on call this weekend, Tomas is. Page the rotation, not me directly, so it reaches whoever's actually covering. Here's the runbook link."
  • Recurring after-hours creep. Q: "Quick prod thing again, you free?" A: "This is the third evening this week. I'll do tonight's, and I want to raise the pattern with the team, because if prod needs someone nightly that's a staffing gap, not my calendar."
  • Declining a non-urgent late deploy. Q: "Can we push the release at 8pm?" A: "I'd rather not deploy at 8pm with no one around to watch it. First thing tomorrow we ship it and babysit the rollout. Same outcome, way less risk."
  • You are the EM setting the on-call norm. Q: "People keep DMing me at night for prod stuff." A: "That stops now. Route everything through the pager rotation, not DMs. I'll announce it so no one feels they have to answer off-hours."

Explaining you are overloaded

  • New ask on a full plate. Q: "Can you also take the migration?" A: "I want to be straight: I'm at capacity with the API rewrite and the on-call this week. I can take the migration if something drops. What comes off, or who else can grab it?"
  • You are the manager, checking load. Q: "How's your bandwidth?" A: "Honestly tight. Two P1s and code review for the whole team. I can keep the P1s moving or share the reviews, not both well. Which do you want me to protect?"
  • Showing the list, not just saying "busy". Q: "You keep saying you're slammed, with what?" A: "Fair, here it is: checkout bug, the vendor integration, on-call, and Priya's PRs. That's the week. Which of these is actually lower than you thought?"
  • Overloaded and something will slip. Q: "Can you get all three done by Friday?" A: "Not all three well. Two solid by Friday, the third early next week, or all three rushed and buggy. I'd pick the first. Your call on which two."
  • You are the teammate offering to help. Q: "I'm drowning this week." A: "Send me the two most droppable things off your list, I've got a slow afternoon. No hero stuff, just genuinely which two can I take?"
  • Quiet overload before it breaks. Q: "Everything on track?" A: "Mostly, and I want to flag early rather than surprise you Friday: I'm carrying a bit much and the docs task is the one at risk. Want to move it or accept it slips?"
  • Context-switching cost. Q: "Can you jump between all four projects?" A: "I can, but every switch costs me about an hour of re-loading. Four at once means I'm slow on all of them. Two focused would ship more. Can we narrow it?"
  • You are the manager rebalancing load. Q: "Ravi says he's underwater." A: "He is, I checked his board. I'm moving the docs task and one PR queue off him today. Can you cover intake this week so he gets air?"
  • You are the manager protecting focus time. Q: "Can Dana take one more meeting series?" A: "No, Dana's calendar is already too fragmented to ship. I'm declining new recurring meetings for the team this sprint. Async updates instead."

Declining additional work

  • Clean no with a reason. Q: "Can you own the analytics rebuild too?" A: "I can't take that on and do the current work justice, so I'm going to say no to owning it. I can review the design or unblock the team on it, if that helps."
  • You are the manager saying no upward. Q: "Can your team also cover the mobile app?" A: "Not without dropping something you care about. I'd have to pull off the payments work. I'd rather say no than half-do both. Let's talk about hiring or resequencing."
  • No, with a trade. Q: "Add the reporting feature to your sprint?" A: "Yes if something leaves the sprint, no if it's on top. It won't fit as an add. What would you like to swap it for?"
  • Declining a favor that isn't small. Q: "Quick favor, redo the whole onboarding flow?" A: "That's a project wearing a favor's clothes, so I have to say not this week. Log it as real work and I'll estimate it properly."
  • You are declining but not ghosting. Q: "So you won't help at all?" A: "I won't own it, that's different from won't help. I'll pair for an hour to get you unstuck, and point you at who has capacity to carry it. Fair?"
  • Protecting deep-work time. Q: "Join this working group? Meets thrice weekly." A: "I'm going to pass. Three standing meetings would eat the focus time I need for the migration. Loop me in async on anything that touches my services."
  • Declining and naming the risk of yes. Q: "Just say yes, we'll figure it out." A: "If I say yes to this, I'm quietly saying no to the deadline we already promised. I'd rather be honest now than apologetic later. Let's pick which one wins."
  • You are the lead saying no for the team. Q: "Can the team squeeze in this extra epic?" A: "Not this quarter without dropping a committed one. I won't set them up to miss two things. Let's pick what this replaces, or defer it."

Asking for clearer ownership

  • No named owner. Q: "Someone should fix the flaky test." A: "Agreed, and 'someone' means no one. Can we name an owner? I'll take it if no one else wants it, but I want it assigned, not floating."
  • You are the lead assigning it. Q: "Who owns the search service now?" A: "Good that you asked, it's been fuzzy. Making it official: Ines owns search, I'm backup. I'll update the on-call doc so it's written down, not just said."
  • Ownership gap surfaces in an incident. Q: "Whose service caused the outage?" A: "That's the problem, no one clearly owned it, which is half of why it broke. Let's fix that in the review: pick an owner before we close this out."
  • Asking who signs off. Q: "Can we ship this?" A: "Who's the decision-maker on that? I can build it, but I don't want to be the one who 'decided' to ship a pricing change. Point me at whoever owns that call."
  • Shared code, no clear steward. Q: "Who maintains the shared utils package?" A: "Right now, everyone and no one. I'd like one team to own it so PRs get reviewed by someone who cares. Can we assign it, even loosely?"
  • You want ownership written down. Q: "You know it's yours, why does it need a doc?" A: "Because when I'm on vacation, 'everyone knows' becomes 'no one knows.' Two lines in the service catalog and we're covered. I'll write them."
  • You are the lead closing an ownership gap. Q: "Nobody's watching the billing alerts." A: "You're right, that's on me to fix. Assigning it to the payments squad today and adding it to their on-call scope. I'll confirm in writing."
  • You are the manager naming a decision-maker. Q: "Who approves the pricing change?" A: "Finance owns that call, not engineering. I'll get you the name and CC them so the sign-off is unambiguous."

Both engineers assume the other owns it

  • Classic dropped handoff. Q: "I thought you were handling the deploy?" A: "And I thought you were, which is exactly how it fell through. No blame, let's just do it now and then write down who owns deploys so this doesn't repeat."
  • You are the one who dropped it. Q: "The migration never ran, that was on you." A: "You're right, I assumed you'd triggered it and I should've confirmed instead of assumed. Running it now, and I'll ping when it's done so there's no ambiguity."
  • Two teams, one seam. Q: "Your side should validate the input." A: "We thought your service did. Let's not both skip it or both do it twice. Can we agree in this thread: validation lives on my side, and I'll document the contract?"
  • Neither picked up the alert. Q: "Did anyone ack the disk alert?" A: "Looks like we both saw it and both figured the other had it. That's a gap. I'll ack now, and let's set the alert to page one named person, not the whole channel."
  • You catch the ambiguity early. Q: "Cool, so we're good on the API contract?" A: "Before we say good: who writes the migration, you or me? I don't want us both assuming the other does. I'll take it unless you'd rather."
  • Reconstructing after a miss. Q: "How did this ship untested?" A: "Handoff between us had no clear owner for the test pass, so each assumed the other. Fixing the process: from now the PR author owns tests unless they explicitly hand it off in writing."
  • You are the lead fixing the seam. Q: "Our two teams keep dropping the middle." A: "Let's write a one-line contract: your team owns ingestion up to the queue, mine owns everything after. I'll put it in the runbook today."

Explaining technical risk to a non-technical stakeholder

  • Migration risk in plain terms. Q: "Is the database upgrade safe?" A: "Mostly. Think of it like moving house while people still live there. We can do it with almost no disruption, but there's a small window where something could go wrong, so we do it Sunday 6am and have a way to roll back."
  • You are the exec asking for the bottom line. Q: "Just tell me, will it break?" A: "Probably not, and I won't pretend it's zero risk. Worst case is a 30-minute outage at 6am Sunday, and we can undo it. Best case, no one notices. I'll tell you the moment it's clean."
  • Explaining tech debt cost. Q: "Why can't we just add the feature?" A: "We can, it'll just be slow and a bit fragile, because we're building on a cracked foundation. Two weeks to shore it up first, or ship faster now and expect more bugs. I'd rather you choose that with eyes open."
  • Security risk to a business owner. Q: "Can't we skip the audit and launch?" A: "We can physically launch, and I'd be nervous. Skipping it means we might be shipping a door we forgot to lock. One week of review buys us a lot of peace. Is the launch date worth the exposure?"
  • Vendor dependency risk. Q: "What happens if that API goes down?" A: "Right now, our checkout goes down with it, because we lean on them entirely. I can add a fallback so we degrade gracefully instead of failing. It's three days. Given they went down twice last quarter, I'd spend it."
  • Explaining "no" without jargon. Q: "Why can't the report be instant?" A: "It's crunching 50 million rows each time you click. Instant would mean pre-computing it hourly, which means the numbers are up to an hour old. Fresh-but-slow or fast-but-slightly-stale: which does the business need?"
  • You are the PM translating for your VP. Q: "Give me the risk in one sentence." A: "One sentence: it'll work, but if the vendor is slow, our page is slow, and we don't control that yet. The fix is scoped and it's three days. I'd fund it."
  • Scaling risk before a launch. Q: "Can it handle the Super Bowl traffic?" A: "At today's setup, no, it'd fall over around 10x normal load. I can get it to 50x with a week of prep and a load test. Without that week, I can't promise it stays up during the spike."
  • You are the CTO briefing the board. Q: "Is our infrastructure safe for launch?" A: "At current scale, yes. At launch-day scale, we need a week of load testing first, which is funded and scheduled. I'll flag immediately if that timeline slips."
  • You are the eng lead giving a go/no-go. Q: "Are we clear to ship tonight?" A: "No-go from me. We have no rollback for the migration step yet. Give me until tomorrow to add one and it's a clean go."

👉 Scope and workload disputes stay mostly inside your team. The next set moves into the harder rooms: live incidents and the cross-team friction that comes with them. On to Chapter 53.