Sentence frames for debate: openers, pivots, and pushbacks

Chapter 5 gave you the strategy of disagreement; this chapter gives you the sentences. Debates are steered by their opening words: the frame of a sentence sets its tone before any content arrives, and two sentences with identical content and different frames get opposite receptions. This chapter is a catalog of the frames that do the work, and a repair shop for the ones that misfire.

One example, four fates

Take the thought "Lambda seems like the obvious tool here." Four ways it can leave your mouth:

1. "Why we didn't use a Lambda function?"        (broken)
2. "Why didn't you use a Lambda function?"       (an accusation)
3. "Why didn't we use a Lambda function?"        (an audit)
4. "Why don't we use a Lambda function?"         (a suggestion)

Version 1 is ungrammatical (the word-order clinic below explains why), and the error is expensive beyond grammar: the listener spends attention parsing the sentence instead of the idea. Version 2 is grammatical and radioactive: "you" plus past tense hunts for a culprit. Version 3 fixes the pronoun but still points backward; it asks the team to defend a past decision, which has its place (auditing real history) but starts a review, not a brainstorm. Version 4 is the idiom you want in a design discussion: "Why don't we...?" is not a question about the past at all; it is a standard English frame for proposing something now.

Don't be confused: three near-identical questions, three different speech acts. "Why don't we use Lambda?" proposes (fully interchangeable with "let's consider Lambda"). "Why didn't we use Lambda?" probes a past decision (use it when you genuinely want the history, and soften it with a frame from below, because bare, it can sound like the decision is on trial). "Why aren't we using Lambda?" challenges the present state (it implies the current approach needs defending, the strongest of the three; say it only when you mean exactly that). Non-native speakers who map all three to one question in their head send accusations they never intended.

The word-order clinic

The grammar error in version 1 is the single most common one in non-native technical debate, so it earns its own clinic. English questions invert; embedded questions do not:

FormRuleExample
Direct questionAuxiliary before subject"Why didn't we use Lambda?" / "What does the retry cost?"
Embedded questionStatement order, no inversion"I'd like to understand why we didn't use Lambda." / "Can someone explain what the retry costs?"

The two failure modes are mirror images: inversion missing from a direct question ("Why we didn't use Lambda?") and inversion wrongly kept inside an embedded one ("I wonder why didn't we use Lambda"). The embedded form is worth mastering for a second reason: it is naturally softer. "Help me understand why we went this way" carries the same request as "Why did we go this way?" with the temperature turned down two notches, which is why so many frames below are embedded questions wearing polite verbs.

The catalog: frames by move

Opening a suggestion (forward-looking, invites building):

  • "Why don't we route this through a queue?"
  • "What if we cached at the edge instead?"
  • "Could we split the worker into two pools?"
  • "How about a flag for the first rollout?"
  • "One option worth putting on the table: ..."
  • "It might be worth trying X before we commit to Y."

Stating intent before content. Announcing why you are about to say something disarms the defensive reading of it. The frame is "I'm trying to X, so Y" and its family:

  • "I'm trying to follow the steps that get us to a decision today, so let me push on the two open questions."
  • "I'm trying to make sure we don't repeat the INC-214 pattern, so bear with a paranoid question."
  • "My goal here is to shrink the blast radius, not to relitigate the design; with that framing: ..."
  • "In the spirit of shipping this week: which of these concerns are blocking, and which can follow?"

Intent-first frames are the cheapest de-escalation tool in the chapter: the same objection lands completely differently when the listener knows it comes from schedule worry rather than turf defense.

Probing a past decision (when you really do want the history):

  • "What led us to DynamoDB here?" (the gentlest form; asks for a story, not a defense)
  • "Walk me through the queue choice? I have context on the new constraints but not the original ones."
  • "What did we weigh against this option at the time?"
  • "Was X considered and rejected, or did it just not come up?" (a genuinely useful distinction, and phrased so either answer is safe to give)

Note every one of these uses "we" even if the asker was not there; "what led you to DynamoDB" re-personalizes it instantly.

