Image 01


beyond the Kuiper Belt, over the sea

Double-Entry Timekeeping

May 16th, 2015 by Kit

I can credit Ben Warren with the phrase, and the particular expression of the idea.

Like double-entry bookkeeping, you don’t just track one value, you track in and out from each account separately. In particular, you track the time you’ve allocated to tasks, and you track the time you’ve spent on tasks.

One thing I’ve noticed in some organizations is a reluctance among those who do-the-work (as opposed to manage-the-work, and yes, I know this is an unfair division, but I trust you know what I mean) to allow visibility into the second part. How time actually gets spent.

I think that this is often motivated by a reluctance to risk blame: if we make it clear how time was spent, “waste” will become visible and blame will be apportioned. But doing so costs us some very valuable information. If we can’t see how we actually spend time, we can’t figure out where the actual waste lies and remove it.

(An aside about waste: in knowledge work especially, time spent apparently not working is not the same as waste. There’s value in long-term sustainability and value in surprise solutions to be had by allowing people some space to muse. You can’t just sit and churn out code if you want that code to be full of good decisions. You need to pause, ponder, learn, as well. So when I talk about “waste”, I really mean priority-shifting, interruptions, vapid features, and things like that.)

But blame is almost always very wrong to ascribe anyway. It is a truth (very nearly) universally acknowledged that complex systems do not fail because of a single cause. System accidents are the norm, and result from many pieces interacting to produce an undesired effect. A complex system can typically handle a handful of failures, because each section of the system gets designed with the local failures in mind, but the interaction of those failures can cascade and cause larger effects that the system cannot tolerate. If you think that either your system or your organization are not complex systems, you are probably wrong. So, usually, if something goes wrong, it is not the fault of one person. It is usually more accurate to ascribe the fault to the modes of interaction and the ways that failures are handled by components of the code or the organization.