How to appraise a developer (part 2)

This post forms part of a series, if you’ve not done so already you might want to check out part 1.

So last time I talked about why on earth you might want a performance appraisal process, this time around I want to go over the scheme I came up with. At this point, I’d like to stress that an annual review is useless without continual follow up via day-to-day interactions as well as specific time set aside for 1-1s. Furthermore, without good management you will always fail, whatever the process.

The key aims of such a scheme are to

  • 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

Warning

This post contains phrases like ‘Core Knowledge Area’ and ‘Capability Level’, I have managed to avoid ‘Leverage Synergies’ but you get the idea. You have been warned.

Areas of investigation

Before starting it seemed sensible to see if there was anything already out there that I could make use of. By far and a way the best resource I found was the Construx Professional Development Ladder, which in turn is heavily based on SWEBOK.

I also looked into Dreyfus modelling, which is a way of characterising improvement in a particular skill and used by coaches of all disciplines, from what I can tell the SWEBOK (and Construx) capability levels are based on the Dreyfus approach.

Overview of the scheme

Overall performance is split into a number of Knowledge Areas, this means that strong or poor performance in one area does not affect performance in another unrelated area. Once defined, Knowledge Areas are assessed against standardised Capability Levels and the resulting spread of skills is reduced to an overall Ladder Level.

This means that people with wildly different roles can be expressed in terms of one another, this is absolutely crucial in tackling the question of progression for senior developers who do not have formal management responsibilities.

The appraisee has full visibility over the analysis which forms the basis for further professional development and only the final aggregated level is made public.

Knowledge Areas

Before anything can be done it’s necessary to find a way to break down the role into specific skills, this means that feedback can be provided in a very targeted manner. Good appraisers do this naturally but since the feedback needs to be quantifiable the extra layer of formality is necessary.

I’ve identified 15 knowledge areas, these are largely based on the SWEBOK areas with a few additions/alterations to reflect my specific working environment. Were I thinking about including a wider range of roles (e.g. Sys Admin or Support) or to consider such a scheme for another company, then this table would need to be adapted.

The full list lives here, but a couple of examples include :-

Knowledge Area Description
Coding The creation of software according to a specified design. The primary activity is creating code and configuration data to implement functionality using the selected languages, technologies, and environments.
Design The bridge between requirements and construction, design defines the structure and dynamic state of the system at many levels of abstraction and through many views.
Technology The use of tools, technology, methodologies, and techniques for software engineering.
Operations System installation, deployment, migration and investigation. Working safely with live systems.

Core Knowledge Areas

It is not the case that all developers should expect to score highly in all areas, in fact the point of the scheme is to recognise variance in roles. As such some Knowledge Areas will be unavailable to some appraisees, Recruitment is a good example. However it is important to recognise that some Knowledge Areas areas are central to the performance of the individual regardless of what else they are able to contribute and that they are expected to score well in these areas. For example it is hard to envision a Software Developer for whom Coding is not a core skill however it may not be necessarily be a core skill for a Project Manager.

For each individual the appraiser must select a a group of Core Knowledge Areas to reflect what is most important about the role. Roughly ten Core Knowledge Areas from the total fifteen feels about right.

Capability Levels

Once the Core Knowledge Areas have been identified, it is time to grade each level. This part is fraught with problems and I’d be kidding myself if I thought this step could be completely fair. However I found the following to be a serviceable starting point.

Capability Level Description
Introductory The employee performs or is capable of performing basic work in an area, generally under supervision. The employee is taking effective steps to develop his or her knowledge and skills. In general the employee looks for support and guidance from the immediate team
Practitioner The employee performs effective, independent work in an area, serves as a role model for less expert employees, and occasionally coaches others.
Leadership The employee performs exemplary work in an area. The employee regularly coach employees and provides project as well as tech team level leadership. The employee is recognized within the company as a major resource in the knowledge area

In the future it may be necessary to define a level of achievement above Leadership, in which case it could be defined as “The employee is universally acknowledged by those who have achieved Leadership in a particular knowledge area to be a company expert in the area – essentially providing leadership for those already at Leadership level”.

