Getting people to record ยท 1.1
Why timesheets are left blank
A timesheet asks somebody to reconstruct a fragmented day hours later. The reconstruction is a guess and everybody knows it. For another implementation reference, see this Monitask guide.
The blank cell is not lazinessThe cause
A timesheet asks somebody to reconstruct a fragmented day some hours after it happened. The reconstruction is a guess, the person knows it is a guess, and filling it in feels like producing fiction for somebody else's report.
That is the actual reason the cells are blank, and it explains why reminders, escalation and manager nagging all fail: none of them addresses it.
What the entry moment has to cost
Seconds, at the point of switching, from wherever the work already lives.
The threshold is lower than most people believe. An entry taking thirty seconds is done for the first fortnight and then in batches. One taking four seconds is done, and the difference between four and thirty is the whole adoption question.
Which means the design decisions that matter are about removing steps rather than adding reporting: a default that is usually right, a recent list, and no required field that can be inferred.
Confirm rather than reconstruct
A weekly review where somebody confirms what was already captured is accurate and takes minutes. A weekly session where they reconstruct the week is neither.
The distinction sounds small and it decides whether the data is worth anything, because the error in reconstruction is not random. It flattens toward whatever the person believes they should have been doing.
The first fortnight decides it
Four ways a rollout is lost early
Announced as a control. An email about accountability sets the frame permanently.
Categories imposed. A list assembled by somebody who does not do the work produces entries against whichever option is least wrong.
Nothing comes back. People who see no output conclude it feeds a report about them.
The first correction handled badly. Somebody queried about an entry in week two teaches everybody what the system is for.
What to say when you introduce it
What is recorded, what it is used for, who sees it, and what it will not be used for. Specifically, in a meeting, before deployment rather than after.
The unstated fear is always the same: that this will be used to compare people or to justify a decision about somebody. If it will not be, say so, and then make the product incapable of it rather than relying on the promise.
Everyone sees their own record in the same detail their manager sees it.
There is no ranking view anywhere in the product, which is a design decision rather than a setting.
Who should introduce it
Whoever the team already trusts, not whoever commissioned it. A rollout announced by finance is a finance initiative; the same rollout introduced by a respected supervisor is a change to how the team works.
The five o'clock Friday problem, measured
Ask somebody to account for a week and compare it against what was actually captured. The reconstruction is usually tidier: fewer context switches, longer blocks, less interruption, and the total closer to a round number of hours.
None of that is dishonesty. It is how recall works, and it means reconstructed data systematically understates fragmentation, which is precisely the thing most organisations want to know about.
Where entry should live
In the tool the work is already in: the ticket, the job, the call, the calendar. Every switch to a separate application is a decision point at which somebody decides to do it later.
This is the single largest factor in same-day entry rates and it is a procurement question rather than a training one.
What not to require
A description field on every entry. It doubles the entry cost, it produces text nobody reads, and where it is genuinely needed for billing it should be required on billable entries only.
Two kinds of blank cell
The forgotten one. The person meant to and did not. Fixed by cheaper entry.
The refused one. The person does not want to say where the time went, usually because they expect it to be judged. Not fixed by cheaper entry, and not fixed by escalation either.
Distinguishing them matters because the remedies are opposite. The second is addressed by changing what the data is used for, and the change has to be visible before anybody believes it.
The person who logs eight hours every day
A record showing exactly eight hours, every day, in round blocks, is not a record. It is somebody satisfying a requirement, and it is the commonest form of quiet non-compliance.
It is also a signal worth reading: the person has concluded that accuracy is not what is being asked for. That conclusion came from somewhere.
What good looks like
Entries made the same day, uneven totals, occasional corrections, and a catch-all category with something in it. A record that looks tidy is usually a record that was tidied.
What to do first
Sit with three people and watch them record a day. Not a workshop: watch. Where they hesitate is where the design is wrong, and twenty minutes of observation replaces a quarter of speculation.
The exception worth naming
Some work genuinely cannot be recorded as it happens: a surgeon, a driver, somebody on a ladder. For those the answer is a short structured capture at a natural break rather than a better interface, and pretending otherwise wastes everybody's time.
A closing thought
Every organisation that has solved this solved it by making recording cheaper and by removing whatever made people wary of it. None solved it by asking harder.
Also in getting people to record
Choosing the categories
The list somebody picks in week one governs everything the record can later answer.
Reminders, nudges and escalation
Reminders, nudges and escalation. What decides it, what it costs, and what usually goes wrong.
What a manager should do with it
What a manager should do with it. What decides it, what it costs, and what usually goes wrong.
Running a pilot that answers something
Running a pilot that answers something. What decides it, what it costs, and what usually goes wrong.