Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

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?

share|improve this question
It will not have any impact on the developers' salary or their performance review - then why do it at all? Curiosity sounds like an excuse. –  Oded Nov 29 '12 at 20:58
Ask yourself - how would I feel if my workplace decided to suddenly track every little think I do on my computer. They say they are just curious and that this will not affect my salary or performance review. Would you feel a negative effect on your productivity, morale, motivation etc? –  Oded Nov 29 '12 at 21:00
Wow. I would not want to work for that enterprise as a software engineer or as a software development manager. –  David Segonds Nov 29 '12 at 21:20
On a related note, I have personally tracked my own computer usage at work using a tool called "manic time". It is very interesting and I think it has helped with understanding my own productivity. There are definitely clear patterns which appear in the usage that strongly correlate with my own assessments of productivity and flow. However, it would be horrifically unacceptable to me if anyone other than myself looked at this data. –  Angelo Nov 30 '12 at 0:42
It's impossible to predict the effect on productivity without more information on the company's recruitment plans following the departure of all the current developers. –  Carson63000 Nov 30 '12 at 1:50
show 4 more comments

5 Answers

up vote 32 down vote accepted

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.

share|improve this answer
Nailed it with this answer. I'd quit my software development job in a heart beat if I couldn't take some time to get out of inside eclipse and a terminal. Is this job really worth that kind of micro management? –  Jeff Nov 29 '12 at 23:44
As a postscript, before anyone who reads this mistakes me for one of the "overpaid Internet surfers" I referenced, I have been a desktop software developer and architect since 1984. No mainframe experience...just desktop computing. I returned to college in 2002, earned a Bachelors in e-Business in 2005, and a Marketing MBA in 2007. So, I understand the dynamics of this decision not just from the developer's perspective, but also the management perspective. In-house software development is an investment. This idea will guarantee cost overruns. –  Neil T. Nov 30 '12 at 7:04
@Chad - A well run shop monitors dev performance by looking at results. The shop in question must have really poor management if it needs to compute a Facebook/Eclipse ratio to figure out which devs have acceptable levels of productivity. And of course the best devs would probably hack the tool to show 200% of there time is spent on Eclipse while really they are Skyping their friends looking for their next gig. –  Jim In Texas Nov 30 '12 at 17:18
Sorry, @JimInTexas, this is not a way to figure out why. Software development requires a qualitative tracking method, not a quantitative one. Typing more doesn't guarantee that the system will work better. Set up communication exchanges with the project sponsors to discuss the project scope, break the project down into its component tasks, determine the amount of time it will take to complete each task, and use that as a guideline to determine whether or not the project will be delivered on time and within the budgetary constraints. –  Neil T. Nov 30 '12 at 18:59
@Neil - I'm in violent agreement! When I say "looking at results" I mean precisely using Agile methods to plan and execute software development projects. Measuring the Eclipse/Facebook ratio in no way contributes to "break the project down into its component tasks ... use that as a guideline". In an Agile environment we compare estimates to actual performance to quantitatively measure productivity. If you use Scrums correctly the whole team will know who is spending too much time on Facebook in any case. I think you are addressing Chad, not me. –  Jim In Texas Nov 30 '12 at 20:47
show 4 more comments

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.

share|improve this answer
'My early metrics book... most quoted line is its first sentence: "You can't control what you can't measure." This line contains a real truth, but I've become increasingly uncomfortable with my use of it. Implicit in the quote (and indeed in the book's title) is that control is an important aspect, maybe the most important, of any software project. But it isn't...' (Tom DeMarco) –  gnat Nov 30 '12 at 9:35
"...do I still believe that metrics are a must for any successful software development effort? ...no" - yet another quote from the author of buzz phrase you refer :) –  gnat Nov 30 '12 at 9:36
@Gnat - I'd just heard people spout this out as a mantra recently - interesting how "control" has become "manage" in my neck of the woods. Either way I tend to spend a lot more time worrying about the sales pipeline than how many hours the developers spend actually at their computers (as opposed to problem solving over a game of pool); some are in at six am, some leave at eight pm, they are all there for the standup, stories are getting knocked off at a cracking pace and they are all happy. They have it under control (so I don't have to...) –  GuyM Nov 30 '12 at 10:05
just feed the article I referred to these mantra spouters and explain that mantra author officially "denigrated" it since mid 2009 :) –  gnat Nov 30 '12 at 10:13
add comment

Will it have any positive or negative effects on:


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.


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.


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.

share|improve this answer
+1 for "a solution in search of a problem" - I would suggest there are better and more practical methods for managing each of the stated goals that would cost less (in terms of time and employee relations) and contibute more towards genuine business improvement. –  GuyM Nov 30 '12 at 22:26
RE productivity spike: it's pretty much the Hawthorne Effect which you can expect from most changes that result in increased scruitiny –  Rarity Nov 30 '12 at 22:31
@Rarity - Thanks added that link in the answer. –  Chad Nov 30 '12 at 22:41
"morale will be seriously impacted" generally my experience was exactly that, but every rule has exceptions. In one of my past jobs, permanent time tracking did not have that impact. Have to note that in that "exceptional" company, 1) everything was clearly, strongly and unambigously targeted to serve programmers and 2) time tracker tool was extremely inobtrusive and convenient to use. Don't know which of these two things was more important; I guess both. I for one have been using that tool to track overtime and keep my weekly time spent below a sane level. :) –  gnat Dec 3 '12 at 7:44
add comment

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?"


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).

share|improve this answer
add comment

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.

share|improve this answer
Welcome to The Workplace. If you have reason to believe this is a good idea or that it will improve productivity please explain why you believe this is true. We requires all answers here to be complete and stand alone answers. Please edit your answer and explain why you believe that this is an effective solution for the questioner's problems. –  Chad Dec 3 '12 at 14:36
Increased productivity does not guarantee quality. I did like your battle analogy, however. When it comes right down to it, there are two forces battling against each other: one wants to receive the highest pay possible for their efforts, and the other wants to give the lowest pay possible to get the job done. If we were talking about a job where thinking is not required, this method would be very suitable. Because we're talking about software development, it is clearly not. –  Neil T. Dec 4 '12 at 18:57
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.