How Time Tracking Makes Our Software Team Better

At Blueshift, every member of our team tracks 100% of their work time, from the most junior engineer to our CEO. That means from the minute we start work in the morning to the minute we leave, we record exactly what we’ve been doing, every minute of the day. We don’t do timesheets (they suck), we just use a time tracking tool that allows us to track as we work. If you don’t do something similar this probably sounds a bit extreme, but it’s foundational to the way our software development team operates, so I thought I’d share a few of the key principles behind why and how we do it. I’ll start with the more fundamental points, and finish with the really cool stuff.

Visibility

It sounds a bit basic, but actually seeing where our time is spent is a massive win. We use time tracking data to improve individual, team and business visibility in more ways than I could list in this post, but here are some of the highlights:

In my personal development work I often check my time tracking as I reflect on my progress through a work item and plan my next steps. As a team lead, I rarely get large blocks of time for development, and working in small separated chunks I often lose track of how much time I’ve spent, so having an accurate reference is a big help in making sure the time I spend is proportionate to the actual importance of the work.

As a team lead who does a mix of management, development and support work, time tracking is also super useful for understanding where I’m spending my time and effort, and ensuring this aligns to team priorities. We actually have reports on this for our entire development team to track the proportion of time spent in development, support and admin/planning work, but more on that when I talk about data-driven improvement!

For the team, we sync our time into Azure DevOps so we get instant visibility on our taskboard for how long has been spent on each work item in development. The board automatically highlights work items over a time threshold, which we review and discuss in our morning standup, as this is generally an indicator that someone needs help, or we need to loop in the stakeholders to confirm the scope and priority of the work. In addition to the live reporting in Azure DevOps, we also report on average time spent per work item in each sprint and we use this to refine future planning.

As a business, we use time tracked against support tickets to provide exact SLA reporting to our clients, and if there are any questions, we can drill down to the individual ticket to explain where time was spent. We also use time tracking data as the basis for visibility of profitability by project and client, which is super interesting… 🙂

Accountability

As a team leader I trust my team to do their work without micromanagement and we have very flexible remote work and flex-time policies. Having said that, trust is naive without accountability, and time tracking allows myself and the team to keep ourselves accountable to the work we have committed to. This accountability manifests in two main ways which I’ll explain from my personal context.

First and most obviously, I am paid by the company to work a certain number of hours per week, and tracking time allows me to ensure that I work the hours I’m being paid for, even if I flex and work remotely or at a different time. Clearly I can also use this as a manager to ensure my team does the same.

Secondly, by recording what I’m actually working on, I keep myself accountable to the priorities of the team. I suspect that in all software teams the backlog of ideas and work is much larger than can ever actually be accomplished, so it is critical for the team to prioritize this work, and deliver just the things that will actually add value to the client. Many times, I’ll have great ideas for things I could do that would be really fun or interesting, but don’t truly fit into the priorities of the team. Tracking what we’re working on means we can hold ourselves accountable for sticking to the priorities we have established as a business.

Single-tasking

As a general rule, multi-tasking sucks and should be avoided. But it’s so tempting! Using a live time tracking tool forces you to record your time against a single task, and when you click the button to start tracking, you can use this as a cue for a good habit of working on just that one task until it’s done (or you need a break). It’s like making a small contract with yourself to stay focused as you start each task. I suppose this is a form of accountability too, but I liked it enough to write in its own section!

Data-driven Improvement

This is the area where I get most excited – using our time tracking data as part of the third way of DevOps – continual experimentation and learning. I find the biggest challenge when we experiment with team improvements is actually quantifying the impact of what we’ve changed, but time tracking data is an awesome tool to use for both identifying problem areas, and quantifying improvements. For example:

We use time spent on previous work items and support tickets to quantify pain points and areas of technical debt in our software so we can prioritize improvement according to actual impact.

We use time tracking data to quantify the proportion of time that the team spends per sprint in four categories: development, improvement, support and admin/planning work. Generally we want to increase development and decrease support and admin, so this is a perfect metric to see the impact of improvement work and experiments. We track improvement work separately to ensure we’re always investing in paying down technical debt and improving our daily work (which we haven’t always done in the past, to our great regret!).

One thing we don’t do yet, but I really want to do, is use time tracking in combination with cycle time data to calculate Activity Ratio which is a metric from lean manufacturing that is used as an indicator of flow. We’ll be able to use this to identify inefficiencies in our development process and improve them to increase flow (the first way of DevOps!).

–

Convinced? Great! How should you start? Well that’s another blog post but here’s the short version: Sign up for a high quality time tracking tool (we use Toggl) and just start tracking your time, ideally by work item and in some sort of standard categories. Track everything as you go, and if you miss something, fix it immediately. It won’t take long to build a habit and tracking as you work will add minimal overhead to your day.