Setting Performance goals for Developers

Question

I'm about to go through and set a list of personal performance goals for a team of Developers (4) that I am now managing. They are in various stages of the Developer life cycle, from Intern through Senior. I'd like to get some feedback and examples of good SMART (Specific, Measurable, Achievable, Realistic, Timely) goals for any member of the team.

I will be adding individual goals and some self selected goals to each team member, but I'd like to see what people have seen or think are good baseline goals for any developer working on a team.

Answer 1

I want to write a module that has 50% of line code coverage and get it completed by [date]. I will write at least one unit test for each 500 lines of code.

Answer 2

Software developers are typically very good at gaming performance goal metrics. Consider a proven, but unfortunately not widely used approach:

Setup performance metrics, but only the individual can see their own results. All managers can see is a sanitized (no individual information) aggregate for their group.

Straight from one of the best books on managing; Peopleware.

http://www.amazon.com/Peopleware-Productive-Projects-Teams-Second/dp/0932633439

Answer 3

I want to code review 20% of my critical source code by [date]. I will perform a one hour review, 2 times a week.

Answer 4

Do you know these developers or did you just recently become their manager?

Reason I'm asking is that for more than half of my career I got 'reviewed' by managers who really knew precious little about what I actually did. They were so wrapped up with their meetings and their charts and graphs and more meetings and working on the proposal team or doing some sort of CMM/CMMI steering group busy work that I honestly felt like they were my managers in title only.

I hope you aren't that way because a good manager is worth a lot in my book.

Obviously, there are self-selected goals that developers have. I like those being incorporated into the review process - because it is an opportunity for the manager to get more info about what the dev is interested in doing.

But - you can't rely on that and you can't cookie-cutter these things. I've had SEVERAL cookie-cutter reviews over the years where it was clear that the guy at the desk next to me got the same basic review as me and as the guy over on the other side of the room. Not much point to all that in my opinion.

You need to determine what is a good goal for your team members because it is going to be specific to your team and your company and most of all your employee.

If you can do that, then you are on your way to being a good manager. Anything that I would tell you to put on their list (like "learn how to do X" or "develop an automated process to do Y") would be specific to my shop and my devs.

Best of luck!

Answer 5

What would be your rationale for setting a goals? Do you simply want to insure that they're productive? This sort of seems a bit backwards to me, the emphasis should be on results and development, otherwise you risk createing a sort of "grade-school" atmosphere where you not only monitor people's day-to-day, but ultimately take responsibility for it. If you want to use goals to push people the goals should be relevant to the person's level. That seems like a very positive thing-e.g. for junior developers, development of a module or self-contained component with the help of a Senior. Maybe have them give a talk on a new tool or library.

Answer 6

Again from peopleware (see @Solracnapod): measures over a multitude of projects have suprisingly shown that programmers are most productive, if they are left alone. Instead of perfrmance goals, help them by eliminating road blocks whereever found, but tell them to "wake you up when they are finished". Projects done that way were the fastest to complete with best results.

Answer 7

I think you need to first have the developers create estimates for their projects. Then compare the estimates with actuals. These estimates should include number of bugs per lines of code and time to develop. Then also measure bugs found during development with bugs found during QA or production. So the trends should show that estimates and actual should head towards each other. Then trends for bugs found during development should go up and bugs found during QA and Production should head down. This takes some time to see trends. One caveat Dev, QA and Production need to use the same bug tracking application.

Answer 8

Much of what I would say has been aid by itsmatt, but I'd add:

The true performance of a programmer is often hard to judge until another programmer has to use/maintain/correct his code. That is when you can get a good assessment of how solid his code is, how often does it break, has it been responsible for any code disasters etc.

And most important: how well did the CLIENTS enjoy his code. (sometimes the clients are other programmers, sometimes end users, sometimes it's something in between) Ultimately the purpose of computers/code is to make our lives easier (even if it's not always the result) so that is why I think the ultimate judge should be the end users and maintainers of the code.

Mind you I am answering from a large project/video game centric standpoint, and this may be less true on smaller projects, but I think it still holds true.

So what is my advice in the end? Assuming a healthy functional social environment, Client and Peer Reviews tend to be the most reliable metrics (though often not the most convenient ones), "Performance Goals" usually just end up striking good developers as bureaucratic and will annoy them... and as someone said above, it will really just show how good they are at gaming the system

Answer 9

I suggest you read Joel Spolsky's recent article in Inc.com on the subject of incentives. Here's the conclusion:

We simply established as a rule the idea that gaming the incentive plan was wrong and unacceptable. Employees generally follow the rules you give them -- and if they don't, you can discipline them or, in extreme cases, dismiss them. The problem with most incentive systems is not that they are too complicated -- it's that they don't explicitly forbid the kind of shenanigans that will inevitably make them unsuccessful.

But make sure you read the whole article.

Answer 10

You may like to ask each developer to solicit feedback from the client of any projects that they do.

This helps bring another opinion (and a very important one) on the developers efforts to the review.

Answer 11

ask them "What would you like to achieve in the next year?"

then listen

then ask "How can I help you achieve these goals?"

then listen

then ask "How can we measure progress to know that we're on target?"

then listen

then do it