Crucial Conversations — Presenting Difficult Things¶
Prerequisites: Growth Mindset, Standing Your Ground, Professionally
← Growth Mindset | Previous: Standing Your Ground, Professionally | Next: Protecting Your Sanity
Why This Exists¶
Standing Your Ground covers disagreeing with someone above you. This page covers something adjacent and, for most engineers, harder: being the one who has to deliver the hard message — telling a teammate their code isn't ready, telling a peer their pet project is being cut, telling your own manager a deadline they've already promised externally isn't real, telling a report their performance isn't where it needs to be. The instinct under discomfort is to soften the message until it's unclear (which fails the listener, who leaves not understanding what actually happened) or to over-correct into bluntness that reads as an attack (which fails the relationship, and often gets the message rejected on tone before the substance is even heard). Neither extreme actually communicates. The skill is a specific middle path, and it's learnable — it's not a personality trait some people have and others don't.
The Core Structure: Facts, Then Impact, Then the Ask¶
The single most common failure in a hard conversation is leading with the conclusion instead of the evidence — "this isn't working" lands as a judgment with nothing to engage with. Leading with the specific, observable facts, then the impact, then what you want to happen, gives the other person something to actually respond to rather than something to just absorb or defend against.
WEAK STRUCTURE STRONG STRUCTURE
─────────────── ─────────────────
Conclusion first Fact first
"Your code quality has been "The last three PRs you've
a problem lately." merged each needed a
follow-up hotfix within
Vague, unfalsifiable, reads a week — the auth-token
as a character judgment one, the pagination one,
and last Tuesday's rate-
No specific incident to limiter change."
anchor a response to
Specific, checkable,
impersonal — describes
events, not character
Then impact: "Each of
those cost the on-call
rotation a weekend fix."
Then the ask: "I want to
figure out together what's
different about these three
— rushed review, unclear
requirements, something
else — so we can fix the
actual cause."
Worked Example 1: Telling a Teammate Their Code Isn't Ready¶
Situation: A peer has submitted a PR they're visibly proud of, three days before a deadline they care about, and it has a real architectural problem — not a nitpick.
Weak version: "This isn't going to work, we need to redo the approach." — True, but it gives the author nothing to hold onto except that their three days of work is being rejected. It also doesn't distinguish "wrong" from "wrong for a specific, nameable reason."
Better version, worked out loud:
"I want to walk through something before you put more time into this, because I think there's a real gap and I'd rather flag it now than after more work goes in. The approach writes directly to the primary on every request — for the current traffic, that's fine, but the ticket mentioned this feeding the recommendation pipeline eventually, and at that volume this write pattern would saturate the primary. Is that pipeline integration still in scope for this quarter, or did I misread the ticket? If it is, I think we need a queue in front of this before it ships, even though that's more work than what's here now. If it's genuinely not in scope yet, I'd want that written down somewhere so whoever picks this up later doesn't hit the same wall."
Why this version works: it names the specific mechanism (write pattern, primary saturation under a stated future load), it asks a real question instead of assuming ("is that still in scope"), and it separates the code from the person — nothing in it implies the author is bad at their job, only that a specific assumption needs checking. It also gives the author an honest way to be right ("if it's not in scope, that's fine, just document it") rather than a binary of correct-code or rejected-work.
Worked Example 2: Telling Your Manager a Committed Date Isn't Real¶
Situation: Your manager has already told a director a feature ships in three weeks. You've just found out the actual remaining work is closer to five.
Weak version: waiting until week three to say "we're not going to make it" — technically honest, but it removes every option your manager had to manage the date, and it reads as you sitting on bad news.
Better version, said as soon as you know:
"I want to flag something now while there's still room to do something about it, rather than closer to the date. I've scoped the remaining work and I think it's closer to five weeks than three — the two things that grew are the migration script, which needs to run in batches to avoid locking the table under load, and the rollback plan, which didn't exist yet and I don't think we should ship without one given what this touches. I know you've already committed three weeks externally, so I wanted to bring you the gap early enough that you have options — pull in help, cut scope, or renegotiate the date — rather than finding out in week three when the only option left is missing it visibly."
Why this version works: it's delivered at the earliest possible moment (the single highest-leverage move in any hard-news conversation — see the box below), it names the specific two things that grew, and it explicitly hands the manager options instead of just the bad news, which respects that managing the external commitment is their job, not yours.
Timing is the highest-leverage variable in every one of these conversations
The exact same hard news, delivered two weeks earlier, is a manageable problem with several available responses. Delivered two weeks later, out of a mistaken instinct to "be sure" before raising it, it's often a crisis with only bad options left. If you're weighing whether you have enough certainty to raise a concern, weigh it against the cost of being two weeks later — in almost every real case, an 80%-confident flag raised early beats a 100%-confident flag raised late.
Worked Example 3: Delivering Critical Performance Feedback¶
Situation: A report has been missing details in their work consistently — not catastrophic, but a pattern that's starting to cost the team review cycles.
Weak version: "You need to be more careful with your work." — Vague enough that the report can't act on it, and vague enough that it reads more like a mood than a fact.
Better version, worked out loud:
"I want to talk about a pattern I've noticed over the last month, not any one thing. In the last four PRs, three had a bug in the edge case for empty input — the search one, the export one, and yesterday's filter change. I don't think this is about skill; I think it's about the review step before you submit — are you testing the empty/edge case yourself before it goes up for review, or relying on review to catch it? I ask because if it's the former, that's a five-minute habit change. If it's something else — feeling rushed, unclear on what 'done' means for these tickets — I'd rather know that, because the fix is different."
Why this version works: three specific instances, not a mood; an explicit statement that it's not read as a skill judgment (which lowers defensiveness enough for the actual conversation to happen); and a genuine, open question about the cause rather than an assumed one — because the fix for "rushed" and the fix for "unclear on scope" are different, and guessing wrong wastes the conversation.
When You're On the Receiving End¶
The same structure helps you receive a hard message well, which is its own skill and matters just as much for your reputation:
- Resist the urge to respond to the conclusion before you've heard the facts. If someone opens with "I'm concerned about the quality of your recent work," the reflex is to defend immediately — wait for the specifics, which are usually more narrow and more actionable than the opening sentence made it sound.
- Ask the same question you'd want asked of you: "is this a pattern you've seen once, or several times?" — this isn't deflection, it's genuinely useful information for figuring out whether this is a one-off or something to actually change.
- Say what you're taking away, out loud, before the conversation ends. "So the concrete thing is testing edge cases myself before submitting, and let's check back in two weeks" closes the loop and prevents the same vague feeling on both sides resurfacing without anyone being sure whether anything actually got resolved.
Interview Questions¶
Q: Tell me about a difficult conversation you had to initiate with a peer or teammate.
"I had to tell a teammate their PR, which they'd put real effort into, had an architectural problem that would cause issues once we hit the traffic the roadmap called for. Instead of saying 'this needs to be redone,' I named the specific mechanism — the write pattern would saturate the primary under the volume the recommendation pipeline was supposed to bring — and asked whether that pipeline work was actually still in scope, since maybe I'd misread the ticket. It turned out I hadn't, and rather than defensiveness, we ended up scoping in a queue together. Leading with the specific mechanism instead of the conclusion is what made it land as a technical conversation instead of a personal one."
Q: Describe a time you had to deliver bad news early, before you were fully certain, rather than waiting until you were sure.
"I discovered a scoping gap on a project my manager had already committed a date for externally — I was maybe 80% sure the remaining work was two weeks longer than planned, not 100% sure. My instinct was to keep investigating until I was certain before raising it, but I recognized that the cost of being wrong by raising it early (a slightly awkward 'actually, nevermind' conversation later) was much smaller than the cost of being right and having waited (my manager losing all their options to manage the external commitment). I flagged it immediately, with my confidence level stated honestly — 'I think this, I'm not fully certain yet, but wanted you to have it now rather than later' — and that gave my manager two extra weeks to negotiate the date before it became a crisis instead of a heads-up."
Q: How do you coach managers on your team to deliver hard performance feedback well, rather than either avoiding it or delivering it in a way that damages the relationship?
"I teach the same structure I use myself: facts before conclusions, a genuine question about cause before an assumed fix, and timing as early as the pattern is real rather than waiting for a formal review cycle to make it 'official.' Concretely, I'll role-play the actual conversation with a manager beforehand if it's a hard one — not the general advice, the specific sentences — because most people know the principle 'be specific, not vague' abstractly but freeze on the actual phrasing in the moment, and rehearsing the opening sentence once removes most of that freeze.
I also explicitly separate two failure modes I see managers fall into, because the fix is different for each: the manager who avoids the conversation until it's a crisis (needs practice on timing and a lower bar for 'is this worth raising yet'), and the manager who delivers feedback as a character judgment rather than a specific, actionable pattern (needs practice on the fact-first structure specifically). Watching which failure mode a given manager defaults to lets me coach the actual gap instead of giving generic 'have more difficult conversations' advice that doesn't address either one."
Key Takeaways¶
Remember
- Lead with specific, checkable facts — never with the conclusion. "The last three PRs each needed a hotfix" gives someone something to engage with; "your quality has slipped" gives them only something to defend against.
- Timing is the highest-leverage variable. The same news delivered early is a manageable problem with options; delivered late, out of a desire to be fully certain first, it's often a crisis with only bad options left.
- Ask a genuine, open question about the cause before assuming one. The fix for "rushed" and the fix for "unclear on scope" are different — guessing wrong wastes the conversation.
- Explicitly separate the behavior from the person's character, out loud if needed — it measurably lowers defensiveness and is usually also just the more accurate read.
- Close the loop by stating what was actually agreed, out loud, before the conversation ends — otherwise both people can walk away with a different sense of what just happened.
Previous: Standing Your Ground, Professionally | Next: Protecting Your Sanity