How to appraise a developer (resources)

This post provides support and resources for the ‘How to appraise a developer’ series, If you haven’t read the series this post will make no sense whatsoever.

There are two main sections

Suggested Knowledge Areas

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.
Requirements Working with partners/commercial colleagues on an ongoing basis to translate their ideas into something that can be tackled in software.
Quality Activities performed associated with providing confidence that a software item conforms or will conform to technical requirements. Quality is related to testing but considers broader questions such as what strategies necessary to ensure systems work as expected.
Testing Practical means to verify behaviour of a component through unit testing, system/functional testing or manually. Testing is related to Quality but focusses on the practical aspects.
Documentation Activities associated with recording or expressing information about a how a system works.
User Interface Design Designing clear, discoverable user interfaces so that Partners are able to make full use of our systems.
Internal Relations Ability to communicate with and relate to those within the company.
Client Relations Ability to communicate with and relate to clients.
Supplier Relations Ability to communicate with and relate to technical suppliers.
Project Management Resource,task and process management, essentially making sure the right things get done.
Line Management Pastoral care, support and development – most commonly relating to direct reports.
Recruitment Includes CV assessment, interviewing, strategic direct recruitment.

Capability Examples

Below follows some examples to help with assessing a individual’s Capability level for a given Knowledge Area.

The examples are not exhaustive and should be added to over time, what’s more it is not necessary for the employee to satisfy all examples. The examples aim to answers questions like “What does a Practitioner in Design look like?”

Before diving into Knowledge Areas specific examples it’s worth considering the following broad guidelines that can be applied across all Knowledge Areas.

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.


Introductory Can complete simple 1 week (ish) well spec’d tasks/stories alone with some guidance from outside.
Can complete a medium complexity series of tasks/stories spanning a few weeks starting with a fairly loose spec, working along side a more experienced developer.
Practitioner Can complete a medium complexity series of tasks/stories spanning a few weeks starting with a fairly loose spec.
Proposes alternate and superior approaches to problems.
Leadership Takes the lead for large and complicated projects.
Takes the lead on high profile or time critical projects.


Introductory Suggests sensible designs for small stand alone pieces of work.
Practitioner Can be relied upon to reliably produce sensible designs for loosely spec’d medium size projects.
Is sensitive to trades offs between flexibility at the cost of complexity.
Understands the need for maintainable extensible design work.
Leadership Takes the lead for the team’s most difficult design work.
Their work often has system wide architectural implications.
Can point to a number of projects where their design has stood the test of time.


Introductory Is aware of the technologies used by the team and has some idea of the reasons why one might be more appropriate than another.
Is not expected to make technology decisions, but should have opinions on what technologies they might use for their own tasks.
Has some experience of the technologies used by their immediate team.
Practitioner Has a good level of experience of all technologies that the immediate team make use of.
Has had exposure to technologies not actively used by the immediate team
Can reach decisions about library choice for some supporting technology, should we use JMock, EasyMock or Moquito as a Mocking framework?
Leadership Can make broad reaching project level technolgy decisions – what are the implications of upgrading to MySQL 5, is it sensible to do so?


Introductory Can spot obvious problems and make sensible first stabs at resolution.
Knows when to escalate a problem within the team.
Can provide basic support to those outside of the team e.g. A first line support team
Can perform system redeploys, noticing obvious problems, however needs the support of team to fall back on.
Practitioner Confident in the use of investigative tools, events logs also Wireshark or Jprofiler to diagnose and fix problems.
Is capable of deploying systems in isolation.
Leadership Handles the teams’s most complex operational issues, potentially diagnosing bugs in libraries that the team relies upon.
The person turned to for the ‘oh bugger’ moment.


Introductory Understands the rationale behind dedicating time to quality be this unit testing, pair programming, integration testing or otherwise.
Practitioner Regularly suggests ways in which improve the overall quality of the team’s work.
Encourages all members of the team to adopt practices to improve quality.
Leadership Considers the team’s long term strategy.
Can point to series of effective changes that they have instigated to improve quality.


Introductory Understands the importance of unit and integration testing.
Adheres to the team’s testing expectations
Is capable of writing tests where the code lends itself to testing, struggles in more complicated scenarios.
Practitioner Is capable of writing unit tests in all cases where it is sane to do so, making use of additional libraries over and above JUnit where appropriate.
Has a good understanding over what to test for, and writes tests in away that reduces maintenance load over refactoring.
Through system level testing can build a trusted series regression tests.
Where appropriate can devise manual test to reliable verify the behaviour of the system
Leadership Handles or advises on the team’s most complicated testing challenges, suggesting edge cases and reviewing testing strategies.


