Performance reviews take time…

Oh boy, I wanted to fix some automation bugs today, but could not as I had to update my “commitments” for my performance review. And I need to go home and do my laundry.

Reviews at MS have changed as we officially become a “large company”. Earlier we did not spend time worrying about commitments and what not – you simply listed the work you did and and got graded based on that. That was the whole review. My personal goal was as simple as “work hard(er), make money, have fun” (it was implied, I did not have to write it). Now we need to be mature corporate citizens and define goals accordingly.

Fortunately Microsoft has not reached the stage where you put in arbit goals like “I plan to proactively leverage my synergies to optimize my throughput all while valueing diversity” (I think this was Wally’s [(c) Scott Adams,] goal), our goals still are precise, actionable and measurable, and I think I know that we have to evolve as a company, but part of me still feels nostalgic for the days when I could write my review in a couple of hours and there was very little MBA-speak involved.

I miss the dot-com era.

Comments (6)

  1. Would you mind elaborating on the review process? There are always lots of posts about the interview process, but very few on how employees are reviewed once they are employed. I solicited feedback on how to perform good reviews in small software companies (see but I haven’t received any real replies.

  2. Deeptanshu says:

    Hi Dennis,

    I don’t think I am allowed to give you details on what our review docs look like, but we have always had sections on accomplishments over the last year and growth plans for the next one, which is I think quite common to a lot of companies. Then we have been experimenting with some other sections that as I mentioned probably have to do with us becoming a big company. I think it is not just the sections of the doc that matter as much as the corporate culture of writing the docs. We tend to define measurable criterion of accomplishments and require people to list examples of the accomplishments they are claiming. (became a C# developer? what code did you write?). This considerably reduces the bluff factor. Our reviews also tend to be quite honest and we don’t typically sugarcoat failures. This is again a management attitude issue more than doc specification.