People are not our most valuable resource – a response

Pawel Brodzinski recently wrote a post entitled ‘People are not our most valuable resource’ the point being that people aren’t resources at all , they’re people and should be treated as such.

 

“Every time I hear this cliché about people being most valuable resource I wonder: how the heck can you say people are most valuable when you treat them as resource? As commodity. As something which can be replaced with another identical um… resource. If you say that, you basically deny that people in your organization are important.”

I’m in agreement with Pawel on this point, but I’d go further. Not only is a statement like ‘People are our most valuable resource’ degrading and counter productive, even if you restate it as ‘Nothing is more important than our people’ it’s still incorrect. The real value had nothing to do with people and everything to do with teams.

The key thing that a team provides is a means to align the goals of its members. These goals need not be for the greater good of humanity, in fact they’re generally much more mundane. It really doesn’t matter who wins the world cup* or whether project omega will ship by next Tuesday, all that matters is that the team succeeds in its common goal. A group all pulling in the same direction is orders of magnitude more effective than that same group working as individuals – a business cannot be successful without effective teams.

The trouble is the word ‘team’ is massively over used, it’s a buzzword that has become so ubiquitous we don’t even notice it. The tendency to assemble a group of disparate people and label them as a ‘team’ devalues the concept. One area where this is especially true is that of ‘The Management Team’, generally comprised of middle management peers from various disciplines this group often have very little in common in terms of shared goals and identity.

And here lies the problem, if management is unused to working in a team themselves, then the value of a team is less visible. Furthermore, since it is generally individuals, not the team as a whole, who complete the component tasks the team effect is not obvious from afar.

I don’t think you’ll find an organisation that is anti team, simply that it’s hard prioritise the tasks necessary to encourage team formation when the value of teams is poorly understood. It’s easy to measure the cost of co-location but much harder to measure the benefit to the co-located team, hence the true value of the team is passed over.

Not only are ‘people are not our most valuable resource’, people aren’t our most valuable anything just on their own, it’s all about teams.

[In this post I’ve purposely avoided the subject of how to form a team. It turns out that it’s quite tricky, I’d recommend Peopleware as a good place to start.]

* Except if it’s England of course.

 

 

Hell is for Heroes

Last December I attended the London XPDay, the session I enjoyed most was run by Chris Matts on the subject of Heroes in the context of software development teams.

What makes a Hero?

Chris put forward the idea of the ‘Hero’, an unofficial role assumed by an experienced developer critical to the project. There are positive aspects to the role, this is person turned to in the moment of crisis when something must be fixed ‘right now’, they are the person with the deepest knowledge of the system and an indispensable contributor to the project.  As with many things, however, this strength can also be a weakness. The feeling of being indispensable is very powerful and freely sharing knowledge and collaborating with other less experienced/capable team mates only undermines this feeling. If the Hero is no longer the only person who can fix the problem, surely that makes them less important?

In extreme cases the presence of the Hero becomes toxic, reluctance to collaborate is unpleasant, but active obstruction and obfuscation is something else. At this point the team/project has some serious problems. On the one hand it is doomed to failure without the Hero, on the other-hand, the ability of the group to act as a team evaporates and progress on the project is brought to all but a standstill.

What to do when a Hero goes bad?

We spoke for about an hour on the subject and while there were one or two examples that partially dealt with the problem, ranging from ‘move them to another project’ through to ‘fire them’ (!), no-one in attendance was able to provide a truly positive example of recovering from such a scenario.

I am fortunate in never having worked with anyone quite as extreme as the examples presented in the session, but where I have seen glimpses of this behaviour my sense is that overwhelmingly, the behaviour is the product of environment rather than necessarily any failing on the part of the individual.

The participants in the session, seemed to be made up of managers/coaches rather than out and out developers, which may explain why much of the discussion seemed to presuppose that the fault lay solely with the Hero.

Common environmental factors that I have observed include:-

  • Perceived ambiguity over who has technical responsibility for a system
  • Poor performance feedback and/or poorly communicated career development
  • Lack of trust/respect amongst team mates
  • Seemingly overwhelming operational issues
  • Compensation schemes pitting team mates against one another

It is the manager not the Hero who has most influence over these points. So I think that before answering the question ‘What to do when your Hero goes bad?’, a better question, as a manager is ‘What have I done wrong to allow my Hero to go bad?’.

Focus on Teams

