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.
No comments:
Post a Comment