Case: monitoring software developers

The software developers’ job is deemed untouchable for the user behavior monitoring. Allegedly, software developers are people with a creative turn of mind and therefore assessing their work efficiency by conventional methods is inadmissible. The real quality of their work is in their end product. The chief argument in favor of this approach, “you won’t understand here anything just the same,” gives software developers a status of the untouchable elite enabling them to do as they please. The guests of the KickIdler project blog is a customer who, not believing in the software developers’ special status, undertook their monitoring and analyzed the information, which brought him to amazing conclusions that efficient developers are ruined not by idleness but the context switchover effect, which reduces the productivity of some workmen on average by 20%.

Hi! I own a small company of software development to order. A year and half ago there were a little over 20 developers on our staff, but as the crisis worsened, the number of orders diminished, the “mean check” value fell, and we had to cut the developer staff to 11. We maintain a good rapport with those who quitted the company, involving them as freelancers with an hourly payment.

The staff reduction brought about just what I feared. The productivity of the development team fell. Of course, the fall was not proportional to the team reduction (not by half) but it was serious enough to prevent us from meeting the deadlines. Of course, the customers were displeased. We agreed with some but lost some others. The acute problem had to be immediately resolved. But we had no idea where to start. All our staff were proven and conscientious people, by far not lazy and not killing their working time, which was easy to check.

I supposed that somebody among the specialists was preparing for the crisis way too seriously by picking up freelance assignments and doing them during the working time. I decided to verify the hypothesis with the aid of the working time registration system (WTRS) which gathered information about which applications and sites the staff were using during the working day. The WTRS system discovered no deviations or violations. Judging by the reports, the programmers spent 85% of their working time in development applications, devoting on average 8% to non-work activities. It’s nothing serious to complain of.

It became clear that no logs of user behavior can diagnose the problems. It is necessary to somehow look into the staff’s computers. Of course, it’s impossible to stand behind the backs of all 11 programmers. Therefore it was decided to introduce KickIdler. I used the test version of the solution, and set it to recording video of the computer screens of my team.   

The video gave me food for thought. The software developers had really spent very much time in development applications. But their productive time was largely diluted by time in all sorts of social media and professional communities, from Habrahabr to GitHub. They switched over to those, read messages or posts, wrote answers or comments, and then got back to writing the code. However, this affected their operating spirit, and the developer took 15 to 20 minutes to come to, readjust himself, and regain the working rhythm.  And then he received a notice of a new message. He again switched over to the social media and everything started all over again.  

Among IT engineers this effect is known as the context switch-over. For the human brain (as for its electronic counterpart in the form of the central processor) this is one of the most effort-consuming processes in terms of time consumption and computing power. The context switch-over decreases the processor efficiency of the machines, diverts human attention and makes the brain grope for eons of time for a broken thread of constructive work. When there were more than 20 software developers, this effect was distributed among them and was less conspicuous. The problem cropped up when the number of software developers fell to 11 and the contribution of each became more evident. On average, the context switchover guzzled 20% of working time of each of my specialists. Considering the average wages in the development team ($25k per month), it terms of money this amounted to $5k per month for a single employee or nearly $100k  per month for a team of developers in general. And this without lost orders and received fines filed against us by a couple of displeased customers for failing the deadlines.

I had to take unpopular measures and ban the use of social media, messengers and other resources and applications not related to work, all through the working day except the official intervals. These measures quickly rectified the situation. In the first week the work productivity jumped 12%. But this was not the end! The growth continued. In another week, the signs of global improvement emerged as the team became more punctual in striving to achieve intermediate targets of the project.   

This experience made it possible to understand some essential things:

• If you can organize the monitoring of your employees over their computers, just do it.
• It makes no difference who to monitor. The monitoring will be useful both for software developers and sales managers.
• If the staff resist the monitoring, it means that they are aware of being inefficient are fear exposure.
• The standard working time accounting systems cannot reveal the problem. So it was in our case.

Hopefully, my story will be useful for readers of your mails

Do you want to know on which sites your staff are spending their working time? Take half an hour to install the KickIdler system and get not only the complete statistics of work with the sites and software but also an opportunity to peep into the monitor of one or several managers at a time.