Feedback in Both Directions
Feedback that lands is specific, about the work rather than the person, and says what effect it had — and you ask for it the same way: about one piece of work, with one concrete question.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
How do you give feedback someone can act on, and get feedback that is more than "looks good"?
A teammate's pull request adds the saved-cart reminder email. It works, but it sends even when the saved item has sold out. Separately, in your one-to-one, your manager asks "Any feedback for me?" — and you would like honest feedback on your demo last week.
Keep it kind and general to avoid friction: "Nice work, maybe think about edge cases." When asked for feedback, say "All good". When you want feedback, ask "Any feedback?"
"Maybe think about edge cases" cannot be acted on: which case, and what happens? The sold-out email ships, customers click through to an unavailable product, and support hears about it first.
- "Maybe think about edge cases" cannot be acted on: which case, and what happens? The sold-out email ships, customers click through to an unavailable product, and support hears about it first.
- Generic praise teaches nothing either. "Great job" does not tell someone what to do again.
- "Any feedback?" gets "No, all good" because answering it honestly means the other person has to find something, phrase it, and risk the relationship — all on the spot.
- Feedback about the person — "you are careless with edge cases" — triggers defence, and the conversation turns into one about identity instead of about the email.
- Saving it for the performance review means it arrives months late, when the work is long shipped and nobody can do anything with it.
What is really going on
- Feedback someone can act on has three parts: what specifically happened (something observable), the effect it had on customers, the team or the outcome, and a suggestion or a question.
- About the work, not the person. People can change an email, a demo or a document. Claims about who someone is invite defence, and defence ends the conversation.
- The effect is what makes it more than taste. "I would have named it differently" is preference. "Customers whose item sold out still get the reminder, and land on an unavailable product" is a consequence anyone can check.
- Asking works the same way in reverse. A specific question about one piece of work lowers the cost of honesty: "Was the question at the end of my demo clear enough to decide on?" is easy to answer truthfully; "Any feedback?" is not.
- Praise uses the same shape. Specific praise tells people what to keep doing, and makes the critical feedback credible because it shows you were paying attention.
Three parts: what happened, the effect, the ask
Most unhelpful feedback is missing one of the three parts. Without the observable thing, the person does not know what you mean. Without the effect, it reads as taste. Without the suggestion or question, they know something is wrong but not where to start.
A teammate's pull request adds the saved-cart reminder email. It is clean and tested, but the email sends even when the saved item has since sold out.
"Looks good overall! Maybe think about edge cases a bit more?"
"Blocking: if the saved item has sold out since, the reminder still sends, and the customer clicks through to a product they cannot buy — that will reach support. Suggest checking stock at send time and either skipping the email or saying the item is gone. The template work is really clean, by the way; the rest below are nits."
1blocking: must change before merge — says what breaks and for whom2should: worth changing, author decides — says why3nit: preference, safe to ignore4question: I do not understand this yet — not a request to change itAgreeing these as a team is what lets one blocking comment stand out among twenty nits.
Praise has the same shape
Specific praise is the cheapest improvement a team can make. It tells people what to repeat, and it shows you look closely enough that your criticism is worth listening to.
Great job on the follow-up!
Your follow-up after the review had the decision in the first line and the other feedback as a list underneath. Finance did not have to ask what was decided, and the sold-out link went straight to the backlog. I would like us all to do that.
The first feels nice and changes nothing. The second names the behaviour and its effect, so the teammate knows exactly what to repeat and the rest of the team learns it too.
Asking for it the same way
When you ask for feedback, you set the price of honesty. "Any feedback?" asks the other person to find something, phrase it, and risk the relationship, all at once, so they say "all good". A narrow, concrete question does most of that work for them.
You ran the saved-cart demo on Thursday. Finance seemed to drift in the first few minutes. Your manager was there.
"How do you think the demo went? Any feedback?"
"Two questions about Thursday. Was the retention question at the end clear enough to decide on? And if you had to cut one minute from the start, which one would it be?"
Upward, and on the receiving end
Feedback to a manager uses the same shape, framed around the work or the process you share rather than their character. It works best in private and ahead of the next occurrence, not in a group retro after it.
Receiving is the other half. The reply to feedback decides whether you get more of it. Thank them, ask one clarifying question, do not defend in the moment, and later tell them what you changed — or why you did not.
Your manager asks in your one-to-one. At Thursday's review the agenda was reshuffled at the start and your demo was cut short before the decision.
"No, all good, thanks!"
"One thing. On Thursday the agenda changed at the start and my slot lost five minutes, so we ran out of time before the retention decision and had to chase it by email. Could we fix the order a day ahead next time, or protect the last five minutes of each slot for the ask?"
How to do it
Most important first.
- Give it soon and close to the work: in the pull request, the day after the demo, not in a quarterly review.
- Use the shape: observable thing, effect, suggestion or question. "The reminder sends when the saved item has sold out; the customer clicks through to an unavailable product. Could we check stock at send time?"
- Mark severity in reviews so the one thing that matters is not lost among preferences: blocking, should, nit.
- Praise specifically: "The follow-up you sent after the review with the decision in the first line meant finance did not have to ask. Do that every time."
- Ask for feedback on one thing, with a concrete question, and ask for the critical version: "If you had to cut one minute from my demo, which one?"
- When receiving, thank them, ask one clarifying question, and do not defend in the moment. Decide later what to act on — and tell them what you did with it.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- In the code review: "Blocking: the reminder email sends when the saved item has sold out, so the customer clicks through to an unavailable product. Suggest checking stock at send time and skipping or changing the email. Everything else below is a nit — take or leave."
- Upward, in the one-to-one: "Yes, one thing. At Thursday's review the agenda changed at the start and my slot lost five minutes, so we did not get to the retention decision. Could we fix the order in advance next time?"
- Asking for it: "On my demo — was the question at the end clear enough to decide on? And if you had run it, what would you have cut?"
- Receiving it: "Thanks. So the architecture part lost finance — would a link in the follow-up have been enough for the people who wanted it?"
- "Just approve it, it is a small PR." One thing is blocking, and it will reach customers. Everything else I have marked optional.
- "I do not have any feedback, it was great." Thank you. If you had to cut one minute of it, which minute?
- "That is just your opinion." Some of my comments are, and I have marked them as nits. This one is not: here is the case where a customer gets the email for a product we cannot sell them.
What can go wrong
- The sandwich — praise, criticism, praise — which teaches people to ignore the praise and brace for the middle.
- Too many points at once. Forty nits on a pull request bury the one blocking issue.
- Specific but about the person: "you always…", "you never…".
- Asking for feedback and then arguing with it. People learn quickly and stop giving it.
- Giving in public what should have been private, especially anything about how someone handled a meeting or a colleague.
- "Being specific means being blunt." Specific is about precision. The tone can be as warm as you like.
- "Feedback to your manager is out of place." Managers usually get the least feedback of anyone on the team, and the process problems they own are ones you see first.
- "Nobody gave me feedback, so it was fine." Silence usually means the question was too expensive to answer honestly.
Knowing whether it worked
- The feedback you give gets acted on without a second conversation to explain what you meant.
- When you ask, you hear something specific you did not already know.
- People start asking you for feedback on particular pieces of work.
- Review threads get shorter because the blocking issue is obvious, and the reminder email that would have gone to sold-out items never generates a support ticket.
- On a large team, code review becomes the main feedback channel, and shared conventions — severity prefixes, what counts as blocking — matter more than individual tone (Done Means Someone Used It).
- Across cultures the comfortable level of directness varies a lot. The shape — observable thing, effect, suggestion — travels better than any particular tone.
- Across time zones, feedback is mostly written, where tone is easy to misread and specificity does most of the work.
- Specific feedback takes longer to write than "looks good", and much longer than approving.
- Naming the effect can feel harsh even when it is kind. It is clearer, and less comfortable, for both of you.
- Asking for the critical version means hearing it. That has a cost, and it is the cost of getting better.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALThe shape — observable thing, effect, suggestion — holds for code review, design critique and feedback on meetings alike. How direct the wording can be varies by culture and team, and should be adjusted without dropping the specifics.
- ROLE-SPECIFICFeedback to a peer can be about the work directly. Feedback upward works best framed around the process or the outcome you share; a manager may also need it in private and in advance rather than in a group retro.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.