4 exercises — polite disagreement, "Yes, and" technique, interrupting to clarify, and steering off-topic discussions back to the agenda.
0 / 4 completed
Technical discussion language
Disagree: "That's interesting. My concern would be [specific issue] because [reason]."
Build on: "Yes, and another dimension of this is…"
Interrupt: "Sorry to jump in briefly — I want to make sure I follow…"
Steer back: "Worth a separate session — for now can we focus on [specific decision]?"
Stay humble: "I might be missing something — what's your thinking on…?"
1 / 4
A colleague proposes using a NoSQL database for the new feature. You disagree — you believe a relational database is a better fit. Which response is most professional?
Option C demonstrates the professional disagreement framework:
Acknowledge first: "That's an interesting direction" — you've heard them; you're not dismissing the idea Name your specific concern: "data consistency" and "our data has a lot of relationships" — not just "I don't like it" Propose investigation, not conclusion: "Could we walk through the schema together?" — opens dialogue Stay intellectually humble: "I might be missing something about the access patterns" — acknowledges you could be wrong
Why the others fail: A — Blunt rejection without reasoning; shuts down the conversation B — "Not sure I agree" is fine but "have you considered?" can sound condescending D — Arguments from tradition ("we've always done X") are the weakest form of technical argument; they prevent improvement
The disagreement framework: 1. Acknowledge → 2. Name specific concern → 3. Provide evidence or logic → 4. Invite dialogue
"That's an interesting point. My concern would be [specific issue] because [specific reason]. What's your thinking on [the key question]?"
2 / 4
A colleague suggests using microservices for the new project. You want to build on their idea by adding a related point about service discovery. Which phrase works best?
Option A uses the "Yes, and" technique for building on suggestions:
"Yes, and" structure: • "Yes" — explicitly affirms the previous idea • "and" — adds to it at the same level (not replacing, correcting, or redirecting) • Adds value: names specific tools (Consul, Kubernetes DNS) — not just naming the problem
Why the others fail: B — "That's OK" is a weak acknowledgement; "but" signals that you're about to invalidate what they said, even if you're not C — "I already thought of that" is ego-driven; it makes it about you being smart rather than advancing the idea D — "People forget" implies your colleague hasn't thought it through; unnecessarily condescending
Building-on phrases for technical meetings: • "Yes, and another dimension of this is…" • "Building on that — if we go in that direction, we'd also want to consider…" • "That connects well to something I was thinking: what if we also…" • "I like where you're going. One additional piece would be…"
3 / 4
Two colleagues are in a technical debate and you need to ask a clarifying question. Which phrase politely interrupts without derailing the conversation?
Option C is the ideal polite interruption technique in technical discussions:
Apologise for interrupting: "Sorry to jump in briefly" — signals awareness that you're cutting in State the purpose: "I want to make sure I follow" — frames it as clarification, not challenge Ask a specific, high-value question: Offers two concrete interpretations and explains exactly why the distinction matters ("changes the UX implications significantly")
Why your interruption is justified here: A confusion about "eventual consistency" meaning seconds vs. minutes is architecturally significant. Letting the debate continue without clarifying this could mean 20 minutes of discussion about the wrong problem.
Polite interruption phrases for technical meetings: • "Sorry to cut in — quick clarifying question…" • "Sorry to jump in briefly — I want to make sure I follow before we go further…" • "One second — I think there might be a definition question here that affects the whole discussion…" • "Before we go further — can we align on what we mean by [term]?"
When to interrupt: When a key term is ambiguous, when two people are clearly talking about different things, or when you need a definition to follow the discussion meaningfully.
4 / 4
A technical discussion about caching has drifted into a general conversation about performance optimisation. You need to bring it back to the original topic. Which phrase steers it most effectively?
Option B demonstrates expert meeting steering with the park-and-refocus technique:
Doesn't dismiss the drift: "We have good material here on performance optimisation in general" — validates the theme, doesn't make people feel they wasted time Suggests a future home for it: "Worth a separate session" — the topic isn't dead, just moved Refocuses specifically: Names the exact decision that needs to be made (Redis vs. Memcached for session storage) Sets urgency: "before the end of the meeting" — reminds people of the time constraint driving the refocus
Why the others fail: A — "Please stop going off-topic" sounds scolding; makes people defensive C — Ending the meeting abandons the agenda item entirely D — "Stick to that" is directive without being warm; can create resentment
Park-and-refocus phrases: • "That's a great discussion — can we add it to our parking lot and come back? Right now we need to decide on X." • "I'd like to bring us back to the original question…" • "Worth a separate meeting on that — for now can we finish on [specific topic]?"