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.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica