As you may have picked up from my last post, I am a Bradford City fan having spent 13 years of my life growing up in the city. However, this post discusses the Bradford Factor a method recently introduced at my work to provide insight into staff absence.
Its calculation is very simple. Take the square of the number of times a person has been absent from work (S) and multiply it by the number of days they have been absent (D):
Anyone scoring above 125 over a period of 1 year should be investigated to find out why their score is so high. Anyone with a score over 500 could face disciplinary action.
So what does that look like for an average employee. From this article in The Times last year it describes the average private sector worker as having 6.4 days off in a year. We don’t know how those 6 days are spread, but lets take a look at a few scenarios:
Taking 1 day off 6 times in the year:
B = 6 x 6 x 6 = 216
Taking 6 days in 1 go:
B = 1 x 1 x 6 = 6
Taking 2 days off 3 times over the year:
B = 3 x 3 x 6 = 54
Hmm. Is that right? If I have (slightly less than) the average number of days off in the year, but I do so in 6 episodes I will be investigated and have to explain why I have been missing from work.
At the heart of the philosophy of using the Bradford Factor is that it is frequent short absences that are the most disruptive. That may be true in some sectors, especially where alternative cover must be found, but what about software development?
In my experience, the longer the absence the more disruptive the absence is to the project. Missing a day on a software project is rarely an issue, but missing a week can destroy its chances of success. If a software developer has to spend the day at home ill, they are usually so involved in the project, the challenges, the technical problems that need solving that they still spend their time thinking about the project. This thinking time can still count to the project – after all, the job of developing software is mainly thinking not typing on a keyboard.
Conversely, the longer the absence the more the project fades from memory. Less thinking can be done to move the project on as the current challenge that was fresh in the mind will either fade or will already have been addressed in thought. No new challenges are going to arise without actually trying out the thoughts with new code.
So, in conclusion, please don’t try to make a simple maths formula tell you how to treat your software developers. They are usually highly intelligent, highly motivated and will be absolutely horrified and offended by the implied accusation that they were taking time off when they didn’t need to.