Tag Archives: knowledge loss

I love my job

The Cost Of Replacing Staff

Development, , ,

An article in The Telegraph earlier this year caught my eye. I’ve mentioned once or twice that staff turnover, and the resulting knowledge loss, can be costly. The article in The Telegraph provides some numbers which are really quite startling:

The average fee for replacing a departing staff member is £30,614, says Oxford Economics and income protection providers Unum. This figure comprises two typical amounts – £5,433 for logistics, such as agency fees and advertising, and wages during the time when a new employee is yet to reach optimum productivity level, believed to be an average of 28 weeks at a cost of £25,182.

And specifically for IT:

IT and other technology is most affected by high staff turnover. The overall sector figure is approximately £1.9bn per year. Workers take more than seven months to reach their peak, at a cost of £31,808.

With most probationary periods lasting three to six months, this means on average a developer will reach the end of probation before reaching optimum productivity. Consider also that the average salary for a software developer in the UK is £30,000. This means the average cost of replacing a developer is higher than the cost of paying that developer’s salary for a whole year. Over the course of a year, losing one staff member a month would incur a staggering £367,368, or £381,696 in the case of losing one developer a month. Depending on the size of the company, this can be an unassumable expenditure.

According to Forbes, employees changing jobs can expect a salary increase of between 10 and 20%. Retaining the 12 departing employees, then, would cost between £36,000 and £72,000. It’s still a lot of money, but it’s only a fraction of the cost of replacing them. With such a large divide, it also allows the company to address other issues to aid in staff retention – employee benefits, training, work environment, morale, and so forth.

Photo by cobalt123 via flickr.

Listen

The Importance Of… Listening To Developers

Development, , , , , ,

Everyone’s heard that you should listen to your users, right? After all, if you don’t, you risk alienating and losing them. My particular favourite take on this is Jeff Atwood’s, of Coding Horror, Stack Overflow, and now Discourse fame (and if you don’t know who Jeff Atwood is, where have you been?). He wrote a blog post called Listen to Your Community, But Don’t Let Them Tell You What to Do. You can see this way of thinking in a lot of successful websites and applications – if Facebook didn’t follow this path, it would have died years ago after reverting every change users complained about. In a way, this also applies to software products where customers pay for developments – by all means allow this, but don’t let that affect your roadmap or you will end up without a product.

Somewhat less popular, but still going strong (and perhaps growing stronger with the appearance of shows like Undercover Boss), is the idea that you should listen to your employees. An interesting take on this can be found in an article by Matt Linderman (of 37Signals/Basecamp) called Marketing to your own team:

You’re not just sending out a message externally, you’re sending one out internally too. If your employees don’t believe it, the whole plan falls apart.

It’s not good enough to just have meetings where employees talk to you – it’s all just platitudes if you’re not engaging in a conversation. Listen to your employees, market to your employees, or they will lose interest.

Of course, this is just one of the reasons you should listen to your developers. From a technical perspective, and in the absence of empirical data (such as usability studies), developers should be your first port of call when it comes to figuring out how to develop your product – they know your product inside out, to at least some degree they are invested in it, and they have an interest in what you’re doing (at least, I find web application developers have a general interest in the web). If they didn’t they wouldn’t be there. Their knowledge and their input is valuable, whether it’s suggesting improvements to customer requests, or strategic direction, because they understand the expectations of software products.

Ignoring developers’ input risks alienating them. It can demonstrate a lack of trust, and a removal of responsibility. And employees who feel alienated, or without responsibility, will soon leave. High staff turnover will in turn lead to other problems. Knowledge loss, leading to difficulties in maintaining and developing the products, is perhaps the most obvious. In the highly interconnected development community, it can also make recruitment difficult, which will make any recovery harder to achieve. And if the turnover cycle is short enough, you will end up unable to promote internally. For example, junior roles tend to last 2 or 3 years, and mid-level roles anything from 3 to 5 years. This means senior roles are generally available only after 5 to 8 years. If you’re losing developers after just 2 or 3 years, the knowledge loss will be severe, you’ll be spending a lot of time on training which you don’t get to see a return on, and you’d better hope the code is very well documented.

Photo by Ky via flickr.