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
| 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. |
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. |
Coding
| 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. |
Design
| 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. |
Technology
| 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? |
Operations
| 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. |
Quality
| 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. |
Testing
| 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. |
Requirements
| 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. |
|
|
Documentation
| 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. |
Recruitment
| 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 |
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.
@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’.
N