How to appraise a developer (part 1)

So you have a group of young, smart, driven developers working within a much larger team of young, smart and driven developers. This is in many ways ‘great’, particularly since over time these smart driven developers will drop the ‘young’ part and then things really start cooking.

The thing I’ve noticed is, in groups larger than those that can be counted on fingers and toes, there is a very real need not only to have really good feedback over progression, but also for that progress to be recognised publicly.

Most companies address this need via job titles and annual reviews, in many cases they don’t do a great job and in truth do more harm than good.

My current place has grown rapidly from start up roots and for most of my time there everyone vaguely technical had the same title and we didn’t worry too much about it. As time went on we needed a little more structure and a combined project manager/tech lead/line manager role sprung up.

The difficulty being, that suddenly it then appeared that the only way to get ahead was to move into the management role. Having your best developers move into management for no better reason than it being the only option is toxic. It was clear that it was time to map out a technical path for those who wanted to stay close to the code.

The problem is if you do this, then you need a way to tell people where they are today and what they need to be doing to be considered for the next rung up. If this is going to work it’s going to need to be very flexible otherwise you’ll be forcing people to follow the ladder rather than their own natural progression. Let’s keep motivation intrinsic, kids.

Ordinarily when faced with a really tricky management problem the interwebs are awash with great advice. You need to hire great people? No problem, my meetings suck, easily solved, I’m scared to deploy, are you kidding? But on the subject of an objective method of providing developers feedback, that can then be used to feed into pay reviews and job titles, mainly silence.

I say mainly silence, that’s not fair, there’s SWEBOC that inspired Joel Spolsky and Construx, there’s also the quirky but smart Programmer Competency Matrix.

So I decided to write my own, and I thought I’d share it here. Maybe I can even get some feedback.

So the challenge,

The scheme must satisfy the following :-

• Provide junior and mid range staff something to aim at and work to.
• Provide senior staff who do not wish to enter management an alternate career path without the fear of adversely affecting their seniority or salary.
• Be flexible enough to account for nuances in the role of individuals