I remember one job where I grew to absolutely hate the performance reviews because no matter how I tried to prepare I always ended up having to comment on very vague criticism from often anonymous sources.
Feedback and comments were not weighted by source. So an anonymous comment from someone I’d had a single chat with was given the same weight as my direct supervisor’s comments on the same behaviour. This often led to confusing feedback since the reviewer was loathe to discuss who had given what feedback (but would occasionally).
Some lowlights:
CAN’T DO WORK WITH NO SPECIFICATIONS
I was tasked with building a certain feature of our software, and given a contact to give the documentation of the actual specifications which he had as a word document on his PC instead of searchable on the intranet. (He told me not to use the intranet one as it was very out of date.) I e-mailed him reminders every day, or every other day asking for the spec so I could start until the time I had allocated to me to it ran out. And then any time I knew I was going to finish early and have spare time I e-mailed him again asking for the spec.
At my next review I got the feedback from him that I hadn’t fulfilled that work and the other guy had to rush it in himself at the last minute. My contact didn’t consider the work that difficult and sent the spec to my reviewer to evidence this. So I found out what was in the spec when my reviewer read it out to me asking why I didn’t do it. Fortunately I still had all the e-mails I sent and could evidence that I had never been given access to the spec to do the work. I did put in an HR complaint about having that feedback held against me, but nothing came of it and my reviewer’s impression of me was permanently coloured by this.
CONFLICTING FEEDBACK
One person spec’d me some work where they misused a technical term. Since they were senior to me and more technical than me it never occurred to me that they had misused the term, and my daily status updates made it obvious that we’d understood the terms differently. He even tried to offer support to do the task in the wrong way, not realising that what he’d meant to spec was different. When we realised he’d used the wrong term he put in feedback that I need to be less independent and talk to the other product owners more to make sure we’re properly aligned.
During the same period another person spec’d me some high-priority work with extremely vague specifications. I had to regularly ask for clarifications in order to make sure it was right. He fed back that I needed to work more independent and just get on with it using my best judgement as to what is correct.
My supervisor was aware of both of these situations, thought I handled each case as well as can be expected, and said so in my review.
My review said that two people criticised my communication skills, and only one person thought they were good. Never mind that one person spoke to me and observed me talk to others every day of the six month period and the other two only talked to me for about a week each. But he’d made notes that I needed to be more independent AND be less independent and hadn’t noticed until I raised with him that I can’t do both.
MOVING THE GOAL POSTS
Early in design I built some features for a prototype version for others on the design team to experiment with: we were building a puzzle game and they wanted to experiment with weather effects, such as hot, cold, wind, rain etc… In the end the game went another direction and one of the junior team members was tasked with removing these effects. Six months later I was suddenly hauled up to explain some poor quality, hard to use code that was causing bugs by behaving differently at different frame-rates. Turns out the wind effect was very useful to stopping the player moving out-of-bounds, so that had been kept in by the junior tasked with deleting it. So as far as I knew the code I’d been asked to justify had been removed from the project when we left pre-production (which is normal and to be expected – it’s supposed to be a rare case that code gets carried over), and it was “very confusing” because in prototype versions you give designers the ability to fine-tune *everything* so that you know what to keep behind the curtain when you come to make the final product.
I did talk about all these (and a few other things that made the review process really annoying) at my exit interview. From the sounds of it they did make some changes to the process, but mostly in a way that made it even more bureaucratic than before.