Unhelpfully, as with all management problems, the best way to solve the problem is not to have it in the first place. Placing greater emphasis on the performance of the team rather than on the individual can help here. Any action that benefits the whole team is recognised and celebrated so the Hero need not lose prestige by supporting those around him. In fact the Hero’s standing increases since he is now multiplying his own capability through increasing the skills of the team. As a side effect, since the team is now more capable the Hero has more time to spend on the truly difficult problems, which in time, he will pass onto the rest of the team.

Switching focus away from individuals and towards the team is a non trivial exercise, but if the agile movement has brought us anything it is methods to engender collaboration, trust and team level thinking.

What being in a band taught me about management

The only way to learn to manage is to do it;
and the only way to do it, is to do in front of people;
and the only way to do it front of people, is make a bunch of mistakes in a very public forum;
and the only saving grace is that, as an inexperienced manager, it’s really not clear quite how many mistakes are being made.

Me, ranting, in a pub, in West London

This, of course, is of small consolation to the manager’s team.

So the question is, how do we train people for team management without causing pain and suffering to the team? I don’t think there’s a simple answer, but it definitely helped me to have a chance to learn something outside of my professional life.

Back in the days when I had silly hair and green shoes, I used to play guitar in a band. Much like software teams, the problems a band faces are as much social as they are technical. A band needs someone to draw the group together, drive things forward and turn a bunch of dreamy-eyed losers into a bunch of dreamy-eyed losers who, you know, might get a gig. I’d love to think that I was in the band for my guitar excellence, but in truth my job was to keep things together. Sadly the Lonely Crowd never quite made it beyond the indie dives of London town, but it taught me a huge amount that I would later apply in managing teams of software developers.

Trust is key

Without trust it’s not possible for the group to work effectively. I’m not talking about trusting someone with a winning lottery ticket, more that I know I can rely on that person in the context of the project. Once the trust is gone the band is gone, it’s not coming back. Similarly, as a manager, my effectiveness is directly related to the trust within the team.

No need to motivate, just don’t demotivate

Generally, people who form bands are motivated passionate people, no-ones’s getting paid to be there, and even those more interested in impressing girls/boys than music, need to make sure the band is as good as it can be. The easier it is for the group to concentrate on turning ideas into songs and turning songs into set lists, the more satisfying the whole thing will be. So don’t worry about motivation, focus on removing obstacles and dealing with cranky promoters.

Provide a vision

Often the line between creative spark and creative fleurgh is very thin. Someone has to provide a vision for the group to work towards. In my case this meant coming to the band with rough song ideas, I’d bleed over these things in my bedroom, secretly very proud of my work, only for the rest of the guys to mutate it into something excellent. The point is that without that first step nothing would have happened. Remember that the aim is not to be the best musician, it’s to make the best musicians better.

Roles and responsibilities

A band has distinct roles, when people talk about the Beatles they rarely start with George Harrison, but his considered rhythm guitar parts made it possible for Lennon and McCartney to steal the show, similarly Bill and Ted were never going to get anywhere on their own. The point is that everyone needs to understand where they fit and exactly what they bring to the group, if the drummer is thinking like a lead guitarist, the band will sound awful no matter what.

Feedback

Without good feedback the music will suffer, either through a lack of innovation or through a lack of quality control. The key is finding a way to express your thoughts, good or bad, without it being taken personally. Thinking managerially, the aim should be that the whole group can provide good feedback. Doing so effectively requires a high level of trust within the group as well as a sense of when to intervene if the criticism becomes destructive.

Limit work in progress

Getting a song to a performable state is massive step. It brings the group together and feels like progress. It’s better to have three presentable songs than nine nearly finished ‘things’, not least because it then provides a means for feedback from outside of the group.

Manage internal tensions

Where passionate people collaborate there will always be differences in opinion. Impassioned debate is healthy and a sign that band mates care about the project, but sometimes things get out of hand and it’s necessary for a third party to mediate. Generally it comes down to a breakdown in communication and trust, problems are often best fixed away from the rehearsal room and after the event once all concerned have had a chance to calm down.

So what are you saying Neil, before a new manager starts out they should spend three years in Spinal Tap? Hardly, but training for people management is a tricky subject. At some point it’s necessary to dive in with a real team, accept that mistakes will be made and aim to learn very quickly indeed. The thing is there are plenty of opportunities to gain an introduction outside of work, for me it was guitar wrangling, I’d love to hear what other people have found helpful.

How I Manage Technical Debt

debt pillIn the previous post, Technical Debt is Different, I talked about the need to treat management of technical debt as a separate class of problem to that of feature requests generated outside of the team.

