Here’s the Thing Development Leaders Get Wrong About Time Tracking
It’s that time of year.
Many managers like to give small gifts to their team, just to show their appreciation. But sometimes it can be a struggle to figure out which gifts are the right combination of work appropriate and meaningful/useful.
One popular gift from the last few years? Fitness trackers.
They’re a handy gadget that employees can use on their own time and in their own way to help improve their life–even in small ways. They can track their own progress, measure their results, and hopefully feel good about themselves as they set and reach health goals.
And most smart companies know that having healthier, more active employees is a net benefit for them, too. Healthier people tend to be better at their jobs, happier, and more productive.
But what if it wasn’t just a nice gesture with a small upside for the company?
What if you decided that because health and fitness are imperative to employee productivity, you would start actively tracking and managing each of your employee’s habits?
What if the FitBit you bought each employee logged the data into a work database and then that data was reviewed and used to measure each member of your team?
Okay, that seems like some kind of far-fetched, dystopian micromanagement hell. Right?
But is it really all that different from how most managers treat time tracking?
I mean, think about it. You provide tools for your team to track their time and performance on their tasks. Then many dev leaders use that data as a way to micromanage the team and knitpick about the time different tasks take or how time gets spent.
This is entirely the wrong approach.
Sure, you may argue that a company “owns” their employees’ time because they pay for it. Even if we ignore the weird and creepy connotations of this line of thinking, this still undermines the point of time tracking in the first place.
The net benefit for companies when it comes to time tracking should be that it provides a way for team members to measure their own performance. It gives them a way to track their progress, set goals, and evaluate their abilities.
But, as soon as it become a mechanism for controlling and managing every minute of the work day, that affect backfires. Rather than a tool for developers that helps fuel their intrinsic motivation for self improvements, it becomes a chore–something that controls them.
Just as if you used fitness trackers as a way to force your employees to exercise, using time tracking as a mechanism for control is the wrong approach.
Personal performance and intrinsic motivation
We get a number of surprising questions from managers and leaders using the 7pace product. In particular, we get a number of questions that let us know they are using the app in completely the wrong way.
One of the most common:
“What do I do if my developers say something will take 5 hours and it takes 10 instead?!”
You can hear the panic in their voice just reading it.
It’s natural and understandable to want to react to this scenario in some way. As a manager, it sucks. You had specific expectations–and likely communicated those to others–that turned out not to be reality.
The knee-jerk reaction is to take some kind of action to reconcile this discrepancy. There must be a way to right the books and make sure this doesn’t happen again.
After all, time is money, right?
But this misses the bigger point which is why this discrepancy exists in the first place. It may be that the engineer in question did not have the necessary skills or knowledge to complete the task in the expected timeframe. Or it could be that they did a poor job of estimating how long the job would take.
In either case, the burden for improving future efforts ultimately falls on that developer.
They either need to focus on growing their own abilities–so that this task would, in fact, only take 5 hours rather than 10. Or, they need to better understand their capabilities so far as it allows them to more accurately gauge the amount of work for a specific task.
No amount of chastising or punishment here will help the situation.
This is the central thing that most development managers don’t seem to understand about the role of time in software development and the role of time tracking as a tool.
When we created 7pace, we didn’t do it because we wanted to build something that gave managers a better way to keep an eye on their team. We wanted to give developers a way to track and measure their own performance over time and without extra effort. We wanted to create a fitness tracker for engineering ability.
The reason is that we know that developers do their best work when they’re powered by intrinsic motivation–when they’re driven by their own desire to solve difficult problems and improve their own abilities.
Any skilled engineer with sufficient motivation and interest in the work they are doing will have a drive and desire to improve their own performance over time. Just as people hope to improve their own performance and physical fitness when it comes to running, swimming, or lifting weights.
And through that mechanism, companies and managers will also benefit.
When given the right circumstances–and absent the wrong ones–engineers will increase their abilities and their productivity over time. They will learn to solve new problems in less time and how to more effortless control every minute and hour of their day.
But this kind of progress can’t be heaped upon them by a manager dictating from a timesheet.
The disconnect between management and engineers when it comes to time is largely a matter of who owns it–how it should be tracked, managed, and spent.
So how should managers deal with scenarios in which developers don’t meet their estimates?
In the same way they would deal with their team member not meeting a fitness goal or an activity challenge. Give them the information and encourage them to set goals and work toward those outcomes. Then, let them figure out the best way to move forward.
At the end of the day, it’s their time–it’s their life. They’re the only one who can ever truly own it.