Article Blog Image

In Defense of Time Tracking

Best Practices

Time tracking gets a bad rap. It’s easy to forget, adds extra steps to an already busy schedule, and often feels like micromanagement. But hear me out—when used strategically, it can be a game-changer for engineering teams.

Let me be clear: I’m not suggesting that you track every minute of your day. In knowledge work, a lot of time is spent in thinking and discussion. Engineers should be assessed by the impact they deliver, not the amount of time they spend writing code. However, there are specific situations where tracking time can provide the data you need to drive quality of life improvements for your team (which ultimately benefits the business).

The Business Case for Time Tracking

In a previous post on demonstrating value as a site reliability engineer, I discussed how every SaaS business has the following goal: to make money by increasing sales/subscription revenue while simultaneously reducing the amount of unreleased code and the expense of operating and supporting the product.

In this context, time tracking can help quantify the cost of operations and support, especially when multiplied by an engineer’s pay rate.

Tracking time allows us to measure the efficiency of specific tasks and calculate their financial impact. When you can speak the language of the C-suite (time and money), you’ll have a much stronger case for prioritizing work that improves operational efficiency and your experience day-to-day.

Measuring Impact of a Specific Issue

Take, for example, a common engineering pain point: flaky test suites that intermittently block the CI/CD pipeline. These unreliable tests need to be fixed, but feature work often takes priority, leaving the issue unresolved. During sprint retrospectives, the team may complain about the problem, but without hard data, it rarely gets prioritized.

By tracking the time spent debugging these tests, the team can quantify how much this problem affects efficiency and costs. If your team is spending 8 hours per week fixing these tests, you can tell the product manager, “This is costing us 20% of an engineer’s time.” With a data point like that, the issue is far more likely to get the attention it deserves.

Measuring Operational Load

Beyond tracking specific issues, time tracking can also help measure the operational load your team carries. Many engineering teams spend significant time on “toil,” a term from Site Reliability Engineering (SRE) that refers to manual, repetitive tasks that don’t add long-term value. These tasks scale with the growth of the service and can drain your team’s time and energy better spent on feature work.

From a DevOps perspective, consider the four types of work of a team, as outlined in The Phoenix Project:

  • Business Projects
  • Internal Projects
  • Operational Change
  • Unplanned Work

By tracking time spent on toil (or operational change + unplanned work), your team can measure how much of their time is dedicated to non-value-adding activities. This data is huge when you’re trying to justify investment in automation, process improvements, or even additional headcount.

Expressing Problems in Business Terms

Again, time tracking doesn’t just provide data—it helps you communicate more effectively with decision-makers. From my experience, C-suite executives are laser-focused on two things: time and money. When you can present a problem as, “Our team is spending 25% of its time on unplanned work, which equates to $X per quarter,” it’s much easier to justify prioritizing solutions.

Speaking about team challenges in this manner makes it more likely that you’ll receive the resources and support needed to address them.

How to Make Time Tracking Suck Less

Now, let’s address the elephant in the room: tracking time is often seen as tedious. But there are ways to integrate it into your workflow without adding too much extra work.

If your team uses a ticketing system like Jira, you can add time-tracking metadata to individual work items, making it easier to track time spent on different types of tasks. Jira has built-in time tracking features, but other tools like Toggl can also be useful, especially since they offer API support, allowing you to write tooling that integrates with your existing workflow.

In the past, I used Toggl alongside custom scripts to ensure that all work items were tracked accurately. For instance, I set up a cron job to send daily email reminders to team members about untracked tasks, along with a shell script to make it easy to fill in the gaps. Another cron job collected the time tracking data and fed it into a Grafana dashboard that visualized the team’s operational load. This data was invaluable when I needed to present the case to the C-suite for hiring more engineers to automate toil and launch an SRE program.

Conclusion

Time tracking doesn’t have to be a burden when used strategically. It’s a powerful tool to quantify inefficiencies, measure operational load, and present your team’s challenges in a way that resonates with leadership. By recording time spent on specific tasks and framing the results in terms of cost and efficiency, you can make a stronger business case for prioritizing work that would otherwise be overlooked.

And with time-tracking features part of your issue queue system(Jira) and products specifically built for the task(Toggl), time tracking can be seamlessly integrated into your daily workflow, reducing the friction for your team. Ultimately, when used appropriately, time tracking becomes less about micromanagement and more about improving team experience.


While I have you, I’ve recently launched two new services:

  • RAPID Assessment gives you a focused, personalized, and actionable roadmap to enhance your system’s operations, based on best practices from leading tech companies.
  • Reliability Bootcamp is a one-day hands-on SRE crash course covering everything from kickstarting SLIs/SLOs and building effective on-call/incident response processes to conducting blameless postmortems and implementing safer code releases. By the end, you and your team will have made real, tangible progress toward running more reliable and scalable services at your company!

If you’re looking to level up how you run production, I strongly recommend checking them out!

Tags: