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 us into a meeting. Pour over our time entries line by line and pick apart how we spent our week.
For added flavor, go ahead and tell us how much time you think we should have spent on those tasks—it’s sure to liven us up!
Aka, take a tool that can help us make estimations, learn about our work, and plan better and use it as a tool to spy on us. We love that.
Dear managers, 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 a team for using “too much time” on a particular task.
What managers are communicating here is clear: They don’t trust your team.
If they trusted them, then thy 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: Does your manager trust your team?
If they 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.
TDLR;
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 much bigger problem.
This is a no-nonsense excerpt from here.
Top comments (0)