Feedback. It's the F word a lot of people are scared to hear at work. You've felt it, haven't you? That dread when someone comes up to you and says "hey, I have some feedback...". Internalizing feedback is an art form and crucial if you want to grow in your career, especially if you want to get to the higher levels.

This post is not about that (look for a follow-up post). Today, we'll cover how to deliver feedback effectively so it lands well with the recipient. Hate receiving feedback? Well, others probably hate receiving yours - and that's something under your control.

Why do people hate feedback, anyway?

There are a lot of valid reasons to fear feedback. Here are some that hit me for a long time:

  • Presumption of failure: It always comes with a negative connotation - your internal fear response kicks in, and you think "oh boy, here's how I messed up". You'll often only ever hear about the things you did wrong.
  • Fearing for your job: You're at work. You messed up. Surely there will be major consequences, right? You're going to get fired and have to hustle to get a new job (or worse). For those suffering from impostor syndrome, you'll find you go from hearing feedback to imagining finding a new job in no time.
  • Taking it personally: It's hard not to take it personally. Someone just told you your work was bad. You must be a failure then, right?
  • Perfectionism: Being told you could do better at something means you're not perfect. This is just a much worse version of the previous point.

I could go on, but in the interest of time, let's stop here. Please let me know of your (least) favorite reason and I can add it here!

Here's a secret. As the person giving the feedback, you can make it hurt less. Read on to learn how.

Avoid giving feedback like this.

Avoid giving feedback like this.

Aside: what is feedback anyway?

Feedback is an overloaded term and means different things to different people. For me, it's about providing useful advice so someone can improve their work.

I believe feedback should often be delivered at the first reasonable opportunity (it lands much better that way). So, after a meeting, project milestone, whatever - just message the person with your feedback, or bring it up in your next 1:1. When it's timely, it is much more actionable - and people can make changes immediately rather than being surprised with a bad review.

Most commonly, though, people wait to deliver feedback until it's time for a 'review' (annual, quarterly, whatever your company does). These are often written and carry a lot of weight, so there is a natural tendency to be nice (so you don't hurt someone's review and compensation). There are two types of feedback that most people will have to write:

  • Peer feedback: What you write for peers you worked with, both within your team and across teams. This is often time-consuming, especially at senior levels, since you likely work with a lot of people!
  • Upward feedback: Feedback you write about your manager. This is often really hard because you're never sure what to write and focus on.

There's also downward feedback (which your manager gives you) - but that's a whole topic on its own.

Elements of great feedback

I could write a thousand-page essay on things to fix or avoid when writing feedback. It's easier to focus on the qualities all good feedback should have, though. Starting with the content first - work on:

  • Specificity: Avoid generalizations at all costs. List the specific instances (tasks, projects, times) you are bringing up to ensure everyone is on the same page. This also helps the receiver jog their memory and put things in context. Talk about exactly what needs to change, and stick to the facts.
  • Clarifying severities: A "you wasted a few minutes in this meeting" is very different from a "you recklessly ignored this safeguard and cost the company $1M". Start your delivery by explaining the severity of the issue. There are going to be times when you will need to give harsh feedback that will make someone fear for their job - but that should be rare, and it should never be a surprise - oftentimes the "your job is at risk" feedback is a repeated warning after N attempts at improvement. The uncertainty is what causes anxiety, and people will be more comfortable knowing you won't surprise them with news like this.
  • Avoiding judgment: Work on your delivery, so the message focuses on the actual work and doesn't blame the person. Report what happened and what impact it had on you; rather than making judgments about the person. Avoid "Hasnain is lazy and bad at time management", go for "Hasnain is often late to morning meetings, leading to clients being frustrated and in some cases switching providers (e.g. client X)".
  • Actionability: It should be clear what change you want the person to make, and when you need it. The worst thing you can do is have a long feedback conversation with someone and they don't realize they need to change anything.
  • Playing up strengths: Saying thanks costs nothing, and makes someone feel better. Give credit where credit is due. This will also help people grow! They will learn what aspects of their work are appreciated and can double down on those things if needed. And people will no longer wince when they hear the F word, as it could be a good thing!

