merit badge

Duvet-Days! Ever heard of these? It′s a scheme that was popular in the USA a few years back. In it, employees were allocated a number of days where they were entitled to call in and not turn up for work without having to give any reason. They could just stay home in bed, under their duvet, hence the name. I remember it because a company I was working for decided to implement a similar scheme in an attempt to combat absenteeism. Prior to the scheme, employees were trusted to manage their own attendance and any persistently absent members of staff should have been dealt with individually by their line-manager.

The average number of sick-days taken the previous year per-employee was calculated and this was allotted as the duvet-day quota for each employee. The employees were to use the duvet-days whenever they felt unable or unwilling to come into work, for whatever reason, remembering, of course, that they need not give a reason. Once the duvet-days were used up, any further absenteeism had to be accounted for by an official doctor′s certificate or a day′s pay would be lost. At face value, this scheme seemed to benefit everybody. Those that liked to have the odd day off could do so without having to think up an excuse or feeling guilty and those that didn′t, could take the unused duvet-days as an extra holiday allowance, at the end of the year. The CTO thought it was a wonderful idea. As someone who had very few days off through illness, he was looking forward to his extra holiday entitlement.

So, what′s the problem? Well, what we have here is a seemingly fair and balanced system that appears to benefit everybody but is actually unfair, punishing some people for events that they have no control over. Let′s go back to the CTO, with his low incidence of sickness. Without revealing too much about his private life, I know that he had no children, lived alone, and travelled to work on a motorcycle. In contrast to that, one of the employees with a higher rate of absenteeism lived with his wife (a schoolteacher) and three school-age children. For him, travelling to work involved a bus trip, a main line train ride and a further journey on the London Underground. The latter′s chances of catching an infection are obviously much, much higher than those of the CTO are and go a long way toward explaining his higher rate of sickness. Apart from volunteers at the common cold research centre, nobody chooses to catch a cold or the flu, so essentially, the employee was being punished for being married, having children and not owning a motorbike.

The root problem with this plan and others of its ilk lies in the use of quotas and, in particular, quotas that are based on averages. The duvet-days scheme uses an average to define the boundaries of the system, punishes any transgressors, and serves as an excellent example of the inappropriate use of averages in management.

A better approach is to treat it as a system and identify the boundaries by calculating upper and lower control limits using the average plus or minus three times the standard deviation. This is a very common formula from quality management and is also the basis of six-sigma (sigma being the symbol for standard deviation). Any measurements falling within the control limits should be considered acceptable, or common, variation of the system. It is only when measurements fall outside of those limits that further action is necessary. Only a na�ve manager spends time and effort investigating common variation.

But to the uninitiated in such management techniques, the use of averages is tempting and, I suppose, to an extent intuitive they are simple to understand, require only basic mathematical skills to implement and are something we are introduced to at a very early age. Almost from the day we start school we are labelled as above or below average and this is something that often stays with us for the rest of our lives. Can you imagine how parents must feel when told their children are "below average" or "in the bottom half of the class". There is also a concept known as the Pygmalion Effect that says that once an expectation is set, even if it′s wrong, people have a tendency to act in accordance with it. People will actually even change their behaviour to match the expectation. Treat someone as a star and they will act like a star, treat them as a dunce and they will act like a dunce.

Yet still we do it! I was recently asked for help by Tim, the manager of a development team who was having problems completing his quarterly employee appraisals after his company had transitioned to an agile way of working. The appraisal scheme that his company uses requires him to grade each of his subordinates into 6 bands, ranging from the top 5% through the middle down to the bottom 5%. His problem was that when agile practices such as pair programming and collective code ownership are being used, it is difficult to say whose performance contributes most to team productivity. I asked him how he had performed the appraisals before the transition and he replied that in their old system, the ′star′ performers were easily identified and well known. He couldn′t elaborate on that but my guess is that the Pygmalion Effect was in full swing there.

There were a couple of interesting things that I pointed out to him. The first was that one of his previous ′star′ performers hadn′t liked the change to collaborative working at all; he had refused to co-operate with the rest of the team, to the extent that he was obstructive and detrimental to productivity. He eventually found himself employment elsewhere, to the relief of everybody else. The second point was that, since the transition, the team had, for the first time in five years, delivered a project on schedule. Not only that but the project′s second round of testing was cancelled due to the high quality of the code. Something unheard of in this company′s recent history.

So, on the one hand, we have a guy that used to be a star but is now a pain and, on the other hand, we have a team that used to perform poorly but are now stars. Apart from being subjected to some training, the people in the team hadn′t changed; we didn′t perform a lobotomy on the guy that used to be a star to make him less productive. The only thing that changed was the way they worked. Anyone who has studied management will know that the greatest influence on productivity is the actual production system. The usual quote is that up to 85% .of an individual′s productivity is determined by the system they are working in. Even worse, the system you are working in is also influenced by all the other employees who are working in it, just as you influence the system they are working in. Makes it kind of difficult to calculate an individual′s merit, doesn′t it? Dr Deming tells us that the formula for calculating an individual′s contribution to productivity under these circumstances is p = xy where p is whatever is being produced, be it lines of code, defects or whatever; x is the individual′s contribution and y is the contribution of the system. The rules of mathematics tell us that to find the value of x, we first need to know the other two values, so performance related bonuses are impossible to calculate. Even if you could calculate them, the net result would be for the Pygmalion Effect to drive down the performance of those that didn′t get them.

My advice to Tim was to speak to his HR department. I don′t hold out much hope there, though. It seems the general belief that money is the only motivator nowadays and to keep your best people, you need to single them out for special treatment at the expense of the rest of the team. My feeling is that people, especially software developers, are better motivated in other ways and that the use of financial rewards and bonuses is just another example of uninspired management.

I defy anyone to inform me of a truly objective means of assessing the performance of any individual working within a team and I would further defy them to give me a sound reason for doing so. How can merit based pay awards play a part in any organisation that seeks to promote collaborative working?

I′ve often wondered how to justify granting one employee a greater wage increase than another. I know that we often justify it by giving the recipient extra duties or responsibilities as well but if we do this, we divert them away from the task that they originally excelled in. Often there is a ceiling on programmers′ wages so we ′promote′ them into a management or team-leader role giving them greater incentive to stay. We end up with an individual thrust into an area that he has no training or experience in distracted from the subject he is good at by administrative tasks and a manager with little or no leadership skills. This is one of the reasons why our industry is renowned for poor management but we can talk about that another day.

References:
Deming W.E, The New Economics, 1994, MIT Press,

An old management joke:
Q. How do you know you work for a crap company?
A. They have an ′Employee of the Month′ competition.
Q. How do you know you are a crap employee?
A. You′ve been there 5 years and never won it.

First published in Application Development Advisor