The Horrors of Tracking: Why We Should Build Trust and Freedom into the Workplace

A Ford car, prior to 1913, took about 12 hours to assemble. Time in business is expensive; the more time your product takes to build the more money you are expending on labour, energy, and other miscellaneous outgoings such as buildings upkeep. Ford had tried many ways to speed up the process of building the car, and the end result was the production line. This took the car building process from a fairly ad hoc process where anyone could do anything, to something that was a series of individual units of work on a moving production line. The speed as which the company could make money, because tied to how fast that production line was. A car now took 1 hour and 33 minutes to assemble.

Why am I writing about this story? Parallels can be drawn to the relationship between tech companies and factories in their relationship with their Software Engineers; the engineers are the factory workers which produce the goods the company is selling. Therefore, one can see that temptation may creep in to thinking about how one might take the software which takes months to write, to only take weeks. The gathering of metrics and the desire to treat work as a production line creeps in.

And this is where I have to mention something I recently read about: a tool by Pluralsight,called Pluralsight Flow. This tool tracks the productivity of your developers by measuring how many commits they do in a day, how many lines of code they write, and how many tickets are completed amongst many, many (many!) metrics. These metrics are being collected under the assumption that extremely exhaustive metrics are a good measure of productivity, but the evidence for this seems scant. Even Pluralsight Flow’s own website cannot make claims that they in any way increase software delivery times.

And in a similar line, Scrum and Agile are horribly abused to try and bring predictability to intrinsically unpredictable job. Project delayed? Well this means you need to break every ticket up into [insert arbitrary number] size. The smaller you break tickets up, the more predictable our delivery cycle will be. Ticket delayed/unexpected problem appeared? This means you should have spent more time in refinement, and less time actually doing anything productive.

I have a particular memory of trying to convince my Scrum Master many years back that our sprint was going badly and our goals weren’t going to be met. He was adamant that this was not the case, as the burndown chart of hours spent on tickets was burning down nicely, despite my pointing out to him that the it didn’t show tickets were taking longer, only hours being burnt.

Metrics only show that metrics have been met. They can lead people to try and meet the metrics, rather than using their judgement. A horrific example of why this is bad was seen in the Shrewsbury and Telford Hospital maternity ward in the UK. The NHS had targets to have below a certain number of caesarean births. This led to many horrible cases of death and disability because women and medical staff were not allowed to have the freedom to make the best decision for the mother and child.

The pursuit of measurement and strict process is a distraction from what we should be aiming for. What you want are motivated, smart, efficient teams. The way to do that is not to infantilise, but to give power and freedom to those individuals to do what is a deeply creative and intelligent job. If you hired them, then trust them to do that job, otherwise you need to question why you hired them in the first place. I do believe in having process and metrics - you cannot just have a bunch of people doing whatever they want everyday - but it should be an empowerment tool, rather than a judgement tool.