{"id":260,"date":"2010-09-05T14:03:39","date_gmt":"2010-09-05T13:03:39","guid":{"rendered":"http:\/\/fragile.org.uk\/?p=260"},"modified":"2010-09-05T14:03:39","modified_gmt":"2010-09-05T13:03:39","slug":"how-to-appraise-a-developer-part-1","status":"publish","type":"post","link":"https:\/\/fragile.org.uk\/index.php\/2010\/09\/05\/how-to-appraise-a-developer-part-1\/","title":{"rendered":"How to appraise a developer (part 1)"},"content":{"rendered":"
\n

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 \u2018great\u2019, particularly since over time these smart driven developers will drop the \u2018young\u2019 part and then things really start cooking.<\/p>\n

The thing I\u2019ve 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.<\/p>\n

Most companies address this need via job titles and annual reviews, in many cases they don\u2019t do a great job<\/a> and in truth do more harm than good<\/a>.<\/p>\n

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\u2019t 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.<\/p>\n

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<\/a>. It was clear that it was time to map out a technical path for those who wanted to stay close to the code.<\/p>\n

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\u2019s going to need to be very flexible otherwise you\u2019ll be forcing people to follow the ladder rather than their own natural progression. Let\u2019s keep motivation intrinsic, kids<\/a>.<\/p>\n

Ordinarily when faced with a really tricky management problem the interwebs are awash with great advice. You need to hire great people? No problem<\/a>, my meetings suck, easily solved<\/a>,\u00a0I\u2019m scared to deploy, are you kidding?<\/a> 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.<\/p>\n

I say mainly silence, that\u2019s not fair, there\u2019s SWEBOC<\/a> that inspired Joel Spolsky<\/a> and Construx<\/a>, there\u2019s also the quirky but smart Programmer Competency Matrix<\/a>.<\/p>\n

So I decided to write my own, and I thought I\u2019d share it here. Maybe I can even get some feedback.<\/p>\n

So the challenge,<\/p>\n

The scheme must satisfy the following :-<\/p>\n