Effects of automated time tracking/monitoring

Question

Our company wants to set up an automated time tracking/monitoring system. It will monitor every software developers' workstation and make statistics about their computer usage:

• which program the developer use (based on the title of the applications),
• how much time in a day they use the keyboard and the mouse.

The goals are:

• replacing the old timesheet system,
• reducing time spent on online video streaming/social network sites (increasing work time),
• give feedback to the developers (and their managers) about their time spent on work/non-work activities.

They know that it's impossible to spend 8 hours a day in front of an Eclipse window so it's not an expectation and you can report non-computer time too. It will not have any impact on the developers' salary or their performance review it's rather for curiosity.

The developers can disable the monitoring (for privacy) but it won't count as work time (in the monitoring system).

Will it have any positive or negative effects on productivity, morale, motivation, etc? Would it change anything if only the developer sees the stats?

Answer 1

This is a perfect example of "sweat-shop" software development. The people considering implementing this system clearly have no understanding about the creative process that goes into developing quality software, and only see their developers as overpaid Internet surfers who are a burden on the company's bottom line.

They run the company, so they can do what they want to do. As a developer, the mere threat of implementing such an arcane tracking method would have me starting my job search before I got to the bottom of the email message announcing it. Unfortunately, that's not my biggest problem with this insipid methodology.

My biggest problem with it is what follows after they have "seen the light" and realize they've done nothing but piss off decent workers to the point where they either leave or allow their work to become substandard in order to keep their job. The company then has to replace the people who left during their bout of micromanagement. So, these new developers, riding on nothing but eagerness and good intentions, who did not contribute to the reasoning behind the shift now have to bear the burden of fixing the damage that was created by the shift. A minute to break...an hour to repair...

This is just laziness on the part of management and an unwillingness on their part to take the time to learn and understand how to properly run a software development project. If you don't trust your people, get rid of them...don't compound the stress they will already be experiencing by instituting ridiculous policies which not only damages employee morale, but also the resulting infrastructure of the company.

Answer 2

There's a "buzz phrase" at the moment that "you can't manage what you can't measure", which is usually used to suggest that you need to put metric in place in order to be able to drive business improvement.

Creating and monitoring metrics of any kind always carries the risk that over time, the metric (in this case time spent on-work activity) becomes more important than the main business goal (producing high quality working software in the shortest time possible.)

Each metric you add to your workload adds to the overhead you have in managing and supporting your team. A few excellent, direct metrics are usually better than a large number of indirect ones.

For a team to buy-in to a metric, they too have to understand how this is going to improve the main business goal of the team; if they can't - and you give them an opt out - I suspect they will use the opt-out. Especially when it comes to the non-computing side of the monitoring which sounds just as manual as a time sheet.

As the question stands, you haven't defined how the metric is going to improve your core activities. As a result, I think it will be very difficult to sell this to your team as a good idea.

Answer 3

Will it have any positive or negative effects on:

Productivity

I would expect a short term spike in productivity as most developers would do just a little more to make sure they do not look like they are one of the slackers. You will not be able to measure this productivity spike though because you do not have the metrics for the time before the monitoring. After the first week people will compare scores, and find out the penalties for being low/benefits of being high. Unless the penalties are severe or the benefit is significant, the productivity will quickly return to normal, potentially take a hit as some might think it is unfair they work so much harder than others, but they get over that quickly because basically people work the way they work. Diligent workers do not like being idle. Lazy workers do not like doing work. Net result productivity will probably stay the same unless you change personnel.

Morale

This screams we do not trust you and are looking for ways to punish you. Even if that is not the goal it is how it feels. This morale hit will be temporary as well. Real effects will eventually replace the expectation bias. But morale will be seriously impacted, especially with those people who are already distrustful of management. You could even lose a few good workers because they are the types of people who will go look for a new job when their job takes a turn. The lazy workers, on the other hand, will wait until you fire them and their unemployment is about to run out. Net result here is all negative.

Motivation

You will likely have a short term hit as people try to figure out how to game the system. You could have some minor gains here as extended breaks get cut short as people remember they are being monitored. But the motivation will be only to meet the minimum. If people can monitor their stats during the week you might see a small bump at the end of the week if someone has marginal stats through Thursday. But you would also have some de-motivational effect as when someone takes a lazy Monday as they feel like they have stuck themselves in a hole. If you hide the statistics during the week this effect is compounded. A few people will take motivation from trying to improve their stats. Most of them will try to do it by gaming the system rather than actually doing more work.

etc? (Other Things)

This program can start out benign. Eventually some pointy hair in the luxury suite they call an office sees the stats and decides he wants management to improve the numbers. It will not matter when the manager tries to explain that higher numbers are not indicative of higher quality or even more productivity; that the guy with the worst numbers provides some key knowledge and skills; that the designer that is seems to be browsing the web half of the day is actually out looking for new ideas and incorporating them into new products. No that pointy headed boss will demand you improve those numbers by 10% (or some other arbitrary number). And that improvements in these numbers should be part of the employees yearly goals and tied to raises and promotions. If it doesn't come from the top it will come from the manager that comes after you that has little experience managing developers, but sees these numbers as an area where that new manager can show improvement. And once those numbers are in place as key metrics, convincing management to abandon them will be all but impossible. Improve the accuracy sure... but not remove the metrics all together.

Would it change anything if only the developer sees the stats?

No because they are there. Eventually someone else will learn of these numbers, and lets face it most developers are at least minimally hackers. Someone is going to figure out how to get access to everyone's information. And upper management will find out about the existence of the numbers... see the paragraph above for consequences.

