Skip to main content

Delivering constructive review feedback to technically superior employees

End of year reviews have either been recently completed or are in the process of being finalized. As a peer, scrum-master or manager you have probably been involved in delivering in some form feedback to the technical people in the team. In software development appraisals can quickly be dismissed as a box ticking exercise for management, but it doesn’t have to be this way. Camille Fourneir wrote a blog earlier today on this very subject where she actually emailed her team with a justification as to why the process is important. The process can be even harder if you are giving feedback on someone who has more experienced or specialist technical skills. Here’s some tips I have found help in constructing a useful, engaging appraisal process which helps you achieve the two main goals of a review process – highlighting achievements and identifying areas which can be worked on in the new year. This is useful for both people providing feedback on their peers, and for those managing others.

Image from freeimages
1. The review process is not one way!
Firstly the review process should be a two way process. If you are a manager, you are not just looking at a developers year and commenting on them; this is their chance to comment on your performance in relation to their role. For example, they may think you are good at dealing with impediments for the good of the team, but they find that you are sometimes a block between the development team and the end customer. This kind of feedback is invaluable to you and you should actively encourage it.
2. Include anonymous peer reviews in the process.
Secondly, contrary to point 1, the review process is not just a two way process – it should include peers. One person saying to another person they are good or bad at a specific thing can lead to confrontation or the person being appraised not believing the feedback; however if you get peer feedback from multiple team members with multiple people mentioning the same points, then it is harder to disagree with. A process which has worked well for me is for each team member to nominate 3-5 peers who can provide anonymous feedback on their performance. The appraiser collates the feedback to make it anonymous and provides it prior to the review starting to give the person time to review their feedback and take it in. Feedback from peers will generally resonate better than manager feedback, as you may work far more closely with your peers than you do a manager. This is also allows you to collate both technical and non-technical feedback from various roles within the company, removing the need for you to feel like you need to comment on someone's code if you yourself are not a developer for example.
3. Provide positive and negative feedback.
The third main point is that you need to provide both positive and negative (constructive…) feedback. It is important to celebrate the successes of the previous year. Even if someone has had an unbelievable year, you still need to give them something to work on the next year. The best employees will want constructive feedback so they can improve their performance – we are all professionals after all and the software development industry requires continuous self improvement.
The biggest failing in feedback processes I see is when peers only provide glowing feedback for their peers. Whilst this is great for the review meeting and egos can be massaged, it isn’t for the best of the person being appraised. Getting focussed feedback on areas to improve will be the best thing in the long run, especially if multiple people pick up on something. For junior members of the team giving feedback on someone with superior technical skills or for managers who do not have the same level of speciality in a technology this can be a challenge and intimidating. However, from experience, any honest feedback will be well received and will help gain respect amongst peers.
4. Regular reviews throughout the year.
The most common cause for uncomfortable reviews is when they are only done once a year. One to ones should take place throughout the year and should remove the opportunity for surprises when it comes to the review process. Is it really fair to land negative feedback after 12 months when you could have mentioned it in January and resolved the issue immediately?
5. The outcome of the review is not to encourage someone to aim for a managerial role – there should be a technical career path!
In software development there is a tendency to encourage our best engineers to progress to a point where their technical prowess is no longer used as they move to a management role – which is simply absurd. In reviews, the person being appraised may feel like they have to say they want to work towards management or a scrum-master role, purely as they want to show they have ambition even though it may not be the best thing for them. A good company will have a technical route for employees as well as a managerial route. Just because you are the best developer in the company, doesn’t mean you can’t improve and do more from a technical point of view. Make sure there is a career ladder people who don’t want to go into management can follow. Managers don’t need to get paid more than the best developers! Keeping your best developers developing if that is what they want to do will ultimately lead to you having a greater product.  Erik Dietrich describes this common problem in the following great blog post.
Related Posts:


Popular posts from this blog

Managing programmers and the programming mother******* mentality

I came across the following great site on Stumbleupon today - - and as a developer had a great laugh before realising that in my day job I'm really the guy the site is having a swipe at!

The site aims it's gun firmly at the door of managers, whether they practice agile, XP, Scrum, waterfall etc and pokes fun at the agile manifesto:

Whilst the site may be a bit tongue in cheek (obviously taking inspiration from Pulp Fiction), a huge challenge of managing developers can be the fact they can see you as a roadblock in the way of them producing code. Ultimately you are responsible for the success or failure of a project and as a result you have probably applied a process to the team to help you ensure your team are progressing in the correct direction. So how, as a manager, can you break down this perception from members of your team who have this mentality?

Before I start, I'll confess when I started my first programming job I agree 100% with the se…

Integrating Google Analytics into existing Android app

Analytics are key to measuring the success of your project or application and are a great way of identifying your users trends and demographics. Have you released an app and wondered who your users actually are? Well with analytics you could find out where your users are situated, what ages they are etc. The leader in this field is Google Analytics - this can be embedded into your mobile application, website and even your blog.

After a few frustrating attempts at integrating Google Analytics into an existing app I thought I should post a guide on how to do this.

1. Download the Google play services library and add it to your project.

You can do this by right clicking on the project you want to add analytics to in eclipse, choosing properties and then the Android tab. In the Library section, select Add and choose google-play-services_lib and select Apply.

2. Add the required permissions to AndroidManifest.xml.


Android - Could not find HelloWorld.apk! - fix

So my first experience of Android development left me frustrated after getting an error trying to launch the  simple Hello World example!

Simple fix - basically when I set up eclipse I forgot to set the JAVA_HOME path variable.

The symptoms are this in the console:
[2011-12-12 22:37:05 - RoryHelloWorld] Android Launch! [2011-12-12 22:37:05 - RoryHelloWorld] adb is running normally. [2011-12-12 22:37:05 - RoryHelloWorld] Could not find RoryHelloWorld.apk!
The fix is simple. Open up your machines environment variables (in Vista it's Control Panel -> System -> Advanced System Settings -> Environment Variables).

In System Variables add a new variable JAVA_HOME set to where your JDK is installed, e.g.

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_12\
Then add JAVA_HOME to your Path variable. I added:

%JAVA_HOME%\bin;%PATH%; to the end of mine
Restart eclipse for the changes to take effect, then the next time you run your app it should work!