Skip to main content

How To Do End of Year Performance Reviews for Agile Team Members

I've been avidly following a discussion in the LinkedIn "Agile and Lean Software Development Group" called " Does Agile mind-set suggest any method for measuring the individual performance of developers and using it in a punish and reward system?:  (I included the url, but I'm not sure what will happen if you try to point your browser at it if you're not me.).
From http://memegenerator.net/instance/25931448

There are a lot of interesting directions for this topic to take, but the key question I've been mulling over in my own mind is this:  What, if anything, do you need to do as a hiring manager at "annual review time," in order to reinforce an agile culture of teamwork without demotivating your star contributors?  It's Star Trek's notion that the needs of the many must battle and win against the needs of the few!  Or so it seems.

Let's talk about these issues frankly for a moment.

Punish and reward:  a significant plurality of LinkedIn Agile and Lean Software Development forum members (henceforth LAALSDFMs) pointed out that only a fool thinks that the way to squeeze better performance out of an individual -OR- a team is to use the threat of punishments or promise of external rewards.  As Daniel Pink's web site says with reference to his amazing book, Drive:  The Surprising Truth About What Motivates Us:
Most of us believe that the best way to motivate ourselves and others is with external rewards like money—the carrot-and-stick approach. . . .  The secret to high performance and satisfaction—at work, at school, and at home—is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.
"Bah, humbug!" you say.  "Idealistic twaddle!"  No, seriously!  It's true. Think of your own life.  Have you, or would you ever, leave a job due to one year's rate of salary increase?  On the other hand, have you, or would you ever leave a job or take a new one for the same salary or even less, in order to learn a new craft or increase your sense of being needed?  Day to day or even year to year motivation is seldom a matter of an external reward.

Tying salary to end-of-year reviews is therefore a really bad idea.  In fact, end-of-year reviews are a bad idea.  This notion was also a popular one for the LAALSDFM crowd.  Here I must protest. 

Seriously?  Never review?  Are you also not giving regular raises?  How is that working for you?  I can picture in a small start-up where everyone owns a stake of the business that reviews and raises wouldn't be relevant.  I've never personally worked anywhere that didn't have annual raises though.

Don't link review and annual raises?  Again I ask, are you serious?  Are you a line manager?  Do you want to explain to an important member of your team that although you are both going to spend hours preparing for and conducting an end-of-year review, the result will have nothing whatsoever to do with their salary next year, their bonus, or their hopes of promotion?  And worse, how are you going to justify the salary, bonus, or hopes of promotion discussion when you get around to it? 

Please, be practical.  If you don't do one on one reviews with people reporting to you at least once per year, please set that up.  It is a very good practice under most circumstances to conduct an annual review of a person's goals, how well they did in achieving the goals, and you must certainly also discuss any related news you might have about their compensation or external rewards.  Although money is not a motivator, a careless or cavalier attitude towards a person's salary is a guaranteed DE-motivator.

Okay, but you should measure people by something fair, like a 360 review by the whole rest of the team, or the actual business value the team delivered, divided by the number of team membersSorry, no.  This is not "Lord of the Flies," and we don't set compensation based on popularity with the team.  You are aware that teams are composed of human beings, correct?  It is also not a good idea to create competition among team members for the "revenue enhancing" projects rather than the "bread and butter" infrastructure and workflow projects that keep the lights on.  As a manager, I am hugely grateful for people who enjoy what they're doing even if it isn't "cutting edge" or "high recognition."

And it's not going to work to just give everyone in your whole division the same compensation every year to reinforce how we judge "teams" and not "individuals" any more.  Telling a person "we're giving everyone the same compensation this year because we only judge team performance" is both careless and cavalier, however noble it may sound to you in theory.

As a hiring manager, it is your job to work with everyone on your team at least annually to ensure that the person's employment on your team is mutually beneficial for them and for your organization.  This discussion should not be focused primarily on salary, but to avoid giving offense to the employee, it must include an explicit conversation about what their salary and title needs are, and an implicit consideration by them and by you of what it would cost you to replace them in the current hiring climate, and what their prospects of flight to somewhere better might be.

Make no mistake:  there most certainly is competition in this world, no matter how agile your company becomes, and that competition is for the chance to hire and retain the best workers.  The cost of hiring and training a replacement even for an AVERAGE worker is something like two years worth of that worker's salary.  The issue is not "how do we keep team members from competing with each other through deft use of carrots and sticks."  The issue is "how do we as managers create a workplace where workers want to stay for a while?"  Each person's need for recognition, in terms of title, compensation, and so on, is individual, and must be negotiated individually based on how much you need them and how much they need you, and how well you negotiate the deal.

So I hope you're never doing something really stupid like "victim rotation,"where you give everyone the same raise, except some random people.  That will have people running away!  Sorry to disappoint, but I'm not with you on this point either. 

Give your team members some credit.  If nobody is getting a raise this year, there is no need for you to pretend that the "no raise" situation is personal to the individual, in order to falsely motivate them to work harder.  If your hands are tied, you need to be honest about that, and do the best you can.  Not in order to motivate, but in order to avoid DE-motivating.

During the endless decades of my working life to date, I have faced the worst-case situation for a manager, and I have executed on the "pick a victim" strategy.  And I have no regrets.  In this case, corporate policy forced to "grade" my team members on a "bell curve" or "S curve," with the dubious result one year that on a team of six people, I could assign one "A," four "B"s and one "C."  You would think this situation would cause mass exodus from my team or even my company.  But it didn't.  Everyone in the division understood the system, and most teams had an overt understanding that "As" "Bs" and "Cs" would be rotated over successive years.  So long as this was done fairly and transparently by team managers, de-motivation was avoided.  And so was motivation. 

So let's go back to the original question.  What, if anything, is a hiring manager in an agile world to do at end-of-year review time?  I think it boils down to one "do" and one "don't."    

DO:  Focus on coaching individuals on appropriate goals for their own career paths, throwing your support behind them in the things they want to achieve that also work to the benefit of your team.  If your company has a good structure for using the annual (and quarterly) review processes to help people reflect on where they want to go, the best time you will spend as a manager will be the time you spend working with your direct reports figuring out what their dreams are and helping them accomplish those dreams. 

DO NOT:  Create any unnecessary offense by acting coy about money.  Make it clear what parts of a person's compensation are under your control as an individual manager (in your opinion), what parts are not, and what you've done about that.  If they need additional pay because they're getting a divorce, or they want a title change to keep their morale up, they should feel free to say that, and you should work together with them to figure out what the two of you can do as a team to make that happen (or not).  Are they getting in their own way?  You need to tell them how to change their behavior so you can help them achieve their goals without cutting into your integrity.  Are you not pushing hard enough?  They need to tell you.  Maybe you're being too timid.

This annual end-of-year review is a discussion between two adults, whether your company is agile, waterfall, or government-controlled process hell.  It requires personal judgements.  Pardon the reference, but it requires that most agile of concepts--a focus on "people" over "process."  Please don't be silly about it.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…