As with any project above a certain size, team collaboration is key, and that means having a reliable method of prioritising technical debt that the whole team can buy into. This post will describe a method that I have been using over the past year that satisfies this need.

Identify

I was new to my current the project and wanted to get an idea from the team of the sorts of things that needed attention. I mentioned this just before lunch one day and by the time I got back from my sandwich I had an etherpad with over 100 hundred items. By the end of the afternoon, I discovered that etherpad really doesn’t deal with documents above a certain size.

It was clear that we needed to a way to reference and store these ideas, I had two main requirements.

  • It was easy to visualise the work items
  • An easy, non-contentious way to assign priority

The first step was to go through the list and group items into similar themes, this helped identify duplicate or overlapping items. At this stage some items were rewritten to ensure that they were suitably specific and well-bounded.

Prioritise

Now that we had a grouped list of tasks it was time to attempt to prioritise. As discussed in the previous post, prioritising refactoring tasks can be challenging and passions are likely to run high. I felt that rather than simply stack ranking all items, it was better to categorise them against a set of orthogonal metrics. This led to a much more reasoned (though no less committed) debate of the relative merits of different tasks.

Every item was classified according to:-

  • Size
  • Timeliness
  • Value

Size

The simplest metric, this is a very high level estimate of what sort of size the item was likely to be. Estimating the size helped highlight any differences in perceived scope, and in some cases items were broken down further at this point. Size estimation works best when estimates for tasks are relative to one another, however to seed the process we adopted the following rough convention.

  • Small – A week
  • Medium – 2 weeks
  • Large – 3 weeks for 2 people

Timeliness

Timeliness speaks of how the team feels about the task in terms of willingness to throw themselves into it. Items were assigned a timeliness value from four options.

  • ASAP – There is no reason not to do this task right now. Typical examples include obvious items that the team were all highly in favour of, or items that the team had been aware of for some time and feel that enough is enough.
  • Opportunity – An item that lends itself to being worked on while the team is already working in the area.
  • Medium term – An item that is thought of as a ‘wouldn’t it be nice some day’. The items are typically riskier than ASAP or Opportunity and the team need to really commit to it’s execution before embarking on the item.
  • Long term – Similar to medium and generally populated by reviewing the medium section and selecting items that are imposing or risky enough to postpone behind other medium tasks.

Value

How much will the team benefit from the change? Is it an area of the code base that it touched often? Perhaps it will noticeably speed development of certain types of features. It could be argued that Value is the only metric that matters, however Value needs to be considered in the context of risk (addressed through timeliness) and effort (addressed through size).

All items for a given Timeliness are measured relatively and given a score of ‘High’, ‘Medium’, ‘Low’. Low value items are rarely tackled, and even then, only if they happen to be in the Opportunity category.

Visualise

Once all items had been classified, it is time to visualise the work items. To do this we transferred the items to cards and stuck them to a pin board, with timeliness on the horizontal axis and value on the vertical axis (each card contained a reference to the task size). Now it was possible to view all items at once, and from this starting point much easier to make decisions over which items to take next.

Since the whole team had contributed to the process it was clear to individuals why, even though their own proposals were important, that there was greater value in working on other items first. Crucially, we also had a process to ensure that these mid-priority items were not going to be forgotten and trust that they would be attended to in due course.

Technical Debt Board

When a task is completed, we place a red tick against it to demonstrate progress, this helps build trust within the team that we really are working off our technical debt. Sometimes a specific piece of work, as a side effect, will lead to the team indirectly making progress against a technical debt item. When this happens we add a half tick, indicating that this card should be prioritised over other similarly important items so that we get it finished off completely.

Tiny Tasks

This system is effective in reducing the stress that comes with managing technical debt and provided a means for all the team to have a say in where the team spent their effort.  However, one area where it is weak is in managing very small, relatively low value tasks that can be completed in an hour or so. Examples might include removing unused code, reducing visibility on public fields, renaming confusingly named classes – in essence, things that you might expect to happen as part of general refactoring were you already working in the area.

To manage these small easy wins, the team maintains an etherpad of ‘Tiny Tasks’ and reviews new additions to the list on a weekly basis.  The rule is that if anyone considers a task to be anything other than trivial it is thrown out and considered as part of the process above. These tasks are then picked up by the developer acting as the maintainer during the week.

So what does it all mean?

