The most frustrating thing about time tracking in the nerdosphere is that we aren’t allowed to fix it. I mean really, given our propensity for measuring this or that, you’d think we could be trusted with it, but it is a thing, even in the supposedly geek friendliest of shops, not so much done for us or by us but to us. It is a thing imposed, by faceless agents of “the business”, whose concerns and decrees are beyond our meager comprehension.
If I ever stumble into a parallel dimension where I can, as an individual contributor, affect time tracking process, here are a few observations I might make, and one large suggestion based on those observations:
There is a cognitive dissonance between the usually stated justification for time tracking and the way it’s carried out in practice.
At most shops, the need for time tracking is driven by management’s simple desire to understand how much labor went into undertaking this or that project. It’s important to know that it doesn’t cost you more to build a thing than you make when you sell it. This is not only the sort of thing I imagine you might pick up in business school, but also a valid point.
Why is it then, that when we undertake time tracking, we ask the question: How many hours did Steve work this week? When we should be asking the question: How many hours did Ops contribute to Project X?
Are we paying Steve by the hour or something? (probably not if he’s an op). Why do we care about Steve at all if our goal is to find out how much project X cost? We might care about what Steve’s time is worth, but we aren’t asking that question either. So is there a second, unstated goal? The goal of finding out how individually productive each employee is? Because that’s a very different sort of problem, bringing me to:
Your employees wont report their own lack of productivity to you (no matter how intimidating you are when you demand it of them).
If you don’t hire programmers and ops guys that are idiots, you can pretty safely assume that they know where this is going. Many of them have even seen it before. Maybe you honestly don’t, so I’ll lay it out for you: When Ted reports 40 hours and Steve 10, your bean-counter genes will force you to go back to Steve and smack him for his lack of productivity. And when you do that, you’ll be ignoring a few pretty typical details in the process:
*Steve got more done in his 10 hours than Ted will all week
*Ted loves time tracking because it makes him look productive
*Technical Aptitude is inversely proportional to bullshit paperwork aptitude
*The kind of employee who will give an honest answer is the one you’re most likely to punish.
Of course, Steve saw you coming the moment you mentioned time tracking in the first place. He just wanted to see what you were going to do when he gave you good data, and you did pretty much what he expected. You punished him for it. Which leads me to:
If you want good data, you shouldn’t encourage lying.
Tracking employee time on an hourly basis begets garbage data. If you track per employee, you’ll inevitably make invalid assumptions about when and how they’re working, and compare them against each other based on irrelevant metrics like total hours per week. They aren’t going to come to you to explain why they work differently than other people, why would they think you care? They are going to lie to you, and you are going to thank them for it.
Even if you know this going in, and attempt to account for it, it will happen. Somewhere in the chain, some middle manager will see those numbers, and in him they will trigger that finely honed survival instinct to cover his ass, and he will; ruining your data in the process. It will happen this way until we cease to be human, because it is a human problem, which brings me to:
A tool isn’t going to fix it.
Buying a fancier, web-based spreadsheet isn’t going to help. You’ll just have to trust me on that one.
For Ops and Dev, context-switching is expensive. So if you can suck time-tracking data out of their commit comments, or put an API out there to which they can code their own interfaces, or have them check out blocks of time, or charge them for it via a cost-center, or put physical buttons on their desks with project names on them, that’s great. Make the process as lightweight integrated, and clever as you can, but understand that the lying won’t stop until you clue in and stop incentivizing it.
If you try to fix it with clever tools, the lying will only get more creative. If you put up an API, they’ll write random number generators to it, if you put in a cost center, they’ll rob Peter to pay Paul, if you put buttons on their desks, they’ll hack together random number generators with pneumatic actuators. But they won’t give you real data because you’re not asking for real data. You’re asking for pretty numbers, and they’re perfectly happy to oblige you.
Anonymity gives you what you want: Good data.
Tossing out the employee name is the cheapest way to solve all time tracking problems. Your employees will give you the best possible data and you will know how much it costs to build a thing. You won’t be tempted to bludgeon them, and they won’t need to lie to you. If you want to measure their productivity, stop being silly about it. Instead, set real, measurable, goals for them and let them accomplish those goals by employing their time in whatever way they need. They want to be happy and productive. They want to build things. Give them a way to throw hours at a project anonymously, or better yet, let them build it for you, and live happily ever after.