You have a solution here that you are looking for a problem to solve. If not then you think you have a solution to a problem you have. If that is the case then I suggest you ask the question of how can I solve problem X. I doubt this would be the solution any rational group came up with.

Answer 4

Will it have any positive or negative effects on productivity, morale, motivation, etc? Would it change anything if only the developer sees the stats?

As the other answers state, implementing what you state in the question as you state it in the question will have serious impacts on motivation and productivity as folks update their CVs and get out.

I tend to agree with all of those answers, and really think that this is a disaster waiting to happen, but I think that there's another question hiding in your question which is, "If my bosses are hell-bent on implementing this anyway, how can I minimize the harm?"

Disclaimer:

Not saying this won't cause any problems. I think it will as mentioned above. I just think that if they are going to do it anyway (because if the question is indicative of the attitudes of management, they won't care if it will kill motivation as they've already decided the use of facebook/youtube is more important), it is important to think about minimizing the harm caused.

The first, and most important thing is don't lie to the employees, all of the below suggestions are based on the assumption that they will be implemented in good faith by the management. Since this is incredibly sensitive and has the potential for a mass exodus from your company, I cannot state the importance of doing this in an honest and transparent way enough.

I would suggest the following steps to minimize (but not eliminate) the chilling effects that every other answer seems to cover pretty well.

1) Analysis, not Assumption

Your question contains two massive red flags that cause me serious pause:

[The goals of this program are:]

• reducing time spent on online video streaming/social network sites (increasing work time),
• give feedback to the developers (and their managers) about their time spent on work/non-work activities.

This screams, "Management have already decided that facebook and youtube kill productivity and are looking for metrics to figure out where to place blame." This is a very dangerous approach because the assumption on what makes developers productive is made before any analysis is done.

If you want to sell this to employees, you have to make sure that the bosses understand that they will just alienate productive employees if they assume what makes a productive office before even gathering, let alone analyzing data.

2) Step-by-Step Implementation

Any implementation should be done in steps. For instance, just start by looking at how often people use the keyboard/mouse. Analyze that data over 3 months, and see if it actually correlates with productivity. This reinforces the point in step 1), which is to say that the goal is not to lay blame, but rather to figure out how workers work (without judgment).

By implementing slowly, and piecemeal, this will give more ammo for you (or anyone on the side of the employees) to show why the analysis isn't showing what the management wants it to (that employees are untrustworthy and are wasting company resources on social media). Assuming it isn't showing that.

3) For a Limited Time Only

Be sure that the bosses clearly concede that this is:

1. For analysis, not assigning of blame
2. Limited in scope of implementation
3. A conclusion will be reached on date X and revisited then

Once the system gets created, there will be a huge incentive on the part of cost-conscious management to say, "We've already spent the money to implement it, we should keep it running forever!" The issue is that this will upset many employees. The management needs to be incredibly transparent and straightforward on what the scope and goal of the project is to minimize the negative effects.

It would be even better if management was really just trying to make it easier to do time tracking for the developers, and would only implement a system to track it group- or team-wise with no identifying information about any single person. I doubt there's any chance of that though (and if it isn't true, don't lie to the employees).

Answer 5

Activity monitoring comes from the world of manufacturing lines, where little creativity is involved and virtually none of it occurs away from the task. It is simply not applicable to creative tasks.

For any kind of "knowledge work", much of the actual development/research/synthesis goes on in the employee's head, and simply can not be tracked. At times I can do nothing visible for a week -- can even "play" for a week -- waiting for background processing to complete and then brain-dump a complete hundreds-of-lines solution in a single typing session. The correct measurement of this is average productivity since the offline work is not monitorable, sometimes not even by myself.

If folks demand that I show activity, or if I need to rush the process because it is blocking someone else, I can do so... but my product will be inferior, and I will be significantly dissatisfied. That may be acceptable if you have budgeted to come back and fix it later, but it is going to cost you more to get equivalent results.

There are valid uses for tracking some kinds of things -- repeated antipatterns, for example. But that's something you can let the developers do on their own and encourage them to voluntarily share, or that you can get from analysis of the codebase and changesets; it doesn't need or benefit from a general motion tracking framework.

The fact that a tool exists doesn't mean it's an appropriate one to use. If you don't see a better tool, that may mean you have mis-defined the problem.

ADDENDUM: There is one sort-of exception. If you're working on a contract where employee hours are directly billable to the customer, and the same employees are also doing other things, you may be forced to do account-specific time tracking. But for the reasons I've just mentioned this is AT BEST a statement of primary attention during a given time period, and that's presuming you can convince the employees that it's necessary to try to keep this accurate so your company can justify its income. When I had to deal with this I either set up separate accounts in the machine for the different assignments so I could use login/logout records, or rattled off a tiny script to leave timestamped notes for myself when I switched focus (also useful for producing summaries when manglement asked how things were going). Note that this is not trying to go anywhere near precise activity tracking, and that it costs virtually nothing, and that it respects the employee's honesty and judgement.

Answer 6

It's not done this way because there is no need, it just means a bunch of extra work and maintenance for the people who set it up etc,.

Any halfway decent admin can monitor usage from the firewall. Not as granular as capturing keystrokes, but just as useful to both satisfy curiosity and get a gauge on performance.

Answer 7

Interesting how so many people are really really against this idea of time tracking. They view it as a personal assault on their own livelihood, yet most everyone agrees it will lead to improved productivity. I believe this idea is a product that will come in the main market because of this. Personally I was really taken aback by the article because of the vigor of many of these well thought out complaints. I like that many of them used the word "morale" almost like the morale of a ship in war, which they seemed to view this idea as a battle.