Project: Tracking Time at Work

Cartoon astronaut, dressed for work drinks coffe and checks watch.
Image by catalyststuff on Freepik

We all have a subjective perception about how we approach work πŸ’Ό. We innately have a sense of a productive day vs. a non-productive day, a stressful day vs. a chill day, and so on an so forth. But how does our perception align with reality?

Over time, how good is our memory? Do we have more productive days than non-productive days over the course of a month? A quarter? A year? Do we evenly divide our time between stakeholders? How often are we interrupted during the day? Are some days worse than others? Why?

A lot has changed for me within my company in the last year. I felt this change, this uptick in my cadence, this increase in stress, this increased scattering of priorities, stakeholders, projects, and teams. And to get straight to the elephant in the room, I also had feelings about RTO (my company has recently increased to 3 days a week in the office 🏒). But I really started to wonder how closely my perception of what was happening aligned with reality.

But how should I check myself on this? What exactly could I measure that would capture how I do work?

I am not looking to measure how much I deliver, how many Jira tickets I work, how many code reviews I close, how much I produced during a time. While these are a type of measure of productivity, they are measuring productivity as a function of output. If output drops, this data doesn't tell you why.

I want data that helps answer why my output is what it is, or why I can/can't squeeze in one more task each day, or why I sometimes feel like I never got a moment to breath and yet I don't actually know what I did that day? I want data that tells me where my time is going.

🧠
If I know where my time is going, then I have levers I can pull on to catalyze change.

So naturally I started tracking my time.

Tracking time is not a perfect endeavor, nor one that can completely answer the above questions. In fact it's tedious, error prone, and dare I say... a waste of time πŸ˜‰.

But once the idea got in my head, I just had to do it. I was too curious to see what the data would show me πŸ”Ž.

πŸ§ͺ Methodology

For my time tracking project, I decided that my approach needed to meet some criteria.

  1. Flexible enough to track all types of work
  2. Fast to track so it minimally interrupts my flow
  3. Simple enough for me to remember and remain consistent in how I categorize work
  4. Open in terms of both extensibility and access to the raw data

🧰 tooling

Finding a time tracking tool that would let me stick to those guiding principles was a bit of a challenge, partially because I layered in the a fifth, silent 🫒, requirement that whatever tool I used needed to be something I could self-host.

But never fear, the self-hosted community is ever resourceful. And ultimately I settled on Traggo which is an open source, self-hostable, web-based time tracking application.

πŸ‘€
Ok, as I'm writing this I see there's an app there I hadn't seen before, TimeTagger. I might actually have to explore this as it seems more actively developed and possibly a spiritual successor to my current tool of choice you're about to read about.

Traggo keeps things simple, you start a timer, add some tags to it, then stop the timer. Traggo's tagging system allows it to remain flexible for adding new ways of categorizing work and the time data is stored in a SQLite database making the raw data open for consumption by a variety of different visualization and analysis tools. Traggo's UI also supports a basic auto-complete feature when you are typing in tags which means creating and tagging timers can be fast.

While Traggo comes with it's own dashboarding and visualization support, for the life of me I could not figure it out πŸ€·β€β™€. Regardless, I prefer to be consistent in the tools I use for certain types of problems and when it comes to visualization and analysis, Grafana is my tool of choice. Since Traggo stores the raw time data in a SQLite database it was easy enough to connect the database to my existing Grafana instance.

Traggo's approach to associating tags with time spans meant I needed to plan out what tags I would use to help categorize my time. Picking the right tags was important as it would impact my ability to slice and dice the data.

🏷️ tagging

In my opinion, any task I spend time on should be able to be described using the following sentence:

πŸ’¬
As a <role> I did <planned/unplanned> work on <project> for <stakeholder> at <location>

While this sentence structure has limitations in what it can measure, it does let me answer quite a few different types of questions. Such as:

  1. How much time do I spend in each of my roles? Is it balanced?
  2. How much time do I spend doing planned vs. unplanned work?
  3. Which projects ate up the most time?
  4. Which stakeholders do I dedicate the most time to?
  5. Which projects generated the most unplanned work?
  6. Which stakeholders generate the most unplanned work?
  7. Which projects span across multiple roles?
  8. How much work do I do outside of my role?

Traggo tags time using a key value pair tag:value, where tag is pre-defined and the value is open-ended. So in order to capture the data I'm interested in my tags ended up looking like this:

Tag Example Values Friendly Description
aor Architect, Discovery, Delivery Role or Area of Responsibility
t Planned, Unplanned The type of the work, planned vs. unplanned
p projectName, commute, lunch, code review The project or activity I worked on
s personName, teamName, me The stakeholder, who did the work benefit
l home, office, homeToOffice, officeToHome Current physical location
m true, false Was this a meeting?

For each of these tags I also allowed the values all or the inferred none when the tag is not specified. This let's me track when I do work that is either cross-cutting or not directly related to anything.

πŸ“ Applying the Methodology

Below are a few examples to help tie together what these tags actually look like as I enter them throughout the day.

Scenario Timer Tags
I work on a code review I had planned to work on that day for Mark at home. aor:architect t:planned p:PR s:mark l:home m:false
I get a question in slack from Jake about delivery for SuperCool project in the office. aor:delivery t:unplanned p:superCool s:jake l:office m:false
Lunch at Office aor:none t:none p:lunch s:none l:office m:false
Commute to/from Office aor:none t:none p:commute s:none l:homeToOffice/officeToHome m:false
I attend a stand up meeting related to product delivery for TeamA aor:delivery t:planned p:standup s:teamA l:home m:true

🀨 So show me the data already.

No.

At least, not in this post.😬

This is both a kickoff and a reference post for the project. It will be helpful to have this background and methodology already documented here to point back to when diving deeper into the nuances of the data.

βœ‹ But do not fear! The data is on its way!

So if you're interested in non-scientific, super niche data, analyzed by someone who has no idea what they're doing, then stick around.

πŸ‘©β€πŸš€
You can find all the posts in this series here.

Subscribe to Next Topic

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe