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?

  • 21
    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
    Commented Nov 29, 2012 at 20:58
  • 10
    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
    Commented Nov 29, 2012 at 21:00
  • 5
    Wow. I would not want to work for that enterprise as a software engineer or as a software development manager. Commented Nov 29, 2012 at 21:20
  • 5
    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
    Commented Nov 30, 2012 at 0:42
  • 12
    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. Commented Nov 30, 2012 at 1:50

7 Answers 7


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.

  • 3
    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
    Commented Nov 29, 2012 at 23:44
  • 3
    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.
    Commented Nov 30, 2012 at 7:04
  • 10
    @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. Commented Nov 30, 2012 at 17:18
  • 6
    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.
    Commented Nov 30, 2012 at 18:59
  • 5
    @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. Commented Nov 30, 2012 at 20:47

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.

  • 9
    '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
    Commented Nov 30, 2012 at 9:35
  • 5
    "...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
    Commented Nov 30, 2012 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
    Commented Nov 30, 2012 at 10:05
  • 1
    just feed the article I referred to these mantra spouters and explain that mantra author officially "denigrated" it since mid 2009 :)
    – gnat
    Commented Nov 30, 2012 at 10:13

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.

  • 3
    +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
    Commented Nov 30, 2012 at 22:26
  • 1
    RE productivity spike: it's pretty much the Hawthorne Effect which you can expect from most changes that result in increased scruitiny
    – Rarity
    Commented Nov 30, 2012 at 22:31
  • 1
    "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
    Commented Dec 3, 2012 at 7:44
  • "convincing management to abandon them will be all but impossible" -> Does it not have to be "will be all but possible"? As is, it reads to me, a non-native speaker, that it will be everything, except for being impossible; in other words: Convincing them is possible.
    – phresnel
    Commented Nov 4, 2014 at 13:50
  • @phresnel - Yeah its an american cliche... It is possible but not very likely and that is what the saying means. It is not impossible but it might as well be because once management has made its decision and decided to stand its ground the reality of the situation is that they are not going to change their mind barring some unforeseen event that shows them the error of their ways. Commented Nov 4, 2014 at 15:08

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


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.


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.


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.

  • 5
    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. Commented Dec 3, 2012 at 14:36
  • 4
    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.
    Commented Dec 4, 2012 at 18:57
  • 1
    Just like labor needs a wealthy body, without hardenings in the muscles or other aches, and with functioning tendons etc., a brain job requires a clear mind. You can do a brain job with your body torn apart, and you can do [a lot of] labor with an unclean mind (just remember construction men talking during work), but, I repeat myself, for clean mind work your mind need be clean. And this morale of having clean, trustful air is a lot like the morale on a ship (funny thing being that I actually served on a german frigate).
    – phresnel
    Commented Nov 4, 2014 at 13:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .