The Polite Way To Avoid a Hard Conversation
How feedforward gets misused by managers who mean well
Here’s a familiar scene for anyone who manages people. Something has gone wrong with a team member’s work, like a missed deadline, say, or a client meeting that didn’t land. And you know you need to raise it. You sit down with them, and somehow the conversation ends up being about general development, or how similar situations might be handled in future, rather than about the thing itself. The meeting ends on a positive, polite note. You walk back to your desk feeling lighter, while the team member is left trying to work out what the conversation was actually about.
🎥 The idea for this piece came from a live Jen and I did a few weeks ago - take a look at the recording if you’ve missed it!
Why feedforward works, and why that’s also the problem
Feedforward, in Marshall Goldsmith’s framing, asks you to offer or invite suggestions about future behaviour rather than judgements about past behaviour. The structure is straightforward: you pick a behaviour you want to develop, you ask one or two people for suggestions on how you might do it differently in future, you listen without defending or explaining and you say thank you. The technique was originally designed for executive coaching, but it has spread into ordinary management practice, where it sits comfortably alongside coaching conversations and routine one-to-ones.
The legitimate case for feedforward is strong. It lowers defensiveness, because there is nothing to defend yet. It is easier on both parties, because no one has to deliver a judgement about something the other person did. The suggestions can even come from people who weren’t present at the original event, which makes it scalable in a way that traditional feedback isn’t. And it fits routine skill development well. Think of a manager wanting to be a better listener, or an analyst trying to be clearer in writing.
By moving the subject of the conversation into the future, feedforward removes the thing people defend (their past behaviour) and the thing people find hard to give, which is a judgement on someone else’s past behaviour. Both sides relax, so useful suggestions can get exchanged.
The difficulty is that the same mechanism that strips out friction in a development conversation also strips out accountability when accountability is what’s required. When something specific has gone wrong (imagine a missed deadline or a mishandled client), the future-oriented frame removes the very thing that needs to be acknowledged. The technique can become a way of gesturing at the problem without dealing with it, and the gesture is often enough for the giver to feel they have addressed it.
What avoidance looks like
Each of the patterns below arises from a legitimate feature of the technique. What turns them into a problem is when people reach for them when a different conversation would have been more appropriate (and honest!). And it is worth being clear about who pays for avoidance: taking away feedback conversations deprives the team member of clear and specific information that they need to make sense of what happened and to do something different next time.
Here are four patterns worth being aware of.
The first, and most common, is the pre-emptive pivot. Something specific has gone wrong, and the manager knows they need to address it, but instead of opening the meeting with the incident, they open with a generic developmental frame: “I want to try something new with the team”, or “I’ve been thinking about how we all handle client conversations.” By starting in general terms, the manager has effectively ruled the specific event out of bounds for the rest of the conversation, because raising it now would mean abandoning the frame they have just set up.
The second is the suggestion that only makes sense if you know the incident behind it. The giver offers something like “in the meeting coming up, try giving the client more space to speak”, phrased as a general developmental tip. The plausible deniability becomes the feature the giver is leaning on, consciously or otherwise.
The third is temporal vagueness. Suggestions get framed for “stakeholder conversations going forward” rather than “the next time you meet with this client”, or for “team meetings generally” rather than “the standup last Tuesday.” The vagueness lets the giver avoid any reference point that would require them to talk about a specific event where things went wrong.
The fourth is the group-setting deflection. A manager who has noticed something specific in one person’s behaviour brings it up in a workshop or a team development conversation, framed as something the whole team could think about.
In all these cases, the receiver can usually work out what the conversation is really about, often within the first minute. They know which meeting, which deadline, which incident is sitting underneath the generic framing, and they know the manager knows it too. What they cannot do is name it themselves, because the structure of the conversation has been set up to keep it unspoken.
They will spend the meeting decoding rather than learning.
This is where the no-defending rule, which is protective in genuine development conversations, can close off the conversation that was actually needed. The receiver cannot say “wait, is this about Thursday?” without breaking the frame the manager has established and risking looking defensive in the process. The structure of the feedforward technique can silence the question the receiver most wants and needs to ask, which is “what actually happened, and what did you make of it?”
There is a consistent signal in how people feel afterwards. Feedforward done well tends to leave the people involved slightly energised, because something useful has been exchanged and there is a shared direction for future improvement. Feedforward done as avoidance leaves the giver feeling relieved in a way that has more to do with what they dodged than what they offered. And it makes the receiver, as well as any colleagues who might have been involved, feel unfairly targeted and at a loss.
Why managers slide into this
It helps to understand what makes the avoidance feel necessary, because the pull is real. Direct conversations about specific events carry a risk of being wrong, and can be genuinely uncomfortable. The manager may have only heard one side, may have misjudged what happened, or may not have all the context. Feedforward, by staying in the realm of future suggestion, sidesteps that risk entirely. The manager never has to commit to a reading of the event, and never has to be corrected on it.
There is also the modern preference for psychological safety, which has been one of the more useful developments in management thinking over the last decade. It can, however, be misread as a prohibition on hard conversations rather than a foundation for them. A manager wanting to be supportive, non-judgemental and developmental can find themselves, over time, never quite saying the thing.
Time and preparation play a part as well. A direct conversation about a specific incident takes work. You have to think about what happened, what you want to say, how the other person might respond, where you might be wrong, and what you want to be different afterwards. A feedforward exchange takes far less. If the calendar is full, the technique that requires less preparation tends to win. And the calendar is almost always full.
None of this makes the avoidance acceptable, but it does make it understandable. Recognising the pull helps you notice it in yourself before the meeting rather than after.
The Art of Asking Questions is a reader-supported publication. To support my work, please consider becoming a paid subscriber.
Two versions of the same conversation
To make this more concrete, it helps to look at how the same situation can unfold in two different ways. This is where we bring in Jennifer Houle’s fantastic ‘professional storytelling’ skills.
The setup is identical in both cases.
Earlier in the week, Ezra was in a client meeting that didn’t go well. He interrupted more than he should have, missed a key concern the client was trying to raise, and the meeting ended with the client visibly cooler than they had been at the start. His manager, Hannah, was in the room. She wants to speak to him about it.
Here’s a first version of what happens next:
Hannah opens the conversation by saying she wants to try a different approach to development, and asks Ezra to think about how he might handle stakeholder conversations more effectively going forward.
She frames it positively. She tells him he brings energy into client conversations and that, with a few adjustments, he could be even more effective. She suggests pausing more, asking an extra question before responding, and giving space for the client to finish their thought.
There is nothing inherently wrong with this approach, but it becomes clear almost immediately that Hannah is reacting to something specific, even though she never specifies what Ezra did or when it happened. She circles the issue without letting it surface. Ezra picks up on it quickly. Instead of engaging with what is being said, he starts trying to map the suggestions back to particular moments in the meeting, working out which ones Hannah is referring to, which ones she is annoyed about, and whether the client has complained directly to her. He nods. He agrees the suggestions are useful (How could he not? They genuinely are). He leaves with a list of things to try and no proper understanding of what actually went wrong, or how seriously Hannah took it.
He also leaves slightly diminished, in a way that is hard for him to articulate. He has been spoken around rather than spoken to. The meeting registers as something he needs to manage rather than learn from.
Here’s a second version of the conversation:
Hannah tells Ezra directly that the client meeting didn’t land well. She points to two specific moments where he spoke over the client and moved too quickly past something the client was trying to surface, and she explains the impact it had on the rest of the conversation.
Ezra has space to respond. He describes what he thought was happening in the moment, including a couple of things Hannah hadn’t noticed, and he can also see more clearly than he did at the time where he missed it.
They talk briefly about what the client may have been trying to raise. Only then do they move forward, with Hannah asking what he might do differently next time. She offers a couple of suggestions: pause longer, let the client finish, check understanding before moving on.
The suggestions in the two conversations are identical, and yet they land completely differently. In the first, Ezra is decoding while Hannah speaks, working out what she is really talking about. In the second, he is actually learning, because Hannah has provided a concrete anchor.
A little acknowledgement of what happened can make the advice feel grounded and relevant, and it can help prevent repeating the same mistake. But that acknowledgment does not need to become a post-mortem!
So, when something has gone wrong, the sequence that tends to work is
Name the thing
Acknowledge the impact
Hear the other person’s account of it
Offer or invite future-oriented suggestions.
If you have enjoyed this story, check out our previous pieces below, as well as Jen’s publication, Uncompliant.
How to tell the difference in your own practice
There are three checks we recommend to see if you’re using the feedforward technique appropriately:
1️⃣ A useful first check is the stakes question. If you would comfortably have a more direct conversation about the same kind of behaviour in a less loaded situation, perhaps a hypothetical with a different team member, or a similar issue from six months ago, but find yourself reaching for feedforward in the loaded case, the technique is probably doing a different job than development.
2️⃣ The specificity question is a second check. If you can point to a particular event that is driving the conversation, that event almost certainly needs naming before any future-oriented suggestion will land honestly. A feedforward exchange built on top of an unnamed incident tends to feel to the receiver like being managed, and the difference shows up in how willing they are to take the suggestion seriously afterwards.
3️⃣ A third check is the legibility question. Could a third person sitting in on the conversation work out what it is actually about, with no extra context? If the answer is no, but the answer for both you and the receiver is yes, you are having two conversations at once: a visible one about generic development and a hidden one about the specific event. The hidden conversation is the one that matters, but isn’t the one you’re having.
If you catch yourself through any of these checks, do keep in mind that the recovery move is usually simple. If you notice mid-conversation that you have set the meeting up in a way that won’t let the real issue surface, you can stop and say so. Something like “I realise I’m circling — what I actually wanted to talk about was the meeting on Thursday” works better than people expect. The receiver almost always knew already, and might immediately nod in acknowledgement. This actually tends to lower the temperature in the room rather than raise it, because it confirms what was already there and gives both people something they can actually work on.
If the conversation has already happened and the moment has passed, a short follow-up does the same job. It can be as simple as a message saying you’ve been thinking about the conversation and want to come back to the specific thing, or a fifteen-minute meeting later in the week. The cost of that follow-up is almost always lower than the cost of leaving the unnamed thing unaddressed over the following weeks, where it tends to harden into something neither of you can easily raise.
The conversation you still owe
Management techniques that reduce friction are valuable, but friction sometimes carries information, and removing it can remove valid and important information along with the discomfort.
The same pattern shows up across a lot of modern management practice. Tools designed to make development conversations easier and safer can become tools for not having them. Coaching questions can stand in for honest assessment. Strengths-based language can stand in for telling someone they got something wrong. None of these techniques is at fault. The question is whether the manager using them is doing the harder work the technique was meant to support, or letting the technique do the work of avoidance for them.
Whatever technique a manager uses, the conversation they owe someone remains owed. Feedforward is a useful tool for shaping that conversation once you have committed to having it. It is not a way of getting out of the commitment.
Enjoyed this piece? Become a paid member and get my Consulting with AI prompt library, the full Asking Questions Like a Pro course ($199 standalone), practical templates from a decade of fieldwork, and discounts on many other resources. 🔗 See everything included in the paid tier.
 | A guest post by
|
This was a great read, appreciate you sharing it
This lands. Feedforward is useful when it supports the conversation owed — not when it replaces it.
🥬 Small piece of celery: when leaders avoid the specific hard conversation, they don’t eliminate the discomfort. They transfer it. The receiver pays by decoding, second-guessing, and trying to learn from fog.
The hummus, if we’re willing to reach for it: name the specific event cleanly, separate judgment from dignity, then use feedforward to build the next move.
Clarity is kindness only when it actually arrives. And once it arrives, it earns its keep and then some.