> "This is where you're at today. To get to the next level, this is what you need to do. With your help we've put together this plan for your next 3-6 months. You'll finish up A, make sure B gets deployed. C gets checked-in with QA sign off. Do this w/o ticking anyone off or being a general jerk and that looks like Level XYZ"

"Sorry, corporate priorities changed. A and B were cancelled and C was put on indefinite hold. Sure, you did great work on D and E, but those weren't part of your stated goals for this year. Oh, and by the way, there was a re-org and the manager who promised you a promotion isn't your manager any more."

Not saying you personally do that; it sounds like you're a pretty good manager. But I've seen this pattern many times, and know a lot of other people who have experienced it.

That does happen, and when it does you adjust. It's not like your report is about to checkin everythign all at once, he's about to click Commit, and then new marching orders come down just before he presses the button.

Presumably when A gets cancelled, he comes by and says, "A just got cancelled" (or you tell him, depending on how news flows). "This was part of my plan for this cycle, how can we adjust the plan?" And then you discuss giving him proper credit for work on A until it was canceled, and then break down what his new priorities look like.

Or, "I just started work on D, how does this fit in the plan?" "Currently it doesn't, but lets get it in there".

There should be very few things that happen that would be so important that they'd be worth discussion in a promotion that you don't communicate about within a day or two of it first appearing on the radar (if not hours).

The last issue of a reorg is the one that is toughest to deal with. I would talk to their new manager, layout their plans, etc..., but there's no guarantee that the new manager will have the same philosophy.

Being a manager is hard work. And frankly, I'm largely done with people management. It's the hardest job I've ever had, bar none. But its important, and I think some of the problems noted in this article are things good management training can deal with.

Not if your annual targets have already been entered into SAP HR and the system won't let them be modified outside of the appraisal period, and required yes/no answers to them in the next appraisal period for it to do ranking calculations.

Basically if you have a formal appraisal process at all you're trapped in a machine.

You are right, it is not 100% perfect so therefore it should never be used, and we should keep using the much more broken system we have now.

@ken jackson, are you in a position to share what you would consider to be a good definition of what 'the next level' or promotion might look like?

Is it something specific to the individual, or something more general?

I've found it extremely challenging to write a light weight tech progression ladder, that is flexible enough to still be of use on a week by week basis for a specific individual and general enough to provide comparison across teams.

Any thoughts much appreciated (my initial stab can be found here http://fragile.org.uk/2010/09/how-to-appraise-a-developer-pa... it also explains why, despite this thread, I have a need for a tech ladder).

Neil

The way I've done it, although I really don't think its optimal, is to do it on a very individual basis w/ no formal guidelines. What I've found useful is to make all roadmaps publicly available, except for sensitive inforamtion. And then calibrate it upwards. So you as a manager, review with your manager your directs roadmap. You don't have to do this sync up often, but just enough so they can say, "Hmm... Tim's level 3 is doing much more impressive stuff, we probably need to sync up on this". And of course, with everything public you can get feedback from anyone at anytime -- but this happens less often than you might think.

In a big company this will probably lead to discrepencies across orgs. But honestly that probably happens anyways.

That's interesting, I do like the personal approach, but I'm not sure I see how you know to say, 'okay you've progressed enough that you can now call yourself a Senior Software Developer'

Ideally, I think I'd prefer not to have to assign labels at all (for the very good reasons outlined in this thread), but in practice I've found this not to be practical.

>Notice, there's no competition against other employees or any other such race.

there is. Limited promotion and salary increases pool.