No spam, no B.S.
Unsubscribe if you’re not happy.
For many developers, the very act of timekeeping feels toxic.
It’s understandable that they feel that way. Timekeeping has an image problem, and for good reason — a lot of teams, organizations, and managers approach it entirely the wrong way, and actually do make it into a toxic process.
But it doesn’t need to be that way. Timekeeping itself isn’t the problem. The process isn’t toxic.
Your management is.
The problems developers have with timekeeping can almost always be traced back to management — their attitudes, their processes, and their use of timekeeping as a control mechanism. They make timekeeping into something that can hurt their team, ignoring the potential it has to help the team.
Whether you’re a developer who sees timekeeping as a burden, or a manager who needs to stop being toxic about timekeeping, there are ways to use timekeeping to make your team better — but only after you ditch the toxic processes.
For a long time, timekeeping has been referred to as “punching the clock.”
If you’re thinking that sounds like a violent, negative phrase, you’re right. And those connotations pretty much match up with how a lot of developers feel about timekeeping as a practice.
So why even bother with timekeeping?
Because tracking time gives you valuable data.
No, we’re not talking about tracking time to determine how productive your team members are. That’s not what time tracking is for.
Timekeeping — and the time data that builds up as you track time consistently — offers a number of very useful personal metrics. It can help team members determine their average pace, which makes them better at estimating the time it will take to finish future projects. That, in turn, makes your team less likely to miss deadlines because of unrealistic scoping. That’s something any software team should strive for.
And on an individual level, timekeeping can help developers set, track, and maintain goals for their own growth and improvement. Think of time tracking like fitness tracking — it’s there to help individual developers assess themselves.
Unfortunately, that’s not how organizations typically look at time tracking, which is why so many developers see it as a toxic practice.
There are a lot of reasons developers struggle to see the value in timekeeping.
In a lot of organizations, timekeeping is a way for managers to make sure their teams are working enough hours, working on the right projects, working quickly enough, etc. This kind of timekeeping often leads to quotas at work. It’s a practice that robs individual developers and teams of their autonomy, which kills morale.
And that is what’s toxic. Managers use timekeeping to control their employees, creating a work environment no developer wants to be a part of. It’s like if your manager told you, “I trust you — but I’m going to watch you work anyway, just in case.” What kind of work environment is that?
Plus, this attitude around timekeeping makes it feel like a huge waste of time. Why should developers want to add extra steps to their day to log their time if this is how that data is going to be used?
If your developers and teams think timekeeping is toxic, then this is the systemic issue that needs to be addressed. Change needs to come from the top down, which means changing the way management uses time data and frames timekeeping for the team.
The key to reframing timekeeping to your team is showing them what a valuable process it can actually be. But that change needs to start with managers to truly remove the toxic parts of the process.
Do you want to really make changes to the way your organization thinks about timekeeping — and quickly?
Then remove managers from the equation entirely.
Allow team members to track their own time for themselves and themselves only. No management reviewing or approving time cards. No entering time into a system that managers have access to. Put your money where your mouth is and truly make time tracking into a process that exists within your organization so that individuals can assess and improve themselves.
If managers aren’t part of the timekeeping process at your organization, then it only makes sense that timekeeping shouldn’t be a mandatory process (unless you’re tracking hours worked on a project to bill clients, but that’s a different story altogether).
Since timekeeping should be used as a tool for individual improvement, leave it up to each individual on your team whether they want to take advantage of it. If they do, that’s great. If they don’t, that’s also OK. And if some weeks or months they want to track their time, but then they want to take a break from tracking, that’s also legitimate.
Since so many developers think timekeeping is a chore and a timesuck, do whatever you can to remove those pain points.
One of the best ways to make time tracking simple and seamless is by implementing a tool that’s designed to make it simple and seamless, like 7pace Timetracker, which integrates seamlessly with Azure DevOps tools (and soon, Github) to track time by work item or issue — all in the background, freeing up developers to do what they do best. It just does its job and stays out of the way so you can do yours.
The last step is to give your team members the knowledge and tools they need to use their historical time data for their own improvement and mastery. If they know how to glean insights from time data that can make them better at their jobs, timekeeping will have shifted from a tool for toxic managers, to a value-adding tool that makes software teams better.
It’s not easy to undo the conditioning that’s led us to believe timekeeping is toxic. But it can be done, as long as you realize where the toxicity actually comes from — the top of the organization — and dismantle that first.
No spam, no B.S.
Unsubscribe if you’re not happy.