How would I log that?

In my quest to do my best work at all times here at the company, there have been many times when I did something that in my judgment needed to be done — but then afterwards I struggled to determine what the proper way would be to log that time.

I have found recently that I am not alone in this struggle. One group of developers that has particular struggles with this issue is that of the leaders, the top performers. Could it be that as an organization we’re unwittingly adding unnecessary friction to the day-to-day work of many whose work and leadership we most need to support?

I think so. Allow me to explain…

An Example

Suppose I spend a couple of hours talking with a co-worker about why it seems to me that flexibility is a necessary ingredient for developer productivity, the extent of the problem here, and specific answers we might offer if our opinions were sought in beginning to correct the problem.

It’s hard to see how this has anything directly to do with the security enhancement task I’m currently working on. So poppeth the perennial question: “How would I log that time?”

Exploring Alternatives

Five different approaches come to mind:

  1. Log it to the task at hand
  2. Log it as “Administrative” time
  3. Log a separate task
  4. Do it on your own time
  5. Don’t do it (at least not now)

Let’s look at each of these in turn…

1. Log it to the task at hand.


  • These sorts of activities are necessary day-to-day “sprinklings” — through them, I keep on top of my craft, which is important for the company to remain competitive long-term.
  • In the end I tend to work more efficiently on the task at hand when I also explore other longer-term thinking and doing that comes up along the way, so there may not be a time hit, especially on larger projects.


  • It may appear sneaky or dishonest to log to a task time not spent strictly on that exact task.
  • It may appear that the developer is hiding inappropriate behavior or getting away with something dishonorable.
  • It might even be sneaky, dishonest, inappropriate, and dishonorable!

2. Log it as “Administrative” time.


Looking through the tasks assigned to me, I don’t see any that involve this issue. (I proceeded to discuss it, not because it was part of a task assigned to me, but because the idea came up and, on my own initiative, I identified that it seemed an important topic to discuss.)


None of alternative 1’s worries about dishonorableness.


  • If I don’t miss my guess, administrative time is seen as unproductive time, maybe sort of as necessary waste — in that sense, it seems misleading to log these things as administrative time
  • We’ve been directed to limit the administrative time we log to basically at most one hour beyond our weekly team meeting, and that’s not enough flexibility to cover the sprinklings (such as the one we’re discussing) that might happen in a given week.

3. Log a separate task.


If logging to the current task doesn’t seem quite right, and logging an administrative timesheet isn’t quite right, why not log a task for the exact issue we’re exploring?


  • Doesn’t suffer the drawbacks of either alternatives 1 or 2.
  • Allows tracking time at a finer-grained precision (if you really can separate “sprinklings” from “purely” working on a task, which I’m not certain of).


  • In its current form, our Product Development Methodology (PDM) doesn’t support working on tasks outside of the official approval process. Rather, part of its map to increased productivity involves ensuring that developers are not working on other things (to be fair, it is counterintuitive that this would be a problem, isn’t it?)
  • It seems most likely that the visibility gained by logging separate tasks for these things would lead to a denial of permission to work on them. Some way would need to be found to build the developers’ trust so that they could be confident that logging time at this more detailed level would not be rewarded by the loss of freedom to do what, in their judgment, they need to be doing.
  • Logging tasks can take the focus away from the issue being worked on, breaking the flow and causing a hit to efficiency. (This could be mitigated by requesting only a bare-bones task with some form of description of the activity, rather than the fuller documentation required when a task might be worked by a different person.)

4. Do it on your own time.


It might be stated like this: “These sprinklings you’re talking about don’t sound bad, but they don’t seem to pertain to any initiatives you’re slated to be involved in right now. I don’t mind that you’re interested in this, but I can’t allow you to use time during work at this point (we’re so far behind already – how could I justify it to those I’m responsible to?) If these things are that important to you, maybe you can do them over lunch, or evenings or weekends.”


Avoids the moral qualms of #1, the negative perception fostered by and misleading qualities of #2, and the current unrealisticness of #3.


  • If these things really are important for the company, how can the company ask for additional personal sacrifice on the part of developers who take the initiative to pursue them?
  • For developers who believe that flexibility to do these things is important to the company’s remaining competitive (though they may not have been able to articulate that in so many words), this is another way that “we don’t trust your judgment” is communicated.