Generally it is easier if an individual has final say of the prioritisation of tasks, in the case of technical debt this is harder since the whole team should be involved. Therefore, a trusted method of highlighting and prioritising technical debt tasks is needed. By breaking down the prioritisation process into separate ‘Size’, ‘Timeliness’ and ‘Value’, it was possible to have more reasoned discussion over the relative merits of items. Visualising the items together at the end of the categorisation process enables the team to make better decisions over what to work on next and builds trust that items will not be simply forgotten. Very small items can still be prioritised if the team agrees that they really are trivial.

The Best Job in the World

“What the worst job you’ve had” sings Stevie Jackson on Belle and Sebastian’s Chickfactor. Now I appreciate that in this world many people find themselves with no choice but to accept work in awful conditions, but in the rosy context of a teenager growing up in the suburbs of London I’ve had some questionable jobs. I was happy to have them but if you ever wondered how shops that sell ice cubes in bags get those cubes into the bags, well it’s not as automated as you might think.

However the job that I really loved during that period was at large super market. My job was to make sure that all the shopping trolleys moved from the trolley drop offs dotted around the car park, back to the front of the shop, so that new customers had a trolley to hand.

On the face of it, this job was just like any other that I had had, it had little variety, was physically tiring and was hardly something I could use to  impress girls, and remember these were girls who were impressed by people who tore tickets at the cinema.

So why did I like it so much?

I think the best way to answer that is to draw upon Daniel Pink’s book Drive. He proposes that the three tenants of intrinsic motivation are:-

  • Autonomy
  • Purpose
  • Mastery
Let’s examine each in turn

Autonomy

No one cares about the trolley guy, unless there is a lack of trolleys, so you can pretty much do what you want. Iterating over a strategy as you please. It was sunny, I had my walkman on and had no one to answer to for the entire shift.

Mastery

Pushing 10-15 trollies in a chain is rarely a good idea, especially in with so many cars close by. But if that’s all you do, you get pretty good at it. You learn to control the leading trolley by gently arcing the chain and you learn how to judge the delay from starting a turn to the leading trolley responding.
At a more strategic level, you can greatly reduce you workload once you understand that some parts of the car park will be busier at certain times. In the mornings every one scrambles for the spaces closest to the entrance, in the afternoons people have areas that they always return to.

Purpose

It’s hardly saving the world, but it’s a job that had a clear benefit to shoppers. If you made sure people had trolleys, they had something to put their food in. Shopping for food in such a place is pretty hellish, it would be even worse without a basic necessity like a trolley.

So the question is, if it’s such a great job, why don’t I do now? Why isn’t this just a sentimental piece about a job that was actually pretty rubbish when it rained?

Well the thing is, as a sixteen year old, it satisfied my expectations. I could have earned more elsewhere but I felt reasonably well paid (for my age), and in terms of professional development, I really didn’t care, it wasn’t a long term career choice.

If I took the job now both of those points would cause problems, I have a mortgage to pay, and I expect my job to stretch and teach me things.

So the perfect job matches, at the very least, general expectations but also satisfies the individual’s need for autonomy, mastery and purpose.

Vitamins and pain killers

A while back there was a thread on Hacker News asking why there is no search functionality, Paul Graham responded with:-

What makes users happy is not features, but the quality of the submissions and comments. So I focus on the latter instead of the former …… This is a classic example of how one should give users what they want, not what they say they want. Lots of people say they want search, but I would be surprised if there was a single user who’d left HN because it lacked search. Whereas if I let the front page get filled up with crap, or the comment threads filled up with mean or stupid comments, people would start leaving pretty quickly….

The point being that the absence of some negative behaviour can be more valuable than the  presence of some positive behaviour. The more effective you are at removing negative behaviour the less people will notice your efforts since the pain point is hidden from them.

I think management is great example of this, sure there will be times where your actions are highly public and obvious to all, but you really earn your bread and butter by working furiously to maintain a state where your team can simply get things done. If anything, too many active interventions should be a warning sign that you are not picking up on things quickly enough.

How to appraise a developer (part 3) – A worked example

This post forms part of series, if you’ve not done so already you may want to take a look part 1

Last time round I promised to provide a worked example of how the scheme might work, this post will chart the early careers of two fresh out of university  programmers, Alice and Bob. Alice and Bob are both smart people but have very different skill sets, Alice is a hard core dev and really has no desire to go into management, Bob on the other hand is weaker in terms of pure programming but is better with people and organisation.

This example is a little artificial since, in order to show case the scheme, Alice and Bob are pretty much polar opposites. Real world examples will be much more subtle, though hopefully by demonstrating a toy example it will become clear how to apply the same ideas once real people are involved.

