Difficult conversations: a playbook

Your senior developer has been cutting corners on code review for six weeks. Three bugs have reached production. You have mentioned it twice in passing — once in a standup, once in a corridor — and nothing has changed. You know you need to have the conversation properly. You have also been not having it, because some part of you is convinced it will go badly.

That avoidance is not cowardice. It is risk management executed with bad inputs. You are running a mental simulation of the conversation, the simulation keeps ending in defensiveness or awkwardness, and so you delay. The problem is that the simulation is running on a default script — one built from every uncomfortable confrontation you have witnessed or endured. This post gives you a different script.

Why avoided conversations metastasize

A difficult conversation that does not happen does not disappear. It compounds.

In the short term, the other person receives no signal that there is a problem. They continue the behaviour. You watch them continue it and your interpretation of that behaviour darkens — what started as “they are probably overwhelmed” becomes “they do not care” becomes “they are actively disrespecting the team.” None of those interpretations may be accurate. All of them feel increasingly certain.

By the time the conversation does happen — usually under pressure, when the situation has become acute — you are carrying six weeks of compounded frustration. The conversation that could have been calm and curious becomes charged and positional. The other person, who had no idea there was a serious problem, feels ambushed. That is when conversations go badly. Not because they were difficult by nature, but because they were delayed until they became genuinely hard.

The four-step structure

There is a framework from the field of mediation and negotiation research — popularised by the book Difficult Conversations by Stone, Patton, and Heen (Harvard Negotiation Project, 1999) — that gives these exchanges a reliable shape. The model has four moves, and the order matters.

Step one: anchor on the shared goal. Before you state the problem, name what both of you are working toward. “I want us to keep shipping reliable code and I want to make sure we are both set up to do that” is not flattery or softening. It is framing. It tells the other person they are not about to be fired or blamed — they are about to have a professional conversation with someone who is also invested in the outcome. Most people’s defenses lower by about thirty percent before you have said anything contentious.

Step two: state your observation and its impact, without verdict. This is where the conversation lives or dies. The distinction that matters here is between an observation (what you saw or measured) and an interpretation (what you concluded about the person). “Three of the last eight pull requests were merged without the full checklist, and two of those led to production incidents” is an observation. “You have stopped caring about quality” is a verdict. One invites a response. The other invites a defense.

The impact is separate from the observation and needs to be said plainly: “That puts the on-call engineer in a difficult position and it erodes confidence in the team’s releases.” Impact is not emotional blackmail. It is information the other person may genuinely not have, or may not have seen from your vantage point.

Step three: ask for their view and actually listen. This is the step that most people skip or perform badly. They ask “what do you think?” and while the other person is answering, they are composing their rebuttal. Genuine listening here means you might learn something that changes your analysis. The developer may be covering for a colleague who keeps requesting urgent reviews. They may be under pressure you did not know about. They may have been waiting for someone to finally raise this so they can explain what has been going on.

You do not have to agree with what they say. You have to understand it clearly enough that you could argue their position back to them accurately. That is the test.

Step four: solve together, with a concrete next step. Once you have both spoken and understood each other, the conversation moves from past to future. Not “this can never happen again” (a declaration) but “what would help here?” (a problem to solve). The output should be a specific action with a name and a timeline attached — not a vague commitment to “do better.” “You will flag to me by end of Thursday if a review is likely to be delayed more than a day” is a next step. “We will communicate more” is noise.

The opening line problem

The entire structure above can be torpedoed by a bad opening sentence. Consider the difference:

“I need to talk to you about the code review situation because it is becoming a real problem for the team.”

versus

“I wanted to catch up because I think there is something going on with code reviews that we should sort out together.”

The first signals accusation and positions you as prosecutor. The listener is already categorising this as an attack before you have said anything substantive. The second signals collaboration and positions both of you as problem-solvers. The information content is identical. The emotional signal is opposite.

The physiological thing that happens when someone hears a blame-framed opener is real and fast: cortisol rises, working memory narrows, the part of the brain responsible for perspective-taking goes quiet. You can have the most thoughtfully constructed argument ready and it will fall on a brain that is no longer capable of receiving it. The opener determines whether the conversation you prepared for is the conversation you actually have.

Separating intent from impact

One of the most useful concepts in this domain — drawn from the same Harvard research — is the distinction between intent and impact. Most difficult conversations happen because someone’s impact on us was negative, and we have unconsciously assumed that the intent was also negative. We treat impact as evidence of intent.

In most workplace situations, that assumption is wrong. The developer who stopped doing thorough code reviews probably did not intend to create production incidents. They were likely optimising for something else — velocity, avoiding blockers, managing their own workload — and the impact on quality was a side effect, not a goal. Treating it as deliberate sabotage changes the emotional register of everything you say.

Naming the distinction out loud is often enough to defuse a charged conversation: “I am not suggesting you intended this, but the impact has been…” It is not a legal disclaimer. It is an honest acknowledgment that you are talking about observable effects, not character.

What this looks like in an Indian workplace context

In many Indian professional environments there is an additional layer: hierarchy is explicit, and raising concerns upward or laterally requires navigating relationship dynamics that do not exist in the same way in, say, a flat Silicon Valley startup.

If you are a junior engineer and the person whose behaviour needs addressing is a senior colleague or a lead, the shared-goal anchor becomes even more important. It is not presumptuous to want the team to succeed. Framing the conversation as “I wanted to understand something better” rather than “I need to flag a problem” shifts the dynamic from confrontation to inquiry, and inquiry is much easier to receive across a hierarchy.

If you are a manager, be careful with one specific habit that is more common in high-context professional cultures: the indirect hint. The corridor comment, the pointed question in standup, the expectant silence. These register as background noise. The person may genuinely not know they have received feedback. When the situation escalates and you finally have the direct conversation, they will feel blindsided even if you feel like you have been signalling for weeks. Direct does not mean harsh. It means unambiguous.

The conversation you have been postponing

Go back to the developer whose code reviews have been slipping. The conversation you have been deferring is not actually about six weeks of missed checklists. It is about the fact that you do not have a working channel for raising professional concerns with each other. That channel is what you are building when you use this structure.

The conversation might last fifteen minutes. It might surface something you did not know — an unrealistic workload, a misunderstood standard, a process that no one has explained clearly. It will almost certainly be less bad than your mental simulation predicted. And it will stop compounding.

The structure is not a trick. It is just a way of having the conversation that already needs to happen, without the distortions that fear and delay add to it. You already know what you want to say. Now you have an order in which to say it.