360-degree feedback
Wednesday, December 21st, 2005 at 09:24pm
This morning before we headed off the South Oakleigh Bowling Club for our end of year barbecue we were each given a report of our 360-degree feedback. Although I still have concerns about the entire process (two of the people I gave feedback on I have barely worked with so it was very difficult to rate them) I am happy with my report.
The first section of the report was about twelve key values/behaviours and all of these for me were either meeting or exceeding expectations. However when my average ratings are compared against the entire team’s average a slightly different picture is shown and that is that I need to work on communication and effective team stuff, the mentoring part of my role as a senior developer…
The comment section that follows the key values/behaviours bears this conclusion out and I heartily agree with most of them. One comment that was repeated was that at times (too often was one comment) I am too negative/harsh/dictatorial rather than enabling other team members to perform their best. My initial response to this was that there are some team members that need to be dictated to otherwise the development would not be completed in time or would require excessive maintenance in the future. However I should be investing time in them now in order to enable them to grow to a level where they are improving the quality themselves….
There is one comment that I am not sure if I will ever agree to:
- “finds it difficult to accept that the stakeholder is more important than the underlying code and that the solution is not always precise and neat, but has to go to production anyway”
My stance on this is that the stakeholder has nothing to do with the underlying code, we write code to satisfy the business requirements of the stakeholder and as such we should never go below our internal quality levels. I say should because I do accept that there are emergency situations where an item of functionality must be rolled out as soon as possible. However in these situations we need to immediately follow the emergency change with a refactor that follows out standards. ie we roll the workaround today but next week we roll the final solution.
This stance would also apply in the situations where the requirements change close to the release date or that an action item that we are waiting on is not done in a timely manner. If we have estimated two weeks for our part of the project then the project manager must ensure that we get two weeks to work on it. Then if the project manager fails to plan appropriately we spend three weeks on it: one week to get it done and then two weeks to do it properly. We should not have to suck up excessing maintenance costs because the project manager was negligent… (Over the next few years activity-based costing will be introduced which could make this interesting…)
