Programmer evaluation at end of project

I first learned about FDD this year at the Agile Developers Conference and was so impressed by it, that I've implemented a slightly different version of it at my workplace. We're still ironing out some of the administrative stuff, and one of those is the evaluation of the programmers.

In the past, the supervisor of the programmer has worked with him/her throughout the year, and we have some standard forms that they would fill out. We now have Chief Programmer positions and Supervisor positions. The way we'll be handling the salary/bonus allocations is with feedback from the CP about the programmer. I'm trying to develop the things that will be in this feedback, and was looking for some insight from those that have been doing it longer.

thanks, k

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jeff De Luca's picture

What's Different?


I don't quite see what's different. You were evaluating programmers before and using a supervisor to get the input. Now you have CPs who, being closer the programmers, can give better input. What needs to change other than the source of the input? I feel like I'm missing some assumption perhaps in your description of the problem. How to evaluate staff, especially technical staff, is a huge topic of its own and there's no one right answer.

Personally, I like setting job goals with the employee at the start of each annual cycle. This is often an iterative process with the employee and I invite their input. Come evaluation time I must have gone out to seek input on their performance from a cross section of people and departments they interact with.