4 exercises — making requests without formal authority, influencing senior peers, rallying cross-functional teams, and raising technical disagreements assertively.
0 / 4 completed
Persuasive language principles
Requests without authority: Name why this specific person, reduce perceived effort, provide a reciprocal benefit, ask for a concrete time slot
Influencing senior peers: Validate the current approach first → name a specific measurable problem → scope the proposal narrowly → invite critique explicitly
Cross-functional influence: Open from their perspective → de-risk the change for them specifically → do the work for them → ask for inputs, not agreement
Technical disagreement: Name the exact location + evidence → propose an alternative → close with a question, not a declaration
"I might be missing context — tell me if I am" + specific concern = assertive without adversarial
1 / 4
You need a colleague from another team to review your security design before a launch. They are busy. How do you make the request persuasively?
Option C is a persuasive request without authority because it:
1. Opens by naming the ask and acknowledging their time constraint: "I have a favour to ask, and I want to respect your time" — signals you won't waste their time 2. Gives a specific reason why this person: "based on our last conversation about token rotation, you'd spot issues I wouldn't" — flattery grounded in actual expertise, not generic praise 3. Reduces the perceived effort: "45 minutes async, not a call — two-page summary with decisions marked, not the full spec" — eliminates two of the largest effort barriers up front 4. Provides a reciprocal benefit: "named security reviewer in the launch ticket = performance record" — incentive that costs you nothing 5. Closes with a specific ask: "Thursday or Friday?" — easier to say yes to a concrete window than a vague "when you have time"
Why A fails: "When you have time" = never, especially for a busy person with their own deadlines
Why D fails: Framing as a requirement when you have no actual authority creates resentment
2 / 4
Your team wants to change the API versioning strategy, but a senior engineer strongly prefers the current approach. How do you make your case without triggering defensiveness?
Option C makes a case to a senior peer without triggering defensiveness by:
1. Starting by validating the current approach: "has worked well and I understand why it was chosen" — not "the old way was wrong" but "the old way was right, AND here's a new problem" 2. Naming a specific, measurable problem with the current approach: "35% of clients still on deprecated version at 90 days → three blocked internal migrations" — you're not criticising the architecture, you're naming a downstream operational problem 3. Scoping the proposal narrowly: "mobile API surface only — not a wholesale change" — reduces the perceived stakes and makes it easier to agree to explore 4. Explaining the mechanism, not just the claim: "header versioning allows server-side migration without client deploys" — shows you understand the technical argument 5. Explicitly inviting critique: "Do you see constraints I'm underweighting? I may be missing something" — expresses genuine openness, which makes the senior engineer more willing to engage constructively rather than dismiss
Why A fails: "The current approach is wrong" is a direct challenge that causes defensiveness
Why D fails: "Industry standard" is an appeal to authority — for a senior engineer, this often triggers the opposite reaction
3 / 4
You need to influence a cross-functional team to adopt your proposed database schema change, but you have no authority over them. How do you structure the request?
Option C effectively influences without authority by:
1. Opening from their perspective: "this affects all three of your services and I don't want to create unplanned migration work" — the first sentence is about them, not about you 2. Explaining the motivation with specifics: "p99 latency above 800ms on preference-filtered queries" — not "performance is bad" but a measurable, specific symptom 3. De-risking the change for them specifically: "60-day parallel read window, no same-day cutover" — removes the largest objection (forced synchronous migration) before it's raised 4. Doing the work for them: "migration guide with example queries for your three services" — dramatically lowers resistance by removing effort 5. Making a minimal, specific ask: "Does the migration path work for your schedule? Are there edge cases?" — not "agree to this" but "tell me what I'm missing" — positions them as collaborators, not opponents 6. Explicitly deferring the decision: "Not asking for agreement today" — no pressure, lower resistance
4 / 4
You disagree with a technical decision made by a more senior engineer in a code review. How do you raise this diplomatically but assertively?
Option C raises a technical disagreement assertively but constructively:
1. Opens with epistemic humility without abandoning the concern: "I might be missing context, so tell me if I am" — not sycophantic capitulation but genuine openness, while still fully proceeding with the concern 2. Names the exact location of the issue: "lines 34–67" — not vague criticism, but specific enough that the senior engineer can evaluate the claim immediately 3. Uses observed data for the scenario: "p99 latency ~1.8 seconds, 20–30 concurrent requests" — grounded in real system behaviour, not hypothetical 4. Names the failure mode specifically: "thundering herd — sequential execution extending spike from seconds to minutes" — advanced technical framing demonstrates you understand distributed systems 5. Proposes a concrete alternative: "narrow the lock scope to lines 78–84, handle idempotency separately outside the lock" — not just criticism, but an actionable path 6. Closes with a question, not a declaration: "Am I reading the lock scope correctly?" — invites correction or confirmation, either of which advances the conversation