Tracking Time at Work: Time spent per Task
With all those meetings, all those pesky Slack messages, all those impromptu flyby questions, have you ever wondered how much time you actually get to do uninterrupted, focused work?
In fact, this was one of the questions that kicked off this entire time tracking journey for me.
My biased opinion is that my company, in it's current operating model, is particularly bad about interruptions and context switching. And while I can't measure this in relation to any other company, I can at least quantify the amount it's happening to me.
So mute your Slack ๐, close Discord ๐ฎ, and ignore those pesky emails โ๏ธ for a second while we dive into the data.....
What exactly are you measuring?
Since I track my time for every task I work on, I should be able to look at the average length per task to understand how long I typically work on one thing before switching to something else.
A switch like this may or may not be planned.
For example, if I only had 15min between meetings to get something done, then the task switching is planned and expected after 15min.
Alternatively, if I expect to have an hour to dedicate to a task but am interrupted half way through by a Production issue, then this is an unexpected (unplanned) interruption (task change).
Regardless of planned/unplanned task switching, we can generally say that more time spent per task is a good thing.
Alright, so how much time do you spend per task?
I average 14.6mins per task.
No hold on, I forgot to exclude my commute time from that calculation, one sec....
I average 13.5min per task.
No, no, that still isn't right. Let me get rid of meetings too, those really shouldn't count.....
I average 10.5min per task.
Even the Pomodoro Technique uses a minimum of 25min focused on a single task before taking a break.
What is the cause?
Unfortunately, the raw data can't tell us that. Instead, we'll need to look at the data within the context of many of the themes already explored in previous posts.
Given that, let's walk through what I believe to be some of the causes of all this context switching.
๐ Meetings
As alluded to in a previous post, even if the number of meetings is small, how they are sprinkled throughout the day can have a significant impact on how much time there is to get work done in between these meetings.
Overall, I average 1.58hrs of "free time" between meetings. On a good day, with very few meetings, that time gets closer to 3.5hrs and on some of my worst days, the time is more like 25mins.
On Mondays, when I historically have the most number of meetings, my time spent per task drops to 9.45mins.
On Fridays, when I historically have my fewest number of meetings, my time spent per task jumps up to 12.8mins.
We can definitely see how the number of meetings and the timing of meetings could negatively impact my time per task statistic.
๐ Unplanned work
Unplanned work accounts for 20% of my free time and by definition, this unplanned work would interrupt planned tasks. In a given day I can expect 1.5hr's worth of interruptions.
Two of the most common forms of interruptions I see in the data are:
- Queries from people - 28% of my interruptions originate from this source accounting for 8% of my overall time
- Prod/NonProd Env Support - 24% of my interruptions originate from this source accounting for 7% of my overall time
Queries from people is a hard problem to solve. In fact, I am hesitant to call it a problem as I don't ever want to discourage people from asking for help.
But I do see some things in our workflow that could be improved on:
- More documentation, and creating a culture of documentation
- Dedicated SME's per project, and a culture of developing more SME's
The second major time drain is investigating and supporting Environment related issues, and this should definitely not be taking this much of my time. This is an area where a shift in company priorities to stabilize these parts of our operations or filling a dedicated support role on my team would dramatically help. This is a metric worth doing a deeper dive on though.
๐ฌ Slack
Now this is a bit of a catch all, and it overlaps quite a bit with the "Unplanned Work" we just discussed.
Slack messages are almost always an interruption. And I spend 16% of my time reading or responding to Slack.
That's nearly a full day per week spent just on Slack.
Despite my companies recommendations that we only check Slack once every hour or so, this is completely unrealistic. In my roles, some things are time sensitive. Some things are worth being interrupted over, especially if I can remove a blocker for an even more important project than what I'm currently working on.
There are some strategies for customizing Slack to limit non-critical interruptions, but it is far from perfect, and even with this finely tuned, I still find myself needing to check in on Slack almost constantly.
๐ข Office
On days I'm in the office, this time per task metric drops to only 8.77mins per task.
I believe the two main culprits here are meetings and people.
As we saw previously, percentage-wise I spend more time in meetings relative to available time on days I'm in the office. This naturally leads to more time segmentation in the day.
The amount of time I spend on ad hoc queries nearly doubles on days I'm in the office. Add this to the already limited amount of time I have between meetings and the 8.77min number starts to make a lot of sense.
Is there anything to be done about this?
Spoiler alert....
I've known about this metric for a long time so I've already had the opportunity to experiment with it a bit. And like all things, the answer to the above question is: it's complicated ๐คทโโ๏ธ.
โ๏ธ What I can do...
One of the big opportunities from the data above is to limit meetings and decrease overall segmentation of the day.
One of the strategies I adopted to help improve this metric was Time Blocking.
For the purposes of this analysis, here are some key things to know about how I adopt Time Blocking:
- Generally, I only block time for the same day or one day in advance
- An exception to the above rule would be for a large task with a specific deadline
- I don't time block every task or every day. I lean into this practice as needed.
- Time blocking does not mean I ignore Slack
As a result of Time Blocking, I saw a noticeable improvement in my time spent per task metric.
In the first quarter of the year, I was averaging closer to 8min/task but on the weeks I religiously use Time Blocking I see this metric jump to 16min/task!
But that's not the full story.....
โ What I can't do...
The thing about Time Blocking is it is only as effective as my sole power and ability to protect that blocked time.
As I mentioned above, I do not ignore Slack interruptions during these blocked times. Additionally, exceptions still need to be made if something more critical crops up.
Addressing these two challenges, in my experience, require broader culture and organizational changes.
For example, in the week that I typed up this post, my time spent per task dropped from that lovely 16min/task value down to 11min/task. I was still making use of Time Blocking, but the interruptions that came up were outside of my control.
Cool, but can we see some charts?
This post ended up being quite the wall of text ๐, sorry about that!
The data required evaluating across so many different intersections that there wasn't a clean way to visualize it.
But I won't leave you without at least a few charts to ogle at ๐.
Data is representative of 164 working days from Jan 2024-September 2024.
Conclusion
So far this has been my most shocking and horrifying ๐ฑ metric.
I knew there was a problem with context switching at my job. But seeing it quantified in this way has really elevated its importance to me.
There is always a balance to strike between quality and speed .
I know that 10.5min is not enough time for me to deliver high quality progress on a project. Even if I am still delivering good enough progress I suspect it is paired with high stress and burn out.
As the ultimate stakeholders it is on "the company" to decide how much or how little quality they are willing to sacrifice in order to meet their objectives.
But even with the constraints of the companies expectations, it is to my benefit to improve this metric as much as I can so this will continue to be one of my key focus areas as I experiment with different time management strategies at work.