The problem with getting a pile of comments from a “360 feedback” peer review process with your coworkers is that whatever is written is usually not Truth (with a capital “T”). It’s not that anyone is lying, but rather that the feedback you receive is the final output of a sequence of multiple lossy steps. To discern the signal within the noise, we have to try to work backwards through those stages and apply interpretation and judgement to reverse the distortion and extract useful meaning.
By the time you’re reading a comment from a feedback document, it’s pretty far from being a direct line to objective universal Truth. It actually represents (1) someone’s phrasing of (2) an opinion that is in their mind, derived from (3) their preferences, opinions, and past experiences being applied to (4) their interpretation of events they’ve observed/data they’ve gathered, which are drawn from (5) the limited subset of your actions that have been visible to the feedback author. Phew — that’s a mouthful of a sentence. No worries if you need to re-read it a few times for it to make sense.
Does that mean feedback is useless, or that it’s impossible to understand what was meant and what to do about it? No. But it does mean you shouldn’t take what’s written at face value — whether positive, negative, or simply a neutral opinion. The first step is to try to see through the distorting lenses, peering back to find the raw data, and understanding how each of the layers affect and shape what you’re reading. And then, secondly, you should apply some lenses of your own to filter that newly-clarified information and work out what you want to do with the feedback you’ve now understood.
A decent first step for interpreting a piece of feedback is to consider whether it surprises you or rings true to you. If someone is suggesting you’d benefit from getting better at SQL, and you’ve been having a nagging feeling that you make more mistakes and struggle more than you ought to when working with the database, then that’s probably simply correct and there’s not much interpretation needed. If, on the other hand, your first thought is “Huh? I thought I was doing fine.”, then it’s worth digging deeper.
Consider why the person giving the feedback might have that opinion. Did you work on something together where the topic came up? Is it a personal pet peeve or an area of interest for them? Did they happen to catch the one time you made a colossal mistake in this area, and are generalizing from that?
Step backwards through the layers of subjectivity and consider how to interpret or correct for each one:
- Are they writing literally what they mean, or do you need to read between the lines to get at what they’re politely hinting at or obliquely referencing without saying it explicitly?
- What seems to be opinion, versus what is fact?
- Why did they form that opinion in particular, or choose to highlight those facts? Why is this something they care about and want to tell you about?
- What did they observe that led them to this topic in the first place? Where did all of this start?
- Are their observations representative of the full picture, or are they missing important context?
At no point are we trying to invalidate the feedback, or find an excuse to reject it out of hand. Noting that a particular topic is someone’s personal bugbear and that they’re writing about it based on a limited view of your work, is not a reason to ignore what’s being said. Rather, the point of this exercise is to fully understand all layers of the feedback, so that you can more accurately target your fix to the right place.
For example, imagine someone comments that you aren’t doing enough work in a particular area — say the frontend webapp of your system. What you should do about that (if anything) differs greatly depending on whether you figure out that this person sees the work you’re doing but doesn’t believe it’s valuable; versus if you think they’re just not aware of what you’ve contributed because you’ve not been highlighting it; or if the facts are accurate but the commenter is missing some important context like that you’ve agreed with your manager to focus on the backend for the quarter as part of a different goal.
It can be helpful to talk through this process with someone. Usually your manager should be trying to help coach you through the feedback you received, but you could also ask a trusted peer or mentor. And, of course, don’t neglect the most powerful form of clarification of them all — simply asking the person who wrote the feedback about whether your interpretation makes sense!
Now that you have a better understanding of what the feedback you received really means, you have to figure out what, if anything, you want to do about it. If it’s small and straightforward, great — target your minor fix or tweak at the layer you identified as the source of the problem, and get it sorted. On the other hand, if it’s a larger topic, you’ve got some choices to make.
First of all, is it actually a weakness, and if so, is it one you truly want to do something about? Is it a topic the feedback author simply cares a lot about and wants everyone to focus on? Is it an area that will inherently have different specialists on the team, but you don’t necessarily have to be one of them? Is it an area you could be doing better at, or are you actually underperforming relative to expectations, and need to do better? And, finally, is it an area that aligns with your personal interests and goals?
This winnowing is important because one can realistically only focus on improving maybe two (three at most) areas at a time. Cheerfully trying to fix seven different issues at once is a sure path to getting the same feedback in six months’ time when it turns out you’ve made negligible progress on all of them. Far better to accept and note the feedback on a couple of areas — but defer addressing them until later — while you focus on the most important ones.
The choice of what to focus on should of course take into account what’s important for the team, what you’re struggling with the most, and what your manager is suggesting… but your personal preferences are important as well. You may be able to force yourself to improve at an area you hate, but you’ll be miserable while doing it, and so it’ll be slow and difficult. Improving at something you care about and enjoy, however, won’t feel like an effort at all, and you’ll likely make much better progress. Be attentive to the difference between improving enough to reach the minimum bar in an area, versus becoming excellent at something. Your first priority must be meeting the minimum bar for all facets of your role, but after that, you can become great at some of them.
Feedback isn’t objective truth. It requires interpretation and understanding the context from which it’s coming. But that doesn’t mean it’s completely subjective and meaningless, or that you can twist it to mean whatever you want. Simplistically taking it at face value risks missing the point, having the effort that went into writing the feedback go to waste, or feeling hurt and misunderstood. But rigorously and honestly trying to understand feedback fully will allow you to learn from it and improve.