Pushing back (rungs 3 to 5 of Chapter 5's ladder, as sentences):

  • "I see it differently: ..."
  • "My concern with that is the failure mode, specifically: ..."
  • "The part I can't get past is the cross-region call."
  • "That holds right up until the queue backs up; then what?"
  • "I'd push back on the premise: do we actually have that traffic?"
  • "Strong disagree on this one, and I want to lay out why properly."

Checking understanding before firing (the steelman opener):

  • "If I follow, the goal is strict ordering, and the single queue is what buys it. Fair?"
  • "So the claim is: cost stays flat while p99 halves. Right?"
  • "Before I disagree, let me make sure I'd pass the test of restating your position."

Building and bridging (debate is not only combat):

  • "Building on Ana's point: the same argument covers the write path."
  • "Yes, and it gets stronger if we add the cache layer."
  • "That actually solves my earlier objection; withdrawing it."
  • "Marrying the two proposals: A's storage with B's rollout plan?"

Conceding with precision (partial concessions keep debates honest):

  • "Fair point on the migration cost; where I still land differently is the steady state."
  • "You've moved me on the timeline. The architecture concern stands."
  • "I'll grant the benchmark; my issue is that it measures the wrong workload."

Landing the plane (frames that convert debate into progress):

  • "What would change your mind?" (and its twin, offered unprompted: "here's what would change mine: a benchmark above 500 rps")
  • "Can we agree on the goal and park the mechanism for the spike to settle?"
  • "We've converged on 80% of this. Can I write up the 80 and flag the 20?"
  • "I'd rather be wrong quickly: what's the cheapest experiment that settles this?"

The saboteur words

A few single words reliably sabotage otherwise good frames:

  • "just": "Why don't we just use Lambda?" The word declares the problem trivial and everyone who struggled with it slow. Delete "just" from proposals; the frame works better without it every single time.
  • "obviously" / "clearly": if it were obvious, you would not need the word; what the listener hears is "you are behind." State the point; let it be obvious on its own.
  • "actually" as an opener ("Actually, ...") reads as a correction even when none is intended; inside a sentence it is usually free.
  • "with all due respect" and "no offense, but": universal signals that disrespect or offense is inbound. Say the substance without the flare gun.
  • "as I already said": Chapter 3's passive-aggressive family. Repetition is fine; announcing it is not. Restate the point as if for the first time, perhaps sharper: good arguments survive rephrasing.

The mirror image is over-softening: stacking "maybe we could possibly perhaps consider" until the proposal disappears (Chapter 17's hedging budget). One softener per sentence, then substance.

Weak to strong: a repair table

WeakStrongWhat changed
"Why we didn't use a Lambda function?""Why don't we use a Lambda function for this?"Word order fixed; past-audit became proposal
"Why didn't you cache this?""Would caching help here, or was it ruled out?"Culprit removed; both answers made safe
"This won't scale, I think, maybe.""I doubt this scales past ~500 rps; the pool is the ceiling. Happy to be proven wrong by a benchmark."One hedge, a number, an exit condition
"You need to add retries.""Could we add retries here? Without them, one blip fails the whole batch."Command became request, reason attached
"That's wrong.""I get a different result: with the July numbers it comes out to 3x, not 1.2x. Can we compare inputs?"Verdict became evidence plus an invitation
"I don't like this approach.""My concern with this approach is that the config and the code deploy together."Taste became a nameable, fixable property
"Why don't we just rewrite it?""Why don't we rewrite this module? Genuine question: the patch cost is starting to rival it.""just" deleted; cost argument surfaced

The pattern in the right column never varies: the frame carries respect and direction, the middle carries evidence, and the ending leaves the other person a door (Chapter 5's exit condition, at sentence scale).

👉 Frames are the hand-to-hand layer of design debate; the densest arena for them is code review, which compressed the whole discipline into labels like "nit:", "blocking:", and "LGTM with nits". On to Chapter 7.