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.....

๐Ÿฆ–
In an effort to better understand "how I do work" I decided to start tracking my time. If you haven't already (or need a refresher), I recommend you start with the introductory post: Project: Tracking Time at Work. You can find all the posts in this series here.
tracking time at work series - Next Topic
Sometimes I do fruitless projects.... ok, I often do fruitless projects. This is one of them. I tracked my time at work. Then wrote some blog posts peeling back the data onion layers.

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.

๐Ÿšจ
Can you imagine, having to make progress on something only 10.5min at a time?

Even the Pomodoro Technique uses a minimum of 25min focused on a single task before taking a break.

๐Ÿšง
Unlike previous posts, this will be more text heavy and lighter on visualizations. Jump to the end to see some charts on the raw data.

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.

โ„น๏ธ
The below analysis will continue to exclude data from my commute and meetings as I want to really focus in on the time where I would be working as an individual contributor on a deliverable.

๐Ÿ“† 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.

Tracking Time at Work: Meetings
If you havenโ€™t heard an engineer complain about how many meetings they are in, then you might be living under a rock. Itโ€™s practically a trope at this point.

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.

Tracking Time at Work: Planned vs. Unplanned Work
Weโ€™ve all been there. You plop down at your desk, bright-eyed and bushy-tailed ๐Ÿฟ๏ธ, coffee steam curling lazily up from your โ€œbest dog momโ€ mug โ˜•. You know what you need to do today.
pie title Unplanned Interruptions "Queries from people": 28 "Prod/NonProd Env Support": 24 "Work related to ongoing Projects": 48

Two of the most common forms of interruptions I see in the data are:

  1. Queries from people - 28% of my interruptions originate from this source accounting for 8% of my overall time
  2. 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:

  1. More documentation, and creating a culture of documentation
  2. 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.

๐Ÿ”ฅ
If End User Experience is impacted by a Production issue, I should probably not wait till the top of the hour to check in.

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.

โ˜น๏ธ
Slack provides a woefully disappointing lack of metrics around it. Ever try to figure out how many slack channels you are in? How many messages you've received? How many messages you've sent? I'm desperate for this data!

๐Ÿข 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.

๐Ÿ‘‰
I actually adopted Time Blocking to help address a few different problems with mixed results, but that discussion is worth its own post.

For the purposes of this analysis, here are some key things to know about how I adopt Time Blocking:

  1. Generally, I only block time for the same day or one day in advance
  2. An exception to the above rule would be for a large task with a specific deadline
  3. I don't time block every task or every day. I lean into this practice as needed.
  4. 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.

๐Ÿ’ก
Time Blocking is only as effective as my sole power and ability to protect that time.

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.

xychart-beta title "Avg. Time Per Task over Time" x-axis [jan, feb, mar, apr, may, jun, jul, aug, sep] y-axis "Time (in min)" 0 --> 20 bar [15, 8, 8, 12, 11, 10, 13, 16, 12]
xychart-beta title "Avg. Time Per Task by Day of Week" x-axis [Monday, Tuesday, Wednesday, Thursday, Friday] y-axis "Time (in min)" 0 --> 20 bar [9.45, 10, 10.8, 10.4, 12.8]
xychart-beta title "Avg. Time Per Task by AOR" x-axis [Architect, Discovery, Delivery, All, None] y-axis "Time (in min)" 0 --> 20 bar [14.9, 12.9, 12.7, 9.51, 6.21]

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.

๐Ÿ‘ฉโ€๐Ÿš€
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