What ‘How your company treats exiting staff’ says about you

Nothing impacts your working life like company culture and yet culture is very difficult to assess. This problem keeps me up at night and I’ve written about it before in ‘Why work at your company?’

The trouble is that in many cases, the company itself does not really know that much about its own culture and even if it did, expressing it in a sincere manner is challenging, in fact most companies don’t even try at all.

But how about this as a question to quickly determine a how a company feels about its staff?

“HR hoops aside, what happened the last time someone left your company?”

Seems pretty innocent, no? Every company can answer that question in a positive manner, but I think the variations speak volumes.

For instance, recently we said goodbye to junior (ish) developer, he’d been with the company 18 months and was leaving to pursue a childhood dream to work as an air traffic controller (actually true).

On his last day there was a leaving ceremony where a few words were said in the office and a leaving gift presented, immediately afterwards there was a trip to the pub for those wishing to see him off.

Nothing unusual so far.

But it was the whole office of eighty people that turned out – the parting gifts, while inexpensive, were completely personalised – in this case it was a ‘make your own picture book’ with each picture and audio presenting some sort of in joke – jokes understood by the whole group. In similar situations, gifts have included a ‘time of day’ vs ‘date’ commit plot for a notoriously nocturnal team member, a Wordle of IRC logs for an especially chatty colleague and even a framed 3ware card (his nemesis) for a long suffering sys admin.

The pub trip was not just his team or engineering, but had attendees from across the entire company, and at all levels of seniority. Numbers were high, especially given it was a Friday night.

It was a sad occasion, but in many ways felt like a celebration. ‘Great working with you, can’t wait to see what you do next’ – it’s one thing for your immediate work mates to say this, but how about a whole company?

What struck me was how normal this felt, this is completely standard practice for us. Why wouldn’t we act in this way? On reflection I think that this would be considered unusual at most organisations. Such sends off are not unheard of but usually reserved for especially treasured members of the team. This difference say something about our culture.

By comparison, at my friend’s organisation, a senior (much loved) member of staff of 20 years service cannot even expect their manager to drop into their leaving ceremony. Their reluctance to attend driven by fear of tacit endorsement. It’s the same set up, leaving ceremony followed by pub, but a completely different feel.

How a company treats its exiting employees, speaks volumes to remaining staff. The actions of individuals in response to the leaver, reflect the company’s culture. Since the leaver no longer has any direct value to the company, these actions speak honestly about how the company values people.

So ask yourself, how does your company treat exiting employees and what does it say about the culture? What message are you sending to remaining staff? It is not for management to mandate a leaving procedure, but it is for management to create an environment where people matter.

Identity and Narrative – Managing Change

People hate change, and the reason they hate change is that they really hate change, and that change is hated because they really hate change…….

I’d love to know who said this

All teams are subjected to continuous environmental change, but it tends to be gradual and hard to perceive at a week by week level. I want to talk about the sharp, often unexpected step changes and go into some strategies to guide a team through the worst.

Before diving in, I want to introduce a model for characterising teams. There are two attributes that I consider critical in determining a team’s ability to function.

Identity – Who the team perceive themselves to be, what they value.
Narrative – Why the team exists, what value they bring.

I’m unaware of anyone else talking specifically in these terms but similar thinking appears in Daniel Pink’s ideas of Autonomy, Mastery (both mapping to Identity) and Purpose (narrative) as well as echoes in the higher levels of Maslow’s hierarchy of needs.

Ordinarily, definition of identity and narrative is straight forward. The team will arrive at their own identity over time, while the narrative, for the most part, comes from the commercial arm of the company. In times of change there are no such guarantees. I’ll look at each in turn.

Identity

As an individual, our identity is in part context specific and a function of those around us. The same is true for teams. This means that when the environment changes quickly, it can be difficult for a team to define itself. Definition means identifying the skills and attributes that set it apart and most importantly what it values when compared to those around it.

A manager can help speed this process. They have a birds eye view, they know how their team have defined themselves in the past and have more opportunities to interact with the broader business. The manager ought to be able to spot and highlight specific points that will go and form part of the team’s new, long term identity.

Additionally during upheaval it is for the manager to contextualise the actions and focus of other teams/departments. It’s all too easy to enter into a spiral where ‘everyone apart from us is an idiot’. A team needs to understand how they are different, but they also need to collaborate and work effectively with those around them.

Narrative

Narrative is interesting in that it should be easy to identify. The business is willing to invest in the team for some purpose and that purpose ought to be the team’s narrative.

During times of upheaval this is not a given, and it could take months for a clear narrative to emerge, as the dust settles and the business redetermines the best way for the team to add value.

But waiting months for the new vision is not an option. Put bluntly, if the business cannot provide a compelling narrative quickly then the team manager must arrive at one. Once again it is time to make use of the manager’s elevated view of the organisation to sift through the confusion and draw out something tangible that resonates.

Conclusion

All teams need a sense of identity and a sense of narrative in order to be productive. During times of significant change both of these characteristics come into question. It is up to the team’s manager to act as the catalyst, as the team aims to arrive at new definitions.

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.

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

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

A description of suggested Knowledge Areas
A set of examples to help map real world performance in specific a Knowledge Area to a Capability Level

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.

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.