I Hate Time Tracking

I want to share something with you today: although I’m a Project Manager, I despise tracking time and keeping worklogs. Each day at the office is usually divided into numerous smaller activities with frequent context changes. Despite my utmost desire to map out the workday ahead of me, I can’t fully commit myself to that task because, by definition, Project Managers have to dispatch problems as fast as it is humanly possible.

On the other hand, I completely understand the reasoning behind tracking time and the value that proper worklogs can have for any given organization, and this post will delve into both of these issues. Hold on to your seats, this is going to get pretty wild.

A Handful of My Experiences

The majority of my professional life was spent unbound by the vagaries of time tracking and work logs. That particular state of affairs was justified by a number of different factors:

  • the specific character of my work: back then I worked in game development and often times I didn’t have one single position, I did everything from game design to project management and sales,
  • lack of advanced tools: proper software wasn’t available or it constituted a significant overhead,
  • inconsistent revenue streams: about 95% of all my projects were billed with flat fee billing which removed the necessity of having detailed worklogs.

That approach worked to a lesser or greater degree, however, it was decidedly inefficient and unproductive in the long run.

How did I start tracking time? Well, I cooked up an Excel spreadsheet and used it to write down tasks I accomplished on a given workday and assigned them to different projects I was involved in. I usually sat down to fill out the spreadsheets in the evenings and that made all the difference in the world: it turns out it’s very hard to remember exactly what I did during the day and how long each task took. Busy days were especially hard in that regard.

Then I started using JIRA and everything changed. At first, each project I handled contained a separate task entitled “Project Management” that I used to track time. Whenever I was finished with something, I used that task to log the time I spent on it.

This approach yielded the following:

  • I had more detailed worklogs,
  • time tracking became much more labor-intensive,
  • I had a better idea of where my time went,
  • unfortunately, a lot of my time still went unaccounted for and my evening logging sessions were still necessary to construct a clear worklog

Shortly thereafter I started to track time using timers in Harvest and I realized fairly quickly that this method was much, much better than the previous one. Harvest allows you to create individual, separate timers and switching between them requires minimal effort. After I finished work for the day, I only had to add short descriptions to tasks I managed to capture using timers.

Switching to Harvest had the following results:

  • my worklogs were more accurate than ever,
  • tracking time became less labor-intensive,
  • I could finally determine how much time any given task has taken me,
  • the efficiency of my work increased significantly.

That’s where I am today.

Improving Your Time Tracking Practices

After years of trial and error, I decided that I acquired enough experience in the matter to put together a few pieces of advice that could help you refine your own methods of dealing with logging time:

1. Replace current tools with better ones.

If you are a developer, your workday is not just about writing code. You are part of a team that produces software, you take active part in product maintenance as well as the planning and management of the entire group’s workload.

Do that as fast and as effectively as possible so that you have lots of time for what you love most: writing code. Applying that approach is not only in your best interest, but also in the best interest of your PM, your employer, and the client.

2. Track time using a timer instead of logging after the fact.

It’s a qualitative leap with regards to both accuracy of the process and the amount of time it consumes. Trust me, there is nothing worse than sitting down at the end of a workday or even a workweek and trying to figure out what we spent our time on.

I know what you’re thinking: “But I can check my commits, completed tasks on JIRA, my e-mails…” But should you? Best case scenario, trying to comb through all of that will cost you lots of time and frayed nerves. Additionally, there’s stuff you won’t be able to quantify this way, e.g. the time you spent on writing a post for the company blog.

3. Attribute worklogs to specific tasks.

Only then will your work and your worklog be fully transparent for the entire team, for you PM, and for the client. If you’re working on something that’s not related to any existing ticket, create one for yourself.

Creating an internal project for tasks like blog posts, blitztalks or preparing estimates of future projects is actually a pretty good idea. This will allow you to track all of your time within one framework or system, thus making it visible to all interested parties.

The Value of Tracking Your Time

I’d like to share with you a few observations about the benefits you can reap from diligent time logging efforts. For clarity, I will use separate sections for each type of employee you may find at a software development shop.

Developer: for you, the value lies primarily in your own worklogs and the logs kept by your teammates.

Having detailed worklogs will:

  • help you manage your time in a more efficient and consistent fashion,
  • make it easier for you to spot whether you’ve exceeded the estimates,
  • help you increase the efficiency of your work by giving you a timer to work with (e.g. the widely known Pomodoro),
  • enable you to estimate tasks more accurately — this is also where the worklogs of your teammates will come in handy.

Project Manager: for you, the value lies in the worklogs kept by developers as well as your own.

Analyzing the worklogs of developers will:

  • let you be more efficient in planning your team’s assignments,
  • improve your communication with the client,
  • make the development process more transparent to all interested parties,
  • allow you to detect incoming problems or resource shortages in a more timely manner.

The everyday workloads of a project manager and a developer are very different; however, logging time may be beneficial for both. The average workday of a project manager is very, very fragmented, you’re running a few projects simultaneously and handling each client usually requires a different amount of time.

Your own worklogs will:

  • allow you to manage your time in a more efficient manner, and that’s priceless when you’re running multiple projects simultaneously,
  • enable you to detect activities that need optimization because they take up too much time relative to the profit they bring in.

Executive: most of the time you’re not keeping any worklogs of your own, so for you, the value lies primarily in the logs kept by others in the company.

Perusing the worklogs of your employees will:

  • allow you to quickly check whether everything is on the right track, right here and now,
  • enable you to easily estimate the profits the development team generated in a given period,
  • allow you to assess how much time do your employees spent on tasks others than the ones directly generating profits, e.g. writing for the company blog, preparing blitztalks, or organizing events (like our Swift Warsaw) and whether these activities will pay themselves off in the long run,
  • enable you to generate useful reports and estimates.

Dos and Don’ts

So, if we’re up to speed on the what we can do to improve your time tracking experience, maybe we should now focus on what we should avoid in our daily tracking practice:

  • only log time when it’s of some value to you or others,
  • don’t log your time when no one is expecting you to do so, when it does nothing to improve your everyday work life, or when it is not necessary for billing purposes,
  • most of the time, attributing a tracked period of time to a particular task (e.g. using a link or the ticket number) is enough as far as logging goes,
  • if you’re adding description to worklogs, do it in a way that allows everyone to make use of those logs in the future,
  • label your tasks properly, the fact that you worked for 6h on “some stuff” brings absolutely nothing into the mix,
  • try to use separate timers/tasks for recurring activities (e.g. calls with clients), only then will you be able to precisely determine how much time they took. Don’t chuck all such tasks into one basket,
  • group smaller activities so that you’re not overwhelmed with the sheer number of timers/tasks,
  • try to employ tracking tools that you will enjoy using, doing so will ameliorate the majority of problems related to time tracking,
  • avoid logging your work after the fact, it’s always more time-consuming and frustrating than it has any right to be.

In Conclusion

Tracking time has lots of merit if you do it wisely. Proper approach to the matter transforms it from a chore into a normal element of your everyday efforts and brings a lot of value to your company. However, if logging time makes you miserable, discuss the issue with your team and establish whether tracking time is worth the effort in the long run.

…meanwhile, deep inside the Macoscope offices, a secret team of developers is hard at work to devise an application that will integrate project management software with Harvest, thus allowing users to use multiple instances of JIRA without producing superfluous worklogs.

A Developer’s Primer on Being a CEO (Lessons Learned, Part Two)
A Developer’s Primer on Being a CEO (Lessons Learned)