5. Don’t do it (at least not now).


“This is just not a direction the company is going right now. Perhaps next quarter there will be a chance for some of this; or write up the idea and put it in the queue of the team that’s responsible for this type of thing.”


  • For a particular idea, maybe someone else is already pursuing it. There’s no reason to duplicate work — it could be worthwhile to check that.
  • By not doing it now, we avoid the moral qualms of #1, the negative perception fostered by and misleading qualities of #2, the current unrealisticness of #3, and the additional personal sacrifice of #4.


Admittedly there is give and take. No one gets everything they want all the time. But when there is a pattern of denial of flexibility/permission/trust, we see some of these effects:

  • Developers feel that they are powerless to effect the good they see they could do.
  • Developers who try to exercise initiative may begin to feel that there are barricades on all sides.
  • The discouragement bred by the systemic inflexibility results in much lower productivity (even though the strictures are in place in the name of increased productivity!)
  • Many top performers may feel that to remain top performers they must get free of the shackles, and so leave the company.
  • Those that remain are in danger of losing their edge, because there is so much overhead involved in getting permission to do each thing that allows them to stay sharp that it’s just easier to lose the passion and downshift into a new gear: just try to cope, survive, get by.


Whatever alternative we choose, we must not squelch the spirits of those who are working hardest to make our company great. The stakes are high!

Updated 2/13/2008 – Revised the introduction and added conclusion


4 thoughts on “How would I log that?

  1. I tend to go for option 1. Most of my sprinklings happen when I’m waiting for things to finish/happen. So, while I’m working on something else. I think all of the drawbacks of options 2-5 outweigh the drawbacks of 1.

  2. Daniel, I would agree that option 1 should be the only task you are concerned with logging time too. Logging your time should be toward the task at hand for the week. As long as you deliver the expected results for the task that you have been assigned, there really is no need to log time toward the other minutia. The current leaderships vision was to alleviate the pain associated with time tracking. The additional time that you spend during the week developing relationships and thinking of ways to improve the organization is valuable as well and should not be diminished by a concern over where to track that time.

  3. I would like to think that option 1 is always accepted, but I sometimes get criticized for it. At that point, I usually get discouraged or angry and choose option 5. I realize intellectually that my emotions get in the way, but I am human.

  4. Some of the feedback here hinges on a question of what “logging time to a task” means. If a task is created and has a particular time estimate and due date that is deemed acceptable, then completion of the task by the due date should be a milestone of good work (whether time was spent on conversations, sprinklings, or whatever).

    However, that has not always been the agreed upon definition of “logging time”, but perhaps it is gaining more ground now. The other necessity is ensuring that the task is, in fact, completed on time. This doesn’t mean simply that you only logged 40 hours to a 40 hour task, but also that it was completed by the due date. If a task should be finished by next Friday, and you have logged 10 hours to it by Friday and are 1/4 finished, you should not be rewarded. Conversely, if you have logged 80 hours and have done a perfect job, then also there is room for improvement (ie: you shouldn’t be working overtime so much; work/life balance; etc).

    Of course, it is important that deadlines are set and met regularly, otherwise there can be big problems. Other development methodologies suggest monitoring completion time and graphing this against the remaining tasks and thus having a more granular view (they would eschew tasks over 40-80 hours, and some favor even shorter tasks). This can really help because if you have 10 40-hour tasks and you have finished 4 of them in 200 hours, you will probably need some extra time. And, in reality, people are pretty bad at estimating and ranking things, so this shouldn’t be a surprise.

    As an aside, the anchoring effect is a particularly interesting principle of psychology that is helpful in understanding time estimates. I learned of this (although it is somewhat intuitive) by reading an article in Wired about the Netflix challenge which is a small example of how being well-read can help with numerous issues.

    You can deal with issues such as this by monitoring and tracking progress. However, denying them and suggesting that estimates should always be super-accurate is just denying reality. Further, as we all know, estimates can only be based on what we know, and almost every software task involves solving unknown problems. This is typically what motivates a Knowledge Worker.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s