Beyond the content, delivery is also important. You can have a great message but have it land poorly just due to the delivery. Work on:

  • Positive framing where possible: Especially for perfectionists. People often know that they could do better. Make it clear what the expectation was, what they did, and how they could do even better next time, if they so desired/had the time for it. Use phrases like "In the future, Hasnain should look into X to further improve the quality of his work."
  • Timing: Make sure you deliver it at the right time. Don't give it when you're feeling too emotional, or if the recipient isn't ready to hear it. Generally, try to do it as soon as possible - wait a bit for the right time, but don't wait too long.
  • Environment: Make sure the environment is right. Don't give it in an open setting - prefer a more casual/private meeting environment.
  • Grouping by themes: Instead of providing a laundry list of improvement items, try to group things into related themes - so you can say things like "Work on your engineering skills; in particular example X highlights the importance of testing, example Y does Z", etc.
  • Avoiding the shit sandwich: The shit sandwich is a technique where you give some positive feedback, squeeze in the critical feedback, and end with more positive feedback. In my experience this goes one of two ways: people ignore the positive feedback, or they miss that there is an area for improvement. I'm not sure which is worse.
  • Practicing your delivery: I struggle to deliver hard messages verbally without preparation. If that describes you, try writing down the message, practice speaking it a few times, and then go into the meeting where you say it out loud.
  • Tailoring the message: The message should always be tweaked for the intended audience. Focus on themes they care about, and tie your feedback to their own goals so it resonates better.

Finally, you can make a lasting difference in how your feedback is received through this one simple trick: caring about the other person. Offer to explain the feedback in additional detail, and offer to follow up with them regularly to see how it's going and if they need help. It does wonders.

Additional strategies for peer feedback

Before writing peer feedback, I often do some prep work:

  1. Ask the person if there is anything specific they would like me to focus on - sometimes they just want a critique of their work on project X; or strategies for improving skill Y, etc.
  2. Go over our work history together over the last period - I try to keep copious notes and often write the review throughout the year, in bits and pieces - this avoids recency bias.
  3. Deliver most of the feedback early before submitting it "officially" (where it might not be visible). This is controversial, but I'm a big believer in openness. To the extent possible, I try sharing feedback with people verbally and/or sending the write-up upfront, so they can ask for clarification and act upon the feedback even before the official processes have time to deliver the feedback. It also lets me fix any inaccuracies in my write-up. At the same time, I've skipped this a few times when I've been too busy to wordsmith feedback for public consumption.

When feedback is challenging or hard to write - pull in the person's manager! They can often provide tips on how to frame it more positively or offer to deliver the feedback on your behalf (anonymized).

Try using the impact/behavior/improvements model. Start the write-up by talking about the impact of the person's work, and then go on to list the behaviors they demonstrated. I like this model as you get a clear, objective view of what happened (the impact), and a slightly subjective view of how that was achieved - and potentially suggestions for behaviors to reinforce. Lastly, end by talking about a few areas of improvement - there should always be something there!

If you're not sure what areas of improvement to write about (especially if someone is doing well) - challenge yourself! Your peer is not as good as John Carmack (and if you work with him - well, I'm jealous), so what could they do better? There has to be something! If you have only speculative suggestions, that's okay - phrase them as such, perhaps even in the form of a question challenging them to do better.