Day 1

Our story begins as Bob and Alice join FantastiCo as graduate programmers. At this stage it is only necessary to identify the Core Knowledge Areas for their respective roles.

Alice

Alice is working on FantastiCo’s core platform, she has no customer facing responsibilities and while she works within a larger team, has no responsibilities outside of the code that she produces.

Bob

Bob will be writing plugins to unleash the awesome power of the FantastiCo’s core platform, the plugins are typically developed with a lot of client interaction and while Bob will not be expected to deal with clients on day one, once he gets up to speed this will become a significant part of his job. At this point his Core Knowledge Areas are the same as Alice’s but also include the ‘Client Comms’ Knowledge area.

6 Months

Alice

Alice is progressing well and coming along as expected, she has made less progress in areas such as Quality and Design though at this stage this is really just a reflection that her role is not yet providing the necessary opportunities.

Bob

Bob is clearly a good communicator but there are concerns that he doesn’t spend enough time testing his code. Like Alice, Bob has not made very much progress in Design and Quality but at this stage this is not a concern.

18 Months

Alice

Alice is demonstrating considerable technical skill and this is reflected in a strong performance in Construction and Technology. She is starting to approach the criteria for progressing up to Software Developer ii. The best way to do this is look at moving Operations or Design up to full Practitioner. It is also worth noting that Alice is starting to develop Project Management skills despite this not forming part of her Core Knowledge Areas

Bob

Bob continues to develop well in communications and while not as strong at Construction he is close to reaching Practitioner status. He is still not making progress against Testing and Quality which is starting to limit his effectiveness. In order to be promoted to Software Developer ii he needs at least three Core Knowledge Areas at Practitioner and the remaining Core areas at least Introductory. He’s getting close but he needs to start taking more care in ensuring that his code does what he says it does. Like Alice, Bob is also making progress against Project Management.

2 Years

Alice

Based on the proposed Ladder Levels, Alice is now at the stage where she can be considered for promotion to Software Developer ii. Her manager is very a happy for this to happen and Alice is promoted.

Bob

Bob has shown improvement against Quality and Testing, but still does not have the practical skills to adequately test his code, ultimately this limits Bob’s overall effectiveness and blocks him being considered for promotion to Software Developer ii.

2.5 Years

Alice

Now that Alice is becoming increasingly able she is taken on more responsibility for Project Management, while she does not have formal project management responsibilities it is now an important part of her role and has been added to her Core Knowledge Areas.

Bob

Following his previous review Bob has worked hard to improve his testing skills and he is now ready for promotion to Software Developer ii. Bob has joined the mentoring scheme and this is reflected in his progress against Line Management.

4 Years

Alice

Alice is now a highly respected developer and is starting to approach the point we’re she can be considered for promotion to Software Developer iii. Note that despite the fact that she has started interviewing, Recruitment is not a core part of Alice’s role.

Bob

Bob has recently shifted roles and is the Technical Project Manager of a small team. As such his Core Knowledge Areas have changed, in Bob’s case it is appropriate to remove Construction and Testing. Note, Bob’s role has changed but he still remains at the same ladder level of ii, having said that his new role means that he has greater responsibility than he did as a Software Developer ii and is compensated accordingly.

5 Years

Alice

Alice has been promoted to Software developer iii but has also shifted roles to Tech Lead , her project manager considers her input into the personal development of team as an important part of her role and Line Management is now a Core Knowledge area, despite there being no expectation that Alice will progress past Introductory. The shift to Tech Lead brings with it greater responsibility and this is reflected in her compensation, it is important to note that Alice could have stayed as an individual contributor without this negatively affecting her ladder level.

Bob

Now as an experienced Project Manager, Bob has reached Technical Project Manager iii status. He has become rusty development wise and his score against these areas has deteriorated since Construction and Testing are no longer Core Knowledge Areas, this is not a problem.

Walk Through Conclusion

After 5 years Bob and Alice consider themselves to be peers despite following very different paths and having very different skills sets. Alice worked consistently well through out the period whereas Bob was initially held back by his skills in Testing and Quality.

Series Conclusion

The scheme’s original aims were 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

I think the scheme as it stands makes some real progress against these goals but there is still plenty to be done. Future work might include improving the examples section, refining the Knowledge Areas and tuning the criteria for ladder levels.

This is the last post in the series, I’d be very interested to hear of the experiences of others trying to solve a similar problem, please feel free to get in touch via comments or if you would prefer via email (neil at this domain).

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.

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

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.