June 1, 2017
Counterpoint to “tracking hours is not required”
Tech leadership guru Marcus Blankenship wrote in with a thoughtful counterpoint to my message about abandoning time sheets in a firm or agency that employs dev teams.
Marcus agreed that timesheets aren’t useful for tracking profitability, but pointed out that there are other potential benefits from an employee growth standpoint. Looking back on my time managing dev teams, I tend to agree with his point.
Here’s the thread:
MB:
I believe tracking hours is just a good discipline, even if you are value pricing, working in Enterprise IT, or working by yourself. Knowing how we spent our time is always surprisingly beneficial. :)
JS:
How so?
MB:
Timesheets are a great tool to have an in-depth 1:1 discussions with a developer about...
- What problems they had that week
- What unexpected intrusions distracted them
- What training items they are excited about
- How their estimates line up with reality
- Where they paired with other team members, or consulted on other projects
It’s not about money. It’s about seeing what was really important last week, and having a meaningful discussion about it. This peek into their world helps me see many pressures, constraints, distractions and training opportunities that I’d never get from just asking, “How was your week?”
Just my $0.02
JS:
Interesting. Would a simple list of their week’s activities suffice or do you also need to have the time durations?
MB:
A list of weekly activities is a “status report”, which are full of lies. It’s the time duration that’s the magic.
For example, if someone spends 12 hours on a feature slated for four hours, you’ve learned something new. You can have an interesting discussion which might reveal that the feature was more complex than you through, or had incorrect requirements, or the client changed the requirement in the middle, or your dev needs some additional training opportunities.
But if all you see is “Worked on Feature X”, you miss all that.
JS:
Roger that.
MB:
Beware: Timesheets have a long and checkered past with employees and are generally hated by developers. Due to decades of bad managers they smell like “micromanagement”.
If folks want to introduce them, they should be presented as a valuable engineering discipline which helps the team improve. If you’re going to ask your developers to do them, you’d better lead by example and do them yourself. When it’s done this way, I got very little push-back from my developers.
Thanks Marcus!
For the agency owners in the room:
What do you think?
Yours,
—J