"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

Well, it's that time again -- time for the yearly performance evaluation. The ritual starts with gathering feedback, proceeds to assigning rating/ranking, and drags on through doling out a raise.

Do you enjoy annual performance reviews? Thought not.

This year I think we should all skip it.

Really.

Here's why:

For most teams, each person's achievement is all intertwined with the other members of the team. Trying to pull out individual performance on project goals is futile. Emphasizing or rating individual performance undermines collaboration.

Individual skills are only part of the performance equation. The quality of management and the environment for success are major factors in individual performance. But most rating and ranking schemes ignore those factors.

Ranking people with different skills sets against each other makes no sense. Yeah, I know lots of companies do it, but the fact that lots of companies do it does not make it a good idea.

Rating on the bell curve is ranking in different dress. The bell curve isn't particularly useful in a small population - like the size of a typical workgroup.

Rating and ranking engender competition, not collaboration.

Most people believe they are above average performers. Disabusing them of this notion does not improve morale, nor does it spur people on to greater efforts. Quite the opposite.

And if everyone is doing their job reasonably well (and if managers are doing their jobs, they are, or they've moved on...) does it help to tell them they're at the bottom of the heap? I think not.

Performance reviews aim for objectivity, but in almost all cases, they are, in fact, subjective.

Year end is a lousy time to tell people how they're doing. It's too late -- why waste weeks (or months) of inadequate performance? The best time to let people know how they are doing is in the present, as close to the event as feasible.

Here's what to do instead:

Have a conversation with each person in your group about how the year has gone. Discuss questions like these:

What were the major events of the year?

What have been the major accomplishments?

What new skills have you acquired?

What have been your struggles?

What contributed to those situations?

What insights do you have, looking back on the year?

What are you most proud of?

How does this inform us going into next year?

What do you want to do better?

Are there new areas you want to explore?

What skills or capabilties will you develop?

How can we build developing those capabilities into daily work?

How will we tell you're making progress?


Do not discuss a letter or number rating or ranking. Just talk.

Have a separate conversation about salary increases.

Find out waht they salary ranges are for the people in your group. Most companies determine salary rates based on the market.They look at how much people in various jobs are paid within their industry and region, then determine where within the range they will aim to pay -- say with 20% of the midpoint salary. Then they have a progression, usually with smaller % raises as the person reaches the top of the range. From this perspective, salary increases are intended to keep salaries pegged to the market and provide reasonable progression as people become more skilled in their jobs. Use what ever pool you have to keep people aligned with in the market rates; don't try to use the pool for "pay for performance." The aim is to pay people fairly, not to entice people with $ rewards (which doesn't usually work anyway).

Start the new year by meeting regularly (weekly or at very least, every other week) with each person on the team. Talk about the person and the work. Coach and provide feedback. Talk about the goals you set in your year-end conversation.

posted by Esther Derby at 5:37:00 PM  

|

The fall conference season is winding down. As I reflect back on the various conferences I've participated in this fall, one talk stands out for me.

It wasn't the content that struck me, so much as the delivery.

At several points in his talk the speaker said, "If you do this/think this, you're stupid." He singled out a number of practices that have been common in our industry for years. Yep, he stood up there and told at least some members of the audience "You are STUPID."

In my experience, telling people they are stupid is not an effective method of persuasion.

In fact, telling people they're stupid causes people to defend their positions more vigorously. After all, who wants to publicly admit they've been foolish, perhaps for many years?

If change agent is part of your role -- you're a consultant, manager, agilist, or you want to improve the engineering practices on your team -- and you see something that you know is not the most effective choice, try on some generous interpretations.

People generally choose the best option from their available alternatives. They may not have the experience or exposure to know other, more effective alternatives.

The choice that appears stupid today, may have made sense at one time. It may even have been an improvement over what existed before.

People may be diligently applying what they've been taught in school. After all, waterfall is still the predominate model taught in CS/MIS programs (when project management is addressed at all). When something that "should work" isn't working, people tend to question their implementation of the method, not the method itself.

Even if what they are doing isn't working well now, it may have worked well in the past.

Assume people are smart, but may not have sufficient alternatives. And give people some emotional space to change without having to plead stupidity.

posted by Esther Derby at 4:30:00 PM  

|

A while back I posted a little riff on the question "Why?". We want to know why, but asking "Why?" isn't always the best way to find out. I offer alternative ways to ask the question.

Reader Shannon Mann recently sent this response:

The person asking is almost always wanting to know something else, and 'Why?' is their verbalisation of their confusion.  When confronted by 'Why?', reflecting some part of the question back to the asker will often open doors to communication (and eliminate the internal strife of having someone question your credibility).

Shannon describes how he responds when his child asks "Why?":

...the first asking of why, I give an answer, the second asking of why, I ask, 'Why do you think this is this way?' (or some such).  Almost every time, the child already has a formed opinion and has little trouble explaining.

The funny thing is every now and then, they respond in a way I didn't expect and a really good dialog ensues.

I love this! I can imagine the conversation playing out with a my 3-year-old niece.

I think it might be a bit dicey, though, if it's your boss asking
"Why?"

This is the conversation running through my head:

Manager: Why is the release late?

You: Why do you think the release is late?

errr. I'm not sure the boss would take that very well.

How about this:

Manager: Why is the release late?

You: I've thought about that a lot; what causes do you see from your point of view?

(Sigh. I've done it again. I've restated a Why question as a What question.)

And I do think this could lead to an interesting dialogue.

Thanks for writing Shannon.

(Sophie's Rule refers to Brian Marick's advice for learning about what customers do -- and why.)

posted by Esther Derby at 5:25:00 PM  

|