On the subject I have been meaning to ask Angie Culverwell, Product Development Manager, how she knows who is a good product developer in her team and who is not.
So today I asked.
"I know that A is a good developer because he ‘cares’ about his work. I know when he finds a development problem, he will find a way round it, because he cares. I know also he produces code with bugs but that is inevitable. When I give A a job to do it will be done, usually on time.
But the problem of creating timelines is that they are either based on thumb-suck or based on the need as defined by the Customer Service Manager and/or the User. So measuring a Product Developer on the basis of meeting timelines is not always a good idea. In fact it is never a good idea."
So Angie measures the performance of her developers on the basis of attitude. But how do you put numbers to attitude? Can we say A has a ‘3’ attitude this month and perhaps only a ‘2 attitude next month? And B has a ‘1’ attitude this month and a ‘2’attitude next month? Attitude tends to be a fixed attribute. We can talk about it at the Annual Review but not as a monthly performance target.
Do we then perhaps measure performance on the developer’s hours worked? No because hours worked does not measure ‘productivity’. Sometimes it is measure of lack of productivity when it takes, say A 50 hours to develop a piece of software and 100 hours for B to do the same. Neither is it an ‘outcome’. It is only a measure of output. Hours worked therefore cannot be a measure of ‘performance’.
So we are back to ‘square one’. Is it possible to develop realistic performance measures for product developers?
Anything is possible. Miracles we perform immediately, the impossible takes a little bit longer.
Watch this space.