Guidelines for writing good individual review comments

 

It's that time of year again at Microsoft where we get to write our reviews.  I find it helpful as a manager to go over some guidelines with my team as a refresher on how to write good reviews.  These are my opinions from what I've learned after doing reviews for the last 15 years.  Some of these guidelines may not work for everyone.  Also, there are different guidelines for managers writing evaluation comments  and feedback for their reports.  I'll get to that in a future post.

 

• The first thing people need to understand is that review writing is an important task and skill. Don't short-change it. It's the main method used to record all the work that was done in the last year. If not enough time and thought goes into it and it is written poorly, it becomes a bad representation of the work that was done, even if the work was spectacular.
• Who is the audience?  Let's face it. The audience of a completed review document is not the individual writing it or the manager who adds their evaluation comments. It's that future hiring manager or future boss (within the same company) that wants to know more about an individual as that individual moves through product groups on the journey of their career. Given this, there are some items to consider which will make the comments more clear to this audience:
  • Don't overuse acronyms - the individual and their manager may understand it, but the manager a few years from now won't know what it means and the text will lose it's usefulness.
  • Don't use project names without first describing them.
  • Don't infer or indirectly state something. Describe it so new readers will understand.

Here's an example: Before a reorg was announced, I needed to decide what team members I should move into new roles testing databases.  I hadn't worked on the team long enough to know the backgrounds of everyone so I decided to look at their past reviews.  I found that this didn't help me at all.  All I stumbled into was acronyms, project names, and cursory inferences to situations I wasn't a part of.

• Be honest and objective. The goal should be to write comments that are an accurate evaluation of work that was done, both the good and the bad. Along with this, don't overstate your accomplishments or take credit for something you didn't do. When the manager writes comments, they should theoretically only need to write "I agree" because the individual's evaluation comments are objective, accurate, and complete.
• Related to the last point, comments should be balanced. This is a time to brag about your accomplishments and a time to critique yourself. Many people only state all the good things that were done. What happens in this case is that the manager then needs to also mention all the areas that need improvement. More time will be spent on these improvements in the manager comments which then makes the review become unbalanced. The individual may have met expectations, but since the manager needs to spend enough time in the text stating the areas of improvement, the tone then becomes negative. The same is true in reverse. I've read many reviews where individuals get down on themselves for not being perfect or not accomplishing everything. Then the manager's comments need to state all the great things that were done and again, the review's tone becomes unbalanced. This also comes across as the manager and individual not being on the same page. So aim for writing comments so that all your boss would need to write is "I agree".
• Don't just state "what" was done, but "how" it was done with examples and details. This is important. Getting a task completed but upsetting people along the way is not good. Managers should not have to do damage control for mismanaged tasks. When a task is completed, how it was completed is sometimes as important as just completing it.

Here's an example: I've managed tools team and once had someone that wrote a tool and got broad acceptance for it - many people in other teams started using it.  I found out they were using it because they were bullied into it, and weren't given a choice.  In another case, the tools developer did surveys to find out what his potential customers (people in other groups) wanted before writing the tool.  In the end, both people had the same result, a widely used tool.  But how the second person got to that end result was much more appropriate and productive. 

• Polish the written text by confirming that strong action words are used. And get sentences in the right tense, past or present. Avoid using "have", "has", and "been". And finally, don't use bullet items, but write full paragraphs while trying to be concise.

 

If writing review comments is difficult, consider getting into the habit of weekly status reports or saving important emails into a separate folder throughout the year.  Then, at review time, go back through those status reports or emails to remember the details of what was done over the past year.