Why Software Teams Hate Tracking Time

Software developers hate tracking time.

It’s seen as burdensome, useless, and “a colossal waste of time.”

This is because time tracking for developers has traditionally been about control.

It’s been a way for management to put a harness on their development teams and steer the ship in some way. Ostensibly, for the sake of better productivity or more accountability.

But, just like any other creative, problem-solving profession, it’s obvious that software development is not easily measured and evaluated in discreet increments. The number of widgets per hour that software developers create is not a valuable measure of skill or performance.

Simply writing more code in less time or “completing” more tasks in a day does not make you a better developer. In fact, it’s often the antithesis.

For this reason, engineers have come to see keeping time as misguided at best. (Machiavellian at worst.)

Building software is about creative problem solving, collaboration, and quality control. This is why so many teams have embraced an agile methodology. You trade increased autonomy for greater responsibility and ownership over your time and the work that you’re doing.

But, there’s still a role for timetracking in that process.

If you’re a team lead that wants your team to embrace time tracking, you need to work on reframing the process. Rather than being a process for you and other managers to control development from the top down, there should be a real and honest conversation about how tracking time can develop more autonomy for the team–not more control for managers.

Time Tracking Should Be About Mastery, Not Control

In the book Drive, Daniel H. Pinkman contrasts the creative professions of today with the manual labor jobs of yesteryear. His argument is, essentially, that the management processes that dictated speed and efficiency for repetitive tasks do not translate well to the kinds of jobs that dominate white-collar work in the 21st century.

[upgrade]

Keep time. Don’t waste it.

7pace is built for development teams who don’t have time to waste counting every second they spend working.

Fully integrated timetracking for TFS and VSTS that’s out of the way and works like magic (almost).

Learn more about 7pace

[/upgrade]

Measuring and rewarding success based on an arbitrary quota or dictated rate of work is often counterproductive and can put a massive damper on staff morale and work ethic. That’s largely because the kind of work that so many of us do is not as straightforward as, say, tightening the same screw to a specific torque 100 times per hour.

In the book, Pink identifies three core internal motivations for successful employees:

1. Autonomy
2. Mastery
3. Purpose

Each of these pieces helps to provide motivation to employees, even without rigid management and control structures.

And this is how timetracking should be imagined in the modern era of software development.

It’s not a tool for control. Rather, it’s a tool that advances each developer’s ability to attain autonomy, mastery, and purpose.

While agile methodologies use systems of points to structure sprints and iterations, these are ultimately too broadly defined for true analysis and progress. They can’t provide the level of granular insight that you can gain from translating those points into tangible, measurable, and (self-)manageable seconds.

By measuring and analyzing their own use of time, engineers are able to gain complete control over how they spend that time.

They are able to work toward their own motivation of mastery based on their own measure of speed and efficiency (not as dictated by a manager or executive). And their sense of purpose is reinforced by a drive not only complete tasks and projects, but to continuously monitor and improve their own abilities.

via GIPHY

Lose the Carrots and Sticks

Creative work is often not conducive to speed and efficiency. It commonly requires a more methodical, calculating approach. It requires time and consideration to come to the proper solution.

Any software developer probably instantly recognizes this to be true.

Rather than rushing to create a solution as quickly as possible, any sufficiently skilled engineer will take more time to fully analyze the problem. Although it may take more time to “complete the task”, the resulting solution will be better and less prone to errors. Implementing a quick solution often leads to developers having to constantly “put out fires”, jumping from bug to bug–trying to find quick fixes.

This problem, of course, becomes self-perpetuating.

The more solutions that are implemented in such a haphazard way, the more likely they are to lead to additional problems down the line. And on and on.

When organizations use time tracking as an external mechanism for control, this is often the outcome. Engineers feel the weight of time. They’re expected to perform within the confines of a timesheet, often sacrificing quality and innovation for expediency.

This is why time tracking can’t be seen through the lens of traditional carrots and sticks. It sabotages the very foundation of what it means to be a talented and high-performance development team.

Tracking time should be seen as an inherently valuable as a way for engineers to manage themselves, not for its value as a control mechanism.

How to Advance Time Tracking In Your Organization

Simply understanding that time tracking is valuable and that it should be framed in a new way isn’t enough to change things.

As a team lead, you need to take action.

Here’s how to get started.

Start with a discussion about the underlying reasons why time tracking is valuable.

Keep in mind that you’ll likely need to completely reframe the entire concept of tracking time. Most developers–especially senior engineers–will have a lingering memory of archaic and restrictive systems for tracking time.

Make it clear that time tracking is for the benefit of the individual developers. Give it purpose beyond a control mechanism for managers.

Make sure that management understands how time tracking should be used.

Even with the best intentions, it may be tempting for management to grab hold of timesheets and use them to scrutinize and itemize completed work.

This must be avoided at all costs.

As soon as this is allowed to happen, the very concept of time tracking will feel toxic and manipulative rather than insightful and valuable.

Team leads must have clear dialogue with management to set expectations about the role that time tracking will play. Set ground rules for how time tracking data will be used as a way to bolster internal motivation rather than a mechanism for external reward and punishment.

Find the right time tracking solution.

One of the most common complaints about time tracking from developers is that it’s arduous and time-consuming. They’re forced to spend hours each week trying to remember what they worked on–and for how long–the week before.

Skip this conversation completely by finding a time tracking solution that works seamlessly with your current workflow and tracks time according to task status. This will eliminate the need to remember tasks or log hours manually and make the whole process simpler.

Integrate time tracking into the planning process.

Last, but not least, you need to find ways to demonstrate the value of tracking time.

[upgrade]

Time tracking without the time-suck.

7pace is built for development teams who don’t have time to waste counting every second they spend working.

Fully integrated timetracking for TFS and VSTS that’s out of the way and works like magic (almost).

Learn more about 7pace

[/upgrade]

Assess your development process and find ways to incorporate the time tracking mechanism into sprint planning, retrospective, or annual reviews.

Again, keep in mind that the time records should be used as an individual metrics for personal performance and goals only. Don’t keep a public leaderboard of which developers are most “efficient” or set quotas on story points to be completed per hour of work.

Instead, use it as a benchmark for each individual developer and for the team as a whole. Look for opportunities to improve and identify bottlenecks or adjustments that can be made to help everyone grow and improve.