Ask HN: A great engineering appraisal process?

[pandog]

Throughout my career I've been dogged by poorly thought out engineering appraisal or review processes. Especially at larger companies where everyone from the CEO to the Junior Developer are assessed in the same way.

Generally what I've experienced is an annual "review" whereby employees assess themselves on fairly broad requirements ("Helping build the company") and then receive some feedback and a number. This is often associated with an annual pay rise.

I now find myself in a position where I can have some influence over the implementation of such a process, but having mostly had bad or neutral experiences I find myself clutching at straws for suggestions (aside from "don't do this!").

Has anyone had great experiences with such processes? Or am I being too idealistic or just too negative?

[sethammons]

One of my favorites was anonymous peer review. Some folks within your team and from outside your team (with whom you've worked) list some areas of strengths and areas for improvement. When you get these back, they are scrambled a bit. This does not replace the manager review, but can aid it. It really helped me see what I was valued for from others and I could think on the proposed areas for growth.

Back to the formal review, it should be an opportunity to document wins over the period. Your goals should be aligned with the company goals. Ideally there is a rubric for your position and the position that you would get in a promotion and your performance is considered along with the rubric.

Managers should come together and level-set for promotions (assuming there is a finite budget to work with). Defend promotions or lack thereof. If one manager is tossing out promotions like candy, and another is not, some adjustments are likely warrented. Concrete examples defending positions should be discussed.

I've not been exposed to many review systems, but I like the ideas behind this one. Would love to hear what others think and do.

[kat]

Couple of my favourite performance review processes:

- "do your job" should be one of the goals. I want credit for doing my job, rather than having all my goals be tasks that are slightly outside of my job description

- Include soft skills and technical skills in everybody's review. Technical skills are not very useful if you can't explain why or what you've made.

- If you have to work under broad company goals, make examples of what this concretely relates to. ie "make quality software" becomes "maintained 80% test coverage" or "gave a presentation on TDD" etc.

- cost-of-living raises are given for "average" people. The market for developers is too hot to keep people at their existing salary. The company needs to keep salaries at market level which means increasing salaries for everyone, except the "below expected" people.

- quarterly reviews instead of one annual review, keeps people motivated and less surprises