No spam, no B.S.
Unsubscribe if you’re not happy.
It’s a question that has plagued the development community for about as long as software teams have existed: Should time tracking be optional for developers?
It’s no secret that many developers don’t love having to track their time. When it comes to knowledge work like software development, time tracking isn’t an accurate measure of productivity or work quality, so what’s the point?
Even within the development community, there are many differing opinions on this. So we looked at some of the most common arguments against time tracking for developers, and then talked to some experts. They have a unique perspective to add: That time tracking can be used to benefit the developers themselves in unexpected ways.
Well, there are a lot of reasons. Here are a few of the most common reasons developers point to when they’re making a case against time tracking in their field.
Sure, there are usually things about our jobs that can feel tedious and unnecessary. But for developers, time tracking can feel especially like a waste of time — and extra chore that’s often overlooked and done in hindsight.
Research shows that workers who record their time days (or even weeks) after they do the work tend to make wildly inaccurate estimates of how long they actually worked, which adds to the feeling that time tracking is just a tool for managers to control their teams, and not anything that’s really necessary for the work that team is doing.
The previous problem and this one go hand-in-hand — one of the reasons time tracking can feel like such a chore is because many software teams don’t have a good system or the right tool for time tracking. We’ve actually solved this, but that doesn’t mean all development teams are using the right tools — many still use intrusive, outdated tracking methods, from software that gets in the way of work, to really old fashioned methods like tracking on scraps of paper.
Developers should know better than anyone that doing a job without the right tools makes that job a serious chore, so this is a big problem that turns many a dev against the idea of time tracking altogether.
And finally, there are all the myriad ways that time tracking just doesn’t really make sense for the type of work that developers do.
For one, developers are kind of known for their tendency to work strange hours and in irregular cycles of productivity. Software development is not a nine-to-five, and that can complicate the time tracking process.
Then you have to factor in how different types of coding can take different amounts of time. In a company culture that uses time tracking to judge a developer’s productivity, this can make it feel like a waste of company time to get stuck on a tricky problem or mired in some complex code, and those are things developers can’t really avoid.
That brings us very nicely to the final (and we think, biggest) problem with time tracking for developers: It creates the impression that only focused work time counts as work. Software development is knowledge work, which means it requires a great deal of mental energy to complete. Coding isn’t like an assembly line, where a worker can show up, clock in, do the work, and clock out. Often, even when we aren’t actually sitting at our desks in front of our work, knowledge workers are still thinking over tricky problems they have to tackle, blurring the lines between work time and time off. How do you track that with traditional time tracking methods?
Considering all those arguments against it, it’s no wonder a lot of developers are against time tracking, in the traditional sense. But does the practice have any hidden benefits? To answer that question, we turned to a couple of experts: Maxim Lutsan, our CTO at 7pace, and Sascha Zierfuss, one of our product managers.
Both Maxim and Sascha agree that forcing developers to track their time just for the sake of time tracking can backfire.
“Forcing people to do something usually doesn’t yield the best results, imposing its use without explanation will seem like a form of control to the devs and that’s not the goal,” Sascha explained.
But he added that this doesn’t mean developers shouldn’t track their time at all. In fact, what they really need to do is reframe their thinking around time tracking so they can use it as a tool to make themselves and their work better.
“Time tracking is a powerful tool to help with getting better at estimating work or seeing the progression of your skills, but it requires accurate data to be the most effective and that comes with using the tool seriously and not just ‘filling it out because my manager asked me to,’” he said. “Some devs just have a knack for estimating work and in those cases time tracking might appear as useless additional overhead, but for others it can help them improve and for both it allows them to track their progress and improvement over time.”
Maxim compares time tracking to something like the screen time report that’s built into a lot of mobile phone operating systems.
“This is a report based on user’s tracking where everyone can get insights and decide if he spends too much time with his smartphone,” Maxim said. Similarly, time tracking can give software teams insights about how they spend their time at work, and that’s where the real value lies, he said.
According to Sascha, those insights can be the key to doing better work — and becoming a better developer overall.
“Time tracking allows you to correlate effort estimates (typically story points) with the actual execution,” he said. “Being able to look back at tasks and projects to see how long they took to accomplish allows devs to become better at estimating how long a new, but similar, task or project will take. Nobody likes crunch time, so the more accurate the estimates, the less stressful the project is.”
But in addition to that, time tracking can help developers tangibly see their own improvement over time.
“Time tracking also allows you to see how you improve over time when learning new skills. For instance, when you start on a new language or technology it can be very motivating to see that a task that originally took you 8 hours, then took you 6 and now takes you 4 hours to complete because you’ve gotten more knowledgeable and experienced.”
Still, all the reasons developers resist traditional time tracing methods and requirements are real, and they deserve attention, Sascha said.
“The major negative is that time tracking is often seen as a way to control what people are doing. Unfortunately, some companies only use time tracking to ‘keep tabs’ on their employees. It is true that this is often merely the perception of those required to track and that’s why outlining the goals and advantages of time tracking becomes important,” he explained. “Another negative comes with some of the tools used for tracking; entering time can be a very tedious process and nobody wants to spend 30 minutes filling out their time for a day/week. If you need an entry in your time card for ‘entering time’ then you have a problem, not all tools are created equal in this regard so you definitely want to shop around and find something that fits your team’s workflow with minimal overhead.”
So what’s the bottom line? Where exactly do these two experts fall when it comes to making time tracking optional for development teams?
For both Maxim and Sascha, the downsides of time tracking for developers are major and deserve consideration. However, both of these experts agree: The downsides are outweighed by what teams can gain from tracking their time.
“By the end of the day I believe all teams track time somehow. It can be precise with time tracking or it will be rough with calculating a team’s Velocity for example,” Maxim said.
No spam, no B.S.
Unsubscribe if you’re not happy.