Lastly, peer feedback should contain novel data (for the person's manager). I've realized over time (especially since becoming a manager) that the best thing I can do while writing feedback is to cover the intel I am uniquely suited to provide that no one else is. As a manager I would often see the following situation:

  • Self-review: I worked on project X and we got the result ABC.
  • Peer review: Bob worked with me on project X and the net impact of the work was ABC.

This peer review has added essentially no value.

Better framing of the above feedback would be something like: "Bob worked with me on project X, handling the system design and code reviews; this helped my team meet our goals of Y, and his attention to detail helped us catch issue Z before it became an issue in production. Bob was very communicative, not only for his tasks but for the entire project. His help unblocked us several times when working on $codebase, and he guided us on how to integrate with Kubernetes. He always made himself available to help."

Here's why it's better:

  • It's specific: it tells the manager Bob's exact role and contributions to the project.
  • It provides new data: It helps the manager understand how it met the other person or team's goals (very unlikely for someone to put this in their self-review)
  • It talks about behaviors to reinforce: In this case, it celebrates Bob's attention to detail and helpfulness and lets him know that he should do more of that.

Examples and critiques

We've talked about a bunch of techniques for feedback in the abstract, but it's hard to internalize things (for me at least) without specific examples. So let's go into a few!

Note that these are all examples of well-written feedback - I wasn't able to easily find poorly written feedback that I felt comfortable sharing.

Example 1: On feedback efficiency

Feedback efficiency - When Hasnain reaches out to me with feedback about my directs, sometimes:
° Feedback is missing details/context about the events, actions he took, and suggested solutions
° Feedback was not shared with the subject
° When feedback is shared with me it is clear but doesn’t land with the subjects. For example, [Alice] and [Bob] both got a softened version of what was provided to me and missed out on opportunities to improve.
° Hasnain holds himself and others to an extremely high bar, I feel sometimes more minor feedback can be aggregated and tracked for progress to avoid “feedback fatigue” and in others, the bigger picture (empathy) can be better integrated.

This example is a bit more meta since it's feedback about feedback. But it's well written! It's great because:

  • It points out a few clear areas of improvement (add more detail, share feedback, etc)
  • It lists specific examples of situations I can think about where things weren't great (delivering feedback to Alice and Bob)
  • It gives specific actions I can take (aggregating feedback) to improve my feedback

Example 2: On feedback efficiency, again

Some of your peer feedback suggests that you are not yet always approaching giving feedback with sufficient directness. This is not a fundamental problem in the way you communicate, but rather something the exhibits only in very specific situations.
I think there is some nuance to this (i.e. [Alice], who wrote some of the feedback to this effect just may need a lot more directness than most), but fundamentally I think it is good advice to:
° Build in feedback loops in conversations so that you can dial up the directness if needed. Make sure that you tailor the message to the recipient. Test how direct to be, rather than being overcautious by default.
° Corollary: When you find yourself being circumspect, question whether you are doing that intentionally.

This is interesting as it's a follow-up to the previous example. I like this because:

  • It's specific: Again, the situations being referred to are clearly laid out (from the rest of the writeup)
  • It provides guidance: Very clear tactical advice on how to approach feedback conversations; and a way to self-assess for improvements
  • It's targeted at the behavior, not the person: The feedback makes it clear it's not a problem in most cases, but applicable in certain (tougher) situations. This makes the message a slightly softer one while still being clear.

Exercise for the reader: contrast this example and the previous one. Beyond the different writing styles, what else stood out to you? They are talking about the same events.

Example 3: On work style

Hasnain's style creates positive, energy-generating interactions, especially during uncertain periods. Ramping up at Facebook can be bewildering, and I know that I can count on Hasnain to point out the right course of action or gently suggest improvements. For example, in commenting on the [redacted] document, Hasnain gave valuable guidance both on the content and on “it’s time to ship this.” Because of this, I look forward to working with Hasnain and I feel inspired to “go the extra mile” in the work we do together.
...
The flip side of Hasnain's positive interaction style is that it’s not always clear to me when something is seriously urgent. I don’t think this has happened yet, but if it does, please don’t hesitate to be blunt and say “I need this by X date or it will be an issue.”

This is great because:

  • It's full of praise: It tells me what I did well (bringing energy to work and helping others), and reinforces that I should continue to do more of this.
  • It also has areas of improvement - it adds color to how I should adjust my behavior (be more explicit with expectations).

Example 4: On concrete areas of improvement

Constructively, we’ve had a few discussions about better delegating (i.e. doing somewhat less prep work before tossing work to the appropriate engineer) as a behavioral item, and about continuing to mature the [redacted] effort (e.g. by ensuring that we collect metrics around coverage that will help us make decisions) at the team strategy level. More directly, the expectation is explicitly that our [redacted] effort will continue to grow in terms of raw results (issues found and fixed; the severity of those issues).

This feedback is written to highlight a concrete area of improvement. It's nice as it clearly calls out two areas of improvement, with suggestions on how to improve. In addition, it sets very clear expectations for the desired result and leaves the recipient with a mechanism to measure progress.

Example 5: Speculative areas of growth

I feel the team has good results from low-hanging fruit for the [redacted] effort and they have collected good feedback for H2 efforts. It is hard to argue with the results, but could the number of [redacted] have been tripled or quadrupled this half?
Hasnain has good context of our org's efforts and has contributed to lightweight team planning exercises that focus on adapting our strategy for [redacted]. This strategy does not yet exist, it isn't an explicit expectation of Hasnain, but he could step up.

This feedback is different from the others: it focuses on identifying potential growth areas. In addition to the praise, it makes those areas of improvement clear as well - challenging me to think about how I could have achieved better results. It also identifies a strength I have (context for the org) and a potential mechanism for me to further increase my impact in the future. This is a good example of coming up with growth areas in a situation where there's nothing "broken" (as it's always just easier to identify something to go and fix).

Meta-analysis

Throughout these examples, you'll note that the styles and tones vary a lot. That's fine! Feedback should not be about word-smithing or coming up with the perfect tone. As long as you can get the message across, you shouldn't worry too much about phrasing (even bullet points are fine!).

These examples make the growth areas clear - that's what I value from feedback. Praise is appreciated, and very welcome, but not necessary.

Lastly, they set clear expectations - they either identify a problem that needs to be fixed, or highlight an area to investigate with clear criteria for success. That makes the feedback much more actionable.

Conclusion

If you find it hard to have difficult feedback conversations, it may be worth reading crucial conversations - I took the course and it helped a lot!

Many thanks to David Molnar, Pieter Hooimeijer, Oren Hafif, and Ted Reed for teaching me how to get better at feedback (and providing some excellent feedback!) over the years and letting me use some of their feedback in this post.