Mapping actual performance to Capability Levels is made much easier through example and I’ve included a selection broken down by Knowledge Area here. In the general sense I have found the following to be a good guide.

Introductory Rarely coaches others.
Looks to the team for support and guidance.
Practitioner Occasionally coaches others, usually those at Introductory level
Occasionally introduces new ideas and practices to the team.
Leadership Regularly coaches others, their own skills and expertise are amplified through the help that they provide.
Regularly introduces new ideas into the team with examples of where these ideas have been adopted.

Ladder Levels

Once the appraisee’s Knowledge Area’s have been defined and assessed an overall ladder level can be assigned. This is important because this is the only part of the scheme that it made public to the company as a whole. In my current context three levels feels most natural. Other teams may benefit from a higher resolution.

Level Requirements Description
i Default grad level Entry level position, makes a positive contribution to the team but requires support and guidance from those around them.
ii 3 areas at Practitioner and Introductory in all other Core Knowledge Areas A key member for their team, they are able to work with little guidance and act as a trusted peer to other grade iis as well as providing support to those less experienced. Team members on this grade will have a few years commercial experience.
iii 3 areas at Leadership, 8 areas at Leadership and Practitioner combined and finally Introductory in all other Core Knowledge Areas A leader at development team level and a significant contributor to the tech team as a whole.

Summing up

So in summary, look at the appraisee’s role, pick the most important attributes and mark them as ‘Core’. Then grade them against all Knowledge Areas, this forms the basis for further professional development. Turn the handle and convert the assessment into a ladder level and hey presto people with disparate job roles can be recognised for their seniority regardless of whether they are pure devs or pure managers, or most probably some combination of the two.

As with anything, I’m always keen to reduce process to the barest minimum possible without things  descending into chaos and I’m aware that at first glance this scheme might feel quite heavy. However without formally breaking down a role, I can’t see a fair and transparent way to appraise technical staff.

Next time round I’ll post some worked examples of how to apply this in practice.

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

In part two I’ll outline what I came up with.

Motivation (almost) for free

Individuals and interactions over processes and tools

So reads the first line of the Agile Manifesto. Agile (and Lean) frameworks differentiate themselves from traditional software project management in the value that they place in people.

I’m always confused when I people attempt to separate out line and project management in the context of software. To me they are intrinsically linked, and cannot meaningfully be considered in isolation. In fact I’d go so far as to say that one of the principle drivers of the agile movement is not so much what it says about project management, significant as that is, but more what it says about motivation and simply letting smart people get on and do their jobs.

As an illustration, I’d like to use Martin Haworth’s ‘Ten Tips About People Management’ as a representative article of a more general approach to people management. For each point I’ve highlighted how it is commonly addressed in the context of an agile team.

1. Talk to Your People Often
By building a great relationship with your people you will bring trust, honesty and information. This gives you a head start in Performance Management of your people.

Daily stand ups provide a frequent and regular period to interact with the team. It doesn’t provide one on one time but it does mean that raising impediments and sharing of ideas is common place such that it then feels much more natural for one on one conversations to occur.

2. Build Feedback In
On the job two-way feedback processes gets rid of the nasty surprises that gives Performance Management such a bad name. By building it in as a natural activity, you take the edge away.

Agile is all about rapid feedback. Both at a technical level in the form of TDD and CI and a personal level through daily stand ups and a commonly agreed definition of done.

3. Be Honest
By being frank and honest, which the preparation work in building a great relationship has afforded you, both parties treat each other with respect and see each other as working for everyone’s benefit.

With lead times measured in days, trust and openness are essential for any agile team, where honesty does not exist the whole process collapses.

4. Notice Great Performance
When you see good stuff, shout about it! Let people know. Celebrate successes and filter this into formal processes.

At a team level daily stand ups and visualisation of work flow provides this for free. Furthermore, since features are delivered in a state ready for production, regular product demos provide the customer with a hands on measure of progress.

