| The "How Knowledge Work Happens" graphic is really what resonates with me. I run a dev shop and I hate time tracking for the complexity implied in this image. Questions come to mind. What counts for time tracking and what doesn't? If I spend an hour emailing back and forth with a stakeholder, none of this is reflected in my GitHub activity. So there is a delta between what is billable time and the actual deliverable. What if I spend an hour researching a solution for a feature? Or debugging my environment? Again, that implies delta between billable time and the deliverable. What about my level of expertise? I might be a junior or senior level developer; I might have certain specialized knowledge in an area of programming (or lack it). Again, more delta that tracks closely to the specific logistics of a small feature and less with overall "time". Suppose I had a machine that strictly tracked the amount of time I spent "doing something project-related" (whatever the specific rubric). At the end of the day, I now have a number. What does this number actually tell me? I am not sure it is that useful and it definitely depends on however the rubric was defined (which would be inherently arbitrary anyway). To me, it makes sense to just allot hours to devs and trust that they are doing their jobs. When people stop doing their job, peers notice anyway, hour tracking or not. |