This post is from the standpoint of a developer, but could be used to understand other similar supportive roles. Any methods or tools mentioned here are reflective of my preference and shouldn’t be considered an endorsement from myself or my employer. Read Content Disclaimer
Over the last year or so at work, we’ve been slamming through our Development task list, but the total is still hovering at 105 open tasks (57 issues, 48 general tasks; 3 developers, 5 repositories). After tracking the totals over the last 9 weeks, it’s clear that a lot of work is getting done (average of 31.32 tasks updated/week). At the same time, however, a lot of new work is being created. You could say it’s just the nature of web development (“fix one bug, two more shall take it’s place”), but I wanted to dig in further and see what could be improved.
When working in an office, especially as someone in a technical role, you tend to get a lot of random requests. Assisting with password resets, helping set up a video call, making an edit in a WYSIWYG editor… All these things, though helpful for others, can take away from valuable time to get “in the zone.” Plus, sometimes there is someone else more capable that can help. A good example of this is that our Marketing team manages all the content on the sites, but sometimes requests for content changes are sent to the Development team. Since they are more familiar with the content of the sites (and are probably already logged in), they can complete the work quicker and even make other suggestions/improvements to the copy/images.
Tracking the Untrackable
We track our tasks and tickets using Asana and Bitbucket Issue tracking, but certain interruptions or surprises get lost in the day-to-day. These can be categorized very simply as “unexpected requests” and “fire fighting.” (And even further, as is in my excel sheet, under “code-related” and “non-code” for both categories.)
An unexpected request would be some type of rush job, let’s say someone needs a change to a form or API call because a process is changing, but they need it by today/tomorrow due to a misunderstanding of who is involved in the change.
By contrast, a fire is a bug or issue with an existing component or piece of functionality that prevents someone from doing their job. This would be something like an Apache module being turned off that’s needed for an integration, an issue with a hosted API library that prevents notification emails from being sent out, etc.
The main differentiation I make between a “fire” and an “unexpected request” is that, although both seem urgent to the requester, the fire is more urgent. Fires can be reduced with a cleaner code base, more attention to detail, a new approval or testing process, etc. Unexpected requests can only be reduced when better reporting processes are followed or with better prioritization.
These types of tasks typically grab our attention and get prioritized above the existing work (usually for good reasons). In theory, both unexpected, urgent requests and fires can be prevented with more/better planning. But they will likely never be eliminated. In order to understand the balance between work that’s planned and work that’s unplanned, I’ve been keeping tallies. On a notepad, I log every unexpected request or “fire” the Development team encounters. At the end of every week, I quickly run through the list and further categorize each as “code” or “non-code.” (This can help identify if we’re swamped with work only we can complete, or we’re swamped with work others can help us with.) Then, I have an Excel sheet that visualizes the findings of my tallying combined with our actual, tracked task list(s).
The problem is, these graphics don’t show the whole story. Based on these stats, you could speculate that the role that unexpected work plays in our workload is minimal. This format is a bit misleading and isn’t representative of the shared feeling of imbalance. So how does unexpected work actually impact our time spent on existing, planned projects?
Perception vs Reality
Now that I know that the stats show just a tiny percentage of the work being “unplanned” tasks, I’m on a mission to find more representative data. The answer to finding less-misleading stats lies in where we focus most of our energy, or our time spent on “unplanned” tasks. I’ve been using Timeular (a time-tracking cube) to track my time since 12/19 now to try to find the potential time-wasting tasks (and therefore money-wasting tasks).
The issue with the visualization above is that it doesn’t speak to the varying amounts in each category or show the spikes/outliers in a particular category. For example, the “Fire Fighting” category has been as low as 0% of my time, then on one particular day, as high as 55% of my time. Similarly, “Management Things” fluctuates between 0% and 15%. This data visualization also doesn’t suggest proper allocation of time in each category. So I headed back to Excel…
Less-Misleading Stats
This probably won’t be my final version of this spreadsheet/visualization, but so far, it’s been the best for me to personally notice any areas that can be improved on. I’ve been using tags (cropped off the screenshot) to identify further when there are spikes. For example, if I’m working on “Documentation Outside my Team,” I use a tag to denote which team I’m creating documentation to help. Or if I’m working on “Maintaining Websites,” I use a tag to note which site I’m working on. The former will help identify the value I’m bringing to the company by helping other departments. The latter will help with identifying a product valuation for the individual sites we have (once everyone is tracking their time in this manner).
Contact me via Twitter or my contact form if you have any feedback!