How NOT to Do Time Tracking for Software Developers (Unless You Want to Kill Your Team’s Morale)

With almost anything in life, there’s a right way to do things and a wrong way.

Time tracking is absolutely no different.

Look, we’re outspoken advocates for tracking time. After all, we are a team of software developers who willingly and knowingly created an application specifically for the purpose of time tracking, right?

Our philosophy is simple. Time tracking is like fitness tracking. It’s a way for you, as an individual, to assess yourself.

We think it’s super valuable as a tool for individual developers. We think that it’s totally normal and healthy for developers to want to own their time in a quantifiable way, measure their own abilities, and master their craft.

But it’s no secret that most developers have a visceral reaction to the very idea of tracking time.

The truth is that most companies do time tracking entirely wrong.

The reason why developers hate tracking time so much and fight tooth-and-nail against the idea of having to log hours is because companies have royally screwed it up. They’ve taken a tool that could give people more ownership over their own work and distorted it into a mechanism for managers to exert control over their team.

It’s like the company’s way of saying, “Sure, we trust you to do your job….but–just in case–we’re watching you.”

What kind of employee-employer relationship do you think that creates?

In most cases, if the developers on your team hate time tracking, it’s because of how it’s being implemented (or because they have PTSD from a previous job where it was implemented poorly.)

Tracking time can be an effective tool for helping developers own and improve their own abilities. But only if management resists the temptations to use it in other ways.

Most developers will reject the idea of time tracking based on 3 main objections:

• It becomes an enormous timesuck
• It robs developers of autonomy
• It kills morale

And, in a lot of cases, those developers would be 100% right to reject such a system.

The number one problem with the way that time tracking is implemented for software teams? It comes from a position of top-down management. It assumes that workers should be measured and evaluated on the basis of their sheer capacity to produce.

This is how factories and assembly lines get managed–like a machine that’s calibrated based on strict inputs and outputs. But this thinking doesn’t apply to knowledge work.

Widgets per hour is not a valid measurement of developer performance.

But that doesn’t mean that time doesn’t matter. It just means that the way time is used, measured, and accounted for in software development should be dramatically different than the way that it’s tallied up on the work floor of the local sawmill.

When you get time tracking wrong, it sucks.

But if you get it right, it can be valuable.

The key is to recognize when the way your company has implemented time tracking is hurting the team rather than helping them. Fortunately, it can be pretty easy to spot if you just take a step back and scrutinize how time tracking is being done–and how the data is being used.

Here are some red flags to watch out for.

Time Tracking that Becomes Its Own Job

The number one complaint about time tracking is the sheer timesuck of it all.

If the whole point of tracking time is, ostensibly, to improve time management and productivity, then doesn’t it seem entirely self-defeating if the tracking itself ends up taking up a disproportionate amount of the team’s time and energy?

Hint: Yes.

Any time tracking solution that requires developers to agonize over filling in their timesheet or thinking back to what they worked on last week is bound to lead to friction.

Teams actually like using 7pace because it integrates directly with Azure DevOps and makes tracking time almost entirely seamless. Work is done and tracked in sync. And there’s a separate GitHub time tracker solution as well.

This tears down the first barrier to implementing smart time tracking practices by not creating extra busywork for the team.

If your team uses a tool to manage work, then having an integrated solution for tracking time just makes sense. Better yet, make it something that requires little or no manual data entry. (Shouldn’t the tool do the work?)

This means your team can reap the benefits of time tracking, but without having the extra work that becomes a non-starter.

Time Tracking Leads to Time Quotas

Tracking time is good.

Using story points to measure story size is also good.

So, together, they must be better, right?

It’s tempting to put story points side by side with a timesheet. Surely you can just do a bit of simple math and define how many hours it takes to complete a story point, right? Then you’d have a simple SP-to-hour conversion rate that you can use all the time!

This is a common fallacy.

But, you should never conflate time with effort.

Story points are a measure of effort and difficulty of a task. Time is a measure of–well–time.

Another major setback for companies implementing time tracking is that they use the data that’s collected in order to create and enforce quotas on how much time is going into a project or iteration.

“Hey John, last iteration you completed 10 story points in 76 hours. This time, you should take on 11!”

This is asking for trouble. It sets a really bad precedent and confuses two different ways of thinking about work that’s being done.

Time data can be a benchmark for scoping and planning similar user stories or types or work. But it breaks down when you try to mix and match different measures. As tempting as it may be, if you find that your team is trying to convert one unit of work into another, chances are you’re heading for disaster.

It’s totally fine to have two separate measures of work.

After all, story points are subjective. Time is absolute.

You can use both of these to solve different types of problems and diagnose your work in different ways. But don’t try to conflate them or convert them as a way to pinpoint a single unit.

Time Tracking as a Band-Aid for Management or Trust Problems

Take that last point and crank it up to 11.

If you really want to demoralize your engineering team and galvanize their distrust for time tracking and management, then you can use their time sheet data against them.

Call them into a meeting. Pour over their time entries line by line and pick apart how they spent their week.

For added flavor, go ahead and tell them how much time you think they should have spent on those tasks—it’s sure to liven them up!

Any good manager should understand that knowledge work is not linear.

There’s no straight line to the final answer, and that means that there’s no quantifiable way to determine exactly how long it’s going to take you to solve a given engineering problem.

Greg Smith from Bocoup points out (while arguing against time tracking as a mechanism, ironically) that a developer’s time generally looks something like this:

So, yeah, there will be down time. No one can work at peak productivity all day–let alone all week. But that’s totally normal and okay. It shouldn’t reflect poorly on a developer or the team.

As such, there’s no value in scolding your team for using “too much time” on a particular task.

What you are communicating here is clear: You don’t trust your team.

If you trusted them, then you would provide them with autonomy to complete the work that’s before them. You would assume that their interests are aligned with yours and that they have no ulterior motives that involve lying or falsifying their time.

Ask yourself: Do you trust your them?

If you can’t trust your team to complete their work and provide accurate accounting for their time, then there are much deeper issues to unravel here.

Don’t wield a developer’s time data like a weapon to be used against them. If at any point you find this to be the case, then it’s clear that there’s a problem.

Getting Time Tracking Right

While a lot of companies get it wrong, we still believe that there is a smart and healthy way to implement timekeeping for developers.

The key here is the last part of that statement.

The exercise of timekeping–and the data that it captures–should be done for the benefit for the developers. It should be a tool that allows them to better understand, plan, and optimize their own work.

That means that it can’t become a control mechanism.

As soon as this happens, developers will lose faith in the system. They’ll rebel against the idea–if they don’t just quit the company outright.

If you want to track time (you should–it’s valuable data), you have to do it right.

To learn more about how to implement time tracking in a way that helps developers master their own work, but without killing their productivity and crushing their soul, check out some of our other articles.

We’ve written about it extensively:

• Why Software Teams Hate Tracking Time (And What Team Leads Can Do About It)
• You Can’t Manage Time: 7 Other Ways to Increase Team Productivity
• The Only Unit of Work That Ultimately Matters is Time
• The Development Lead’s Guide to Understanding & Managing Time
• How to Measure Developer Productivity