5. Have a System
Performance Management is a process and needs some formality – especially for good personnel practice and record. This need not be complicated, but it needs to be organised and have timescales.

Agile frameworks have little to say directly on the subject of performance management, though there is an assumption that team members are continually looking to improve their skills and performance. Agile working models introduce the idea of cadence where there is a period dedicated to retrospection and continuous improvement.

6. Keep it Simple
But do keep it simple. If you have a relationship with your people that is strong anyway, you already know what they are about. Formal discussions can be friendly and simple, with formality kept to a minimum.

With an emphasis on verbal communication, it’s easy to have serious conversations in a relaxed but constructive manner.

7. Be Very Positive
Celebrate great performance! Focus on what’s going well. It’s about successes and building on strengths, not spending ages on their weaknesses – that serves no-one. Go with the positives!

Again, constant feedback through regular delivery of working software, reinforces and encourages good practice.

8. Achieve Their Needs
Remember that we all have needs that we want fulfilling. By working with your people to create outcomes that will do this, you will strengthen your relationships and channel effort in a constructive direction.

Since teams are typically cross functional, team members are exposed to a range of challenges, and have a clearer idea of where they feel they are strongest. While an agile framework does not specifically look to fulfil the longer term needs of an individual, it at least attempts not pigeon hole them into a specific roles.

9. Tackle Discipline
Whilst it often happens, Performance Management is not about managing indiscipline. That has to be managed in a different way. By setting clear standards in your business that everyone understands and signs up to, discipline becomes much, much easier.

In the same way that team success and good performance are highly visible to the team, individual poor performance is also obvious. Expectations of good practice are generally arrived at through team consensus and so could not be clearer. If the expectations are inappropriate or unrealistic then the team has the power to amend as necessary.

10. Learn from Mistakes
As part of regular on-the-job and informal review, mistakes will come to light; things will go wrong. By using the ‘What went well? And ‘What could you do differently?’ format, the unsatisfactory performance becomes controllable and a positive step.

Where teams are correct to take take credit for their success, it is equally important that take responsibility for failure. Examples include retrospectives or Lean style 5 Whys root cause analysis.

Software is an industry not always known for the strength of its people management, by pushing human issues to the fore agile and lean frameworks ensure that not only is the management of of the project considered, but also the management of the people. In a practical sense, while applying agile principles won’t necessarily make me a good manager, they make me less likely to be a bad one.

Agile makes me SMART

Performance review 101, objectives should be SMART. Theoretically, SMART objectives make an awful lot of sense to me, but when asked to set objectives for a developer to cover the next 6 months it really doesn’t feel practical.

Normally, where I have a management problem, the agile community is a great source of inspiration and advice. It turns out that while it has little to say about performance review (why should it?), I’ve been using SMART objectives all along in the form of stories.

Let’s have a look at what SMART means and how it applies to stories.

Specific

By breaking down epics into manageable features it’s possible to isolate a small chunk of behaviour, such that all involved have a clear of idea of the scope of the problem.

Measurable

Acceptance tests provide a clear means to determine when the story is done. In many cases the tests can be expressed in terms of ‘Given a set of preconditions, when a specific event occurs, expect the following behaviour’, this serves to reduce ambiguity and provide black and white tests to determine success.

Attainable

Stories are estimated by the developers charged with their implementation. If the developers cannot see a way to approach the problem then it will not be possible to provide an estimate and the story cannot be accepted. At this point the story will either need to be broken down, or reconsidered before being re-estimated in its new form.

Relevant

The story must in some way relate to the bigger picture, to do this stories refer to features recognisable by the customer as opposed to tasks recognisable only to the development team.

Time Bound

Working in time boxed iterations, or alternatively a work in progress limited flow, means that clearly defined expectations for delivery exist. Where these expectations are not met is is clear to all and it is time to discuss what went wrong.

I have a long held belief that one of the main reasons that the agile movement has been so effective is that it builds good management practices in from the ground up. SMART objectives in the form of stories are just one example.