New time logging initiative at work place

Question

Management announced that starting on specific day all developers (small team) have to log all work time, including non-project work: meeting time, standup chats, walks outside (during non-lunch time), writing long emails, creating new defects, phone conversations, etc. Most developers are salaried employees. The justification for this initiative is to plan work capacity better. This company merged with another one recently.

Currently time is logged for all project work only.

1. Would you be concerned about this announcement if you were a salaried employee working for this company?
2. Have you had a similar announcement at your work place before? Can you provide details about the outcome of such initiative?

Answer 1

I've gone through this in two different companies.

Would you be concerned about this announcement if you were a salaried employee working for this company?

I don't think I was concerned either time. The first time I felt more offended than anything - if project time is logged, and you are being productive, then what does it matter what else you are doing.

The second time I tried to fight it by citing my experience from the aftermath of the first time - which leads me to answer your second question:

Can you provide details about the outcome of such initiative?

At both organisations, before the imposition of "log everything", people were working more than the mandatory 7.5 hours - typically adding anywhere from half an hour to two hours each day. After the new rules were announced, you saw a lot more people dashing for the door at 5pm - and it started taking longer to get things done.

However, the other thing I've learnt is - you can't fight this kind of decision. The best you can do is put up with it, and start to figure out if you still enjoy the working environment.

Answer 2

I received a similar request from a previous employer, with the same motivation, word by word.

After a few weeks I noticed I was the only one compiling this logging, and it tingled my nose, but I kept doing it.

Then I came to know that the CEO and my manager where fighting between them: the CEO wanted to let me go and was looking for a good sounding excuse to do it (I was hired under taxation benefits which were then moved to a different category), while my manager was defending my position, as I was doing necessary work. The CEO even forwarded me a mail chain where he forgot to remove himself mentioning, below one of my weekly logging, "I could do this work in 15 minutes".

Long story short, I was let go shortly after.

Summing up: if a company is really concerned about your productivity should not ask you to fulfill unproductive tasks such as noting down how long you walk each day. I may be biased, but I see a huge red flag here.

Answer 3

1. Doing this two times and starting third time in new company the only concern is the tool used to log the time. Choosing the right one is a task onto itself. I had the unpleasantness using program where time consumed by the program itself clocked around one hour (it was badly optimized, web based program).

2. Usually (from own experience an other people talking about such) extracting useful data from gathered logs is easy but creating useful conclusion is not. What people see is that i.e. people only spend 45% time coding/programing. Then they push people to spend 60% of time coding overlooking the fact that the remaining 55% is used for research/compiling/testing/troubleshooting etc. As @HorusKol noted, people spend less time doing "free" overtime. In my country, for the overtime to be really clocked in, you need to spend whole hour extra OR be called for even 5 minutes after you clocked out (for example to log using VPN). So people didn't see the benefit of finishing the task spending extra 30 minutes at work. That accumulated 30 minutes a day for a week multiplied by 10 programmers gave a nice 25 hours of work done that the company didn't had to pay for.

conclusion - The change will depend on period during time will be measured and if they will want to discuss their thoughts with you. If they want to have some conclusions after a month and present ready solutions then you're facing with micro-management and it's time to dust off the CV.

Answer 4

This has been tried at my place, though at much smaller level ( i.e. project level) rather that organization level. One of the reasons for doing this was to see how much the programmers are distracted during the day, or how much time they actually spend in coding in the day. The only thing which came out of it was something akin to no meeting day or quite time (around 2-4 hours in the day) when developers cannot be pulled into any meetings or distractions and hence can get more done. I don't think we ever got to measure that. There is some merit in the idea, however, its very hard to measure its effectiveness. It does give you peace of mind if you are a developer, but no one really followed this religiously.You can say no to a few people, but when crisis comes, most of these boundaries are just ignored.

How they plan to use it at your place is hard to say, since your company has recently been merged as well. My suggestion is to talk to your managers and see what they want to do with the data.

Answer 5

I've been through similar twice before.

The first was when working at a web development shop there was a team (which I was on) that was supposed to be dedicated 100% to a large client. The client (not entirely without grounds) believed that the company still had us working on other clients' projects during time they were paying for and asked us to record what we were working on - to the minute! The outcome was that my boss just asked us to fill it out and "make it sound plausible" for the times when we were being double billed. Suffice it to say I left not long after that.

The second was actually at a recent contract position - head office was located on the other side of the world and they asked for it for the entire dev team (contract and perm). The given rationale was that they were trying to better understand what projects and clients were profitable. We didn't have to be exact and no-one ever queried the allocated time nor was anyone ever disciplined or otherwise disadvantaged for "taking too long" or similar.

Personally if it's happening to all I wouldn't be worried about it - vaguely irritated at doing something which invariably wastes more time than it saves but not worried. The given rationale sounds plausible given the recent merger.

Answer 6

I have worked at a place that did this. They made all the developers take a class. The idea was to be able to better bid programmers time by knowing how much time was spent in the different work phases. Then if they could also estimate all the programming parts of the project down to complexity and percent reuse, they could better turn that estimate of programing time into man hours.

It was an utter failure. Reuse was hard to predict. The fear of having to label all periods of goofing off during the day made everybody fudge the numbers. We were willing to say we spent an hour in a mandatory meeting unrelated to the task, but we wouldn't tell them about the hour we spent talking about how we spent the holidays. We just assigned that wasted hour to several task related categories.

The only other time I ran into this they wanted all time broken up into these little tasks, but they had no idea about complexity. They were looking for a way to identify the least valuable member of the team. But how do you do that from these numbers. If you spend 4 hours debugging a high priority bug, then the time was deemed valuable. But how do you compare it to somebody who had to spend 4 hours in tweak, compile, re-tweak re-compile cycle becasue the tools were so outdated there was no other way to make small changes to the GUI.

If I had to do this again I would get nervous. Nothing good comes from this type of documenting.