I’ve had a number of jobs where time tracking was required, usually because the time was on-billed to a final customer. In these cases, managers were often keen to see as many hours as possible recorded as billable, even if time being spent was a business overhead. As I type that last sentence, I realise it’s probably a topic for another discussion that focuses on ethics!

It was in my current job, with a view to improving my ‘leanness’ and stop myself working so many extra hours, that I started collecting data around what I was working on. Yes, I chose to add time-tracking to my day!

At first it was simple — tracking time spent working and time spent on breaks. As I progressed, it became more complex as I started to split out work per project and then into other sub-categories.

As my recording became more complicated, I re-read Google’s Site Reliability Engineering (SRE) book and became caught up in its categorisation of time spent.

Google uses the following four categories to track SRE time:

  • Software engineering — involves writing or modifying code, in addition to any associated design and documentation work. Examples include writing automation scripts, creating tools or frameworks, adding service features for scalability and reliability, or modifying infrastructure code to make it more robust.
  • Systems engineering — involves configuring production systems, modifying configurations, or documenting systems in a way that produces lasting improvements from a one-time effort. Examples include monitoring set-up and updates, load balancing configuration, server configuration, tuning of OS parameters, and load balancer set-up. Systems engineering also includes consulting on architecture, design, and productionisation for developer teams.
  • Toil — work tied directly to running a service that is repetitive or manual etc.
  • Overhead — administrative work not tied directly to running a service. Examples include hiring, HR paperwork, team/company meetings, bug queue hygiene, snippets, training course, peer reviews and self-assessments.
     

Although my environment differs from Google’s, using these general headings mostly worked until my workplace ‘went agile’ and adopted a lean approach of its own volition. This introduced new categories I hadn’t been capturing, like value streams and waste.

 

I tried to incorporate lean categorisation alongside SRE but soon encountered a problem. While the two had some overlap, they didn’t appear to have a complete 1:1 mapping — SRE has toil, lean has waste. This meant my time tracking exploded in complexity, becoming a time problem in its own right.

This issue was the original angle of this article. However, in researching it, I stumbled upon a website that referenced Yasuhiro Monden’s book on the Toyota Production System — the company’s approach to just-in-time manufacturing. The book identifies three main types of activity:

  • Non-value-adding operations (NVA) — actions that should be eliminated, such as waiting.
  • Necessary but non-value-adding (NNVA) — actions that are wasteful but necessary under current operating procedures.
  • Value-adding (VA): conversion or processing of raw materials via manual labour.
     

NNVA activities are also referred to as ‘sustaining non-value-adding’ — things that must be done to sustain the business but don’t contribute to customer requirements.

Definitions like these are commonly referenced when talking about lean. However, it was only with the SRE definitions clear in my mind that the three TPS types seemed to be strikingly similar in comparison:

  • Toil is a non-value adding operation (NVA);
  • Overhead is necessary, but non-value-adding (NNVA); and
  • Engineering, of course, is value-adding (VA) work.
     

With this in mind, I went back to my timesheet to recategorise all my tasks and it has helped immensely. I now have ‘toil’, ‘overhead’ and ‘engineering’ as top-level categories; admin fits into overhead, toil contains things which should have been (or can’t be) automated away and ‘engineering’ is reserved for projects and configuration management.

In the quirky way the world sometimes works, this improvement in my time-tracking was only made possible once I decided to write an article suggesting that it wasn’t possible at all. So, thanks for reading!