Introductory Can spot subtle ambiguities in projects on which they are working and asks for clarification.
Practitioner Can work with parties outside of the team to nail down exactly what is wanted, offering advice where the requester is unsure or unclear.
Leadership Is trusted with requirements capture for the team’s largest projects.
Is able to identify alternate approaches to delivering large blocks of functionality.


Introductory Where prompted can write clear descriptions of system behaviour.
With guidance can pitch documentation for the intended audience.
Uses code comments to explain how the code works
Practitioner Understands when and where to document
Does not over document
Code comments often explains why rather than what the code does
Leadership Notices where documentation is missing in a structural sense, creating new wiki/web pages as appropriate
Through good doc design, encourages continual maintenance since doc is often used.
Looks for ways to doc in an automated fashion

UI Design

Introductory Adheres to the team UI style
Considers the impact of their UI decisions
Can propose sensible ideas for simple UIs
Practitioner Proposes sane workable designs for complicated UIs
Leadership Takes the lead for the most complex UI challenges faced by the team.

Supplier Relations

Introductory Can raise well bounded faults.
Can express themselves clearly to suppliers
Typically chooses to communicate asynchronously over email (or similar)
Practitioner Chooses a suitable communication means though is confident to use a real time method.
Can follow up and present a clear argument where the supplier does not agree with our assessment of a fault.
Leadership Draws upon a network of contacts to circumvent bottle necks to achieve their goal quickly.
Through excellent interactions improves our relationships.
Understands when and how to raise matter through commercial channels

Internal Relations

Introductory Can express themselves clearly at a team level.
Practitioner Pitches their communication to a suitable level taking into account their audience and the context.
Has dealings with multiple departments within the company
Leadership Talk confidently to senior members of the company in different departments/countries.
Handles difficult or sensitive issues on behalf of their team.

Client Relations

Introductory Typically chooses to communicate asynchronously
Understand the difference between internal discussion and client facing communication.
Practitioner Understands that some information is sensitive and should not always be given to clients.
Can get to bottom of what clients are *really* asking for.
Can say ‘no’ in a constructive way
Chooses a suitable communication means though is confident to use a real time method.
Leadership Handles sensitive issues with large clients.

Line Management

Introductory Mentors junior members of the team
Assigned to help new members of the team to get up to speed
Practitioner Has formalised Line Management responsibilities
Leadership Line manages other managers.
Introduces new ideas to other line managers
Track record of handling sensitive or difficult line management issues

Project Management

Introductory Can keep track of non trivial lumps of functionality, perhaps they are not the only person working on the project.
Can provide sensible estimates and commitments for non trivial blocks of functionality.
Practitioner Has formalised project management responsibilities. Manages team projects on behalf of the team.
Leadership Manages multiple teams, provides advice and guidance for other PMs
A track record of successfully delivered blocks of functionality.


Introductory Assesses CVs
Can interview along side a more experienced recruiter
Practitioner Able to interview 1st rounds solo
Provides advice on CV review
Implements and develops direct recruitment projects
Leadership Develops interview/ CV assessment system
Instigates new direct recruitment initiatives
Meets with agents
Experienced final round interviewer

2 thoughts on “How to appraise a developer (resources)

  1. I think in many cases here “Introductory” really means someone performing at a basic level who hasn’t gone above and beyond – I think the terminology could be improved to indicate that. People react quite negatively to the term Introductory, when really in many cases if they are there it means they are doing fine.


  2. @Jason It’s a bit tricky that one, I um’d and arr’d about what to go with. I had the same problem with ‘Practitioner’ which was originally called ‘Competent’, the problem being that those who were not yet ‘Competent’ were implicitly ‘Incompetent’ which was hardly the intention.

    I guess it’s not such a problem if the team is generally quite inexperienced and would expect their level to change rapidly or if it’s a skill that is not central to the appraisee’s role, less useful in a more static settled environment. Whatever word you use has to be in some way less than ‘Practitioner’, I did consider lifting the names from those used by Craftspeople but that would make the initial phase ‘Apprentice’ which is even worse.

    You could go for ‘Competent’ as the initial phase but I’m not sure it differentiates itself from sufficiently from ‘Practitioner’.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.