The log, and why the task you use most pays least

Twenty seconds a use

Everything in this course came out of four columns on a shared sheet:

1. What the task was.
2. How long it would have taken by hand — estimated before handing it over, never after.
3. Minutes spent: input, wait, check, repair.
4. What the checking found.

That is about twenty seconds a use. Marasem ran it for six weeks, then stopped keeping it in that detail, because by then the desk knew which tasks were which. The log is a diagnostic instrument, not a permanent overhead.

The second column has to be filled in before. That is the only rule of the four that anybody broke. An estimate made after seeing the output is an estimate of how long the output would have taken to type. That is a different quantity, and it is always smaller.

The ranking

The rank correlation between the two orderings is 0.24.

The row

The single most-used task on the log — 60 of 214 uses, more than a quarter of everything the desk handed over — is the one that lost the most: −150.0 minutes.

And the task that produced 754.0 of the desk's 1,422.5 net minutes, 53.0% of the entire six-week saving, was used 26 times, ranking third.

That is not bad judgement by four experienced people. It is structural, and once you see the mechanism you can predict it on any desk.

Why the small tasks win the usage race

A task you can describe in a sentence is usually a task you can do in two minutes. Rename these columns. Turn this into a sentence. Convert these dates. The cost of thinking of handing something over is almost exactly the cost of describing it. So the tasks that occur to you are the ones that are cheapest to describe, and those are the ones sitting under lesson 1's 4.1-minute floor.

The task that produced half the saving sits at the other end of exactly the same effect. Read this sixty-eight-page manual and tell me where the carton-marking rules are did not occur to anyone at Marasem for a fortnight, because reading the manual does not feel like a task. It feels like the job. Nobody hands over the job. Everybody hands over the fiddly bit at the edge of the job, and the fiddly bit is small by definition.

There is a second effect underneath, and it is arithmetic rather than psychology. Small tasks recur. Large ones do not. A two-minute reformatting job happens sixty times in six weeks because there are sixty of them. A manual gets read when a manual needs reading. So the small task wins the usage count on frequency alone, and frequency is what everybody's impression of usefulness is built from.

The monthly review, in four moves

Rank by minutes saved, never by uses. The two orderings disagree, and only one of them is money.

Retire anything negative, and retire it properly. Not "be more careful with it". Off the list. Marasem retired two tasks on this table, and stopped a third before it became one.

Look for the task nobody thought of. Take the three longest recurring jobs on the desk. They are the ones measured in tens of minutes, the ones that feel like the job rather than like a task. Ask what a checkable version of each would look like. That is where the next task with a rank-one saving is.

Re-estimate the floor once. The floor moves as a desk gets better at writing inputs and worse at bothering to check them. Marasem's was 4.1 minutes in the first fortnight. Anything below it stays off the list, however easy it is to ask for.

Act as an operations analyst who is sceptical of tools and interested only in measured time. I want one task scored honestly, not recommended. The task: [DESCRIBE IT IN ONE SENTENCE, AS YOUR DESK ACTUALLY DOES IT]. My own measurements: it takes me [MINUTES] by hand; preparing the input takes [MINUTES]; waiting takes [MINUTES]; checking the output to the standard this task needs takes [MINUTES]; repairing what checking finds takes [MINUTES]. My loaded cost is [AMOUNT] an hour. I ran it [NUMBER] times in [WEEKS] weeks. Do the following. First, compute the net saving a use and over the period, in minutes and in money, and say plainly whether the number is positive. Second, compute the check ratio, which is checking plus repair divided by manual time. Then compute the ratio it had to stay under, which is one minus preparing plus waiting divided by manual time. Say whether it clears it, and by how much. Third, classify the output: checkable against a source I hold, checkable only against my own judgement, checkable only by doing the task again, or not checkable in the time available. Justify the class from what would have to happen for me to disbelieve the answer, not from how hard the task is. Fourth, if the class is the third or fourth, say so and recommend retiring the task, and do not soften it. Fifth, if it is the first or second, name the single change to my input that would most reduce the CHECKING time, and estimate by how many minutes. Sixth, list every error this task could produce that my described check would not catch, and for each one name what it would cost if it left the building. Do not estimate any figure I have not given you: write MISSING instead.