← All posts

Why nobody in your company knows how long anything takes

Nobody in a growing company knows how long its work takes because every number in circulation is an estimate, and estimates of time go wrong in predictable directions. People remember past jobs as shorter than they were, plan from the job in front of them rather than from history, and explain each overrun as a one-off. The waiting between people belongs to nobody, so nobody counts it. Only a count closes the gap.

Illustration: two tiles joined by a line, a chat bubble and a clock, with a clock highlighted in olive.

Why is every number about time in your company a guess?

In a study published in 1994, psychologists asked 37 honors students at the University of Waterloo, in the final semester of their thesis course, when they would hand the thesis in. Their best estimates averaged 33.9 days. The ones who finished took 55.5 days on average. Fewer than a third, 29.7%, finished within the time they had called their most accurate prediction. These were people working on a project that mattered to them, with every reason to get the date right.

Now ask your operations manager how long month-end close takes, or how long an order sits between the Viber message and the signed delivery receipt. You will get an answer quickly, and it will be a round number: three days, about a week, half a day. Nobody looked anything up. Nobody could have, because nobody wrote the start and the finish down.

That is the measurement gap. Everyone in the business estimates, and nobody counts. It is not carelessness, and it does not close by itself. Three of its causes are documented in research on how people judge time: memory shortens past jobs, plans ignore history, and overruns get explained away. The fourth is plain to anyone who has followed one order through a warehouse: the waiting between people is owned by no one.

The counting method itself is set out in the Hidden Hours Audit. This post is about why the gap exists in the first place, and why it survives every meeting that complains about it.

How badly do people misjudge the time their own work takes?

Badly, and in a consistent direction rather than at random. In the Waterloo study, students missed their best estimates by about three weeks on average. Asked for a forecast that assumed everything went as poorly as it possibly could, fewer than half, 48.7%, finished by that worst-case date. For just over half of them, the worst case was still too hopeful.

The pattern is not limited to students writing theses. A 2012 paper by Michael Roy, Nicholas Christenfeld and Meghan Jones starts from the observation that people are often wrong about how long tasks took in the past as well as how long they will take in the future, and that the usual error is to underestimate. There is an exception worth knowing: when a task is very short or unfamiliar, the error tends to run the other way, toward overestimating.

Reports of time already spent fare no better. A pre-registered meta-analysis by Douglas Parry and colleagues, published in Nature Human Behaviour in 2021, pooled 106 effect sizes comparing what people said about their own digital media use with what their devices logged. Self-reports correlated only moderately with the logs and were rarely an accurate reflection of them. That is screen time, not warehouse time. It is also something people do every day, and they still could not say how much of it they did.

Everyone misjudges time in the same predictable ways, so finding a better estimator will not fix it. Asking more people does not average the error out when all of them lean in the same direction.

Why do past jobs feel shorter than they were?

Because the number you are given is a memory, and memory of duration is biased. When people recall how long a finished task took, they often remember finishing sooner than they did. One explanation, which Roy and his colleagues call the memory bias account, holds that biased forecasts are caused by biased memories: the forecast is built on a remembered past that was already too short.

In a business this matters more than in a laboratory, because there is usually nothing else to consult. When a branch manager says a stock transfer takes a day, they are not reading a log. They are remembering the last few transfers. If the research holds, the memory is shorter than the transfers were.

The bias also feeds itself. Today's remembered duration becomes tomorrow's plan, the plan becomes what everyone expects, and the next overrun is measured against an expectation that was short from the start. The record that would correct the memory does not exist, so the memory wins by default.

This is why asking people is the wrong instrument for measuring time. The answer comes from memory, and memory of duration is where the bias sits.

Why do plans ignore what happened last time?

Because people plan forward from the job in front of them rather than back from the jobs behind them. When Roger Buehler, Dale Griffin and Michael Ross asked students to think aloud while predicting, about three-quarters of what they said concerned future scenarios for the task. Fewer than one in ten of their remarks drew on relevant past experience.

The name for this is the planning fallacy. In their 1994 paper, Buehler and his co-authors credit the term to Daniel Kahneman and Amos Tversky in 1979, and describe it as a confident belief that your own project will go as planned, held even while knowing that most similar projects have run late.

What makes it stubborn is that people do not believe, in general, that work goes to plan. The same paper describes the planning fallacy as the combination of fairly pessimistic general beliefs with optimistic specific predictions. Ask your team whether deliveries usually run late and they will say yes. Ask how long tomorrow's delivery will take and they will give you the plan.

The bias can be removed. In one of the studies, students who were told to connect relevant past experiences to their prediction before making it lost the optimistic bias entirely. The catch, for a business, is that you cannot connect a forecast to past jobs that were never recorded. The cure for the planning fallacy is a record of past jobs, and a company that runs on paper, spreadsheets and Viber usually does not have one.

Why does nobody learn from the last overrun?

Because every overrun arrives with its own explanation. In two of the studies in the same 1994 paper, people put their past prediction failures down to causes that were external, temporary and specific to that occasion. Explained that way, a late finish says nothing about the next job. So it never changes the next forecast, and the same estimate is given again with the same confidence.

Picture month-end close. One month it runs late because the bank statement arrives late. The next month a branch sends its sales report on a Monday instead of a Friday. The month after that, the person who reconciles the accounts is on leave. Every month has a reason, and every reason is a genuine one-off. Counted together, the one-offs are the normal month.

This is also why complaining about late work rarely changes it. The complaint is about one instance, and one instance always has a story. A count of the last six closes has no story. It has a range, and the range is the honest answer to how long close takes.

Who owns the clock when a job passes through five people?

Usually nobody. Each person owns a slice of the work and can say, roughly, how long their part takes. Nobody owns the time between the slices: the order waiting in a Viber thread, the delivery receipt in the driver's bag, the invoice waiting for a signature. That waiting is part of how long the job takes, and it appears in nobody's estimate.

Ask the warehouse how long it takes to pick an order and you will hear the picking time. Ask accounts how long invoicing takes and you will hear the keying time. Add them together and you have a number that leaves out every stretch where the order sat on somebody's desk, which is the part the customer notices.

Even inside one person's slice, the work is rarely done in one sitting. Gloria Mark, Victor Gonzalez and Justin Harris at the University of California, Irvine observed 24 information workers, software developers, financial analysts and managers, over more than 700 hours. In their 2005 study, people spent an average of about 11 minutes on one piece of work, which the authors call a working sphere, before switching or being interrupted, and 57% of those working spheres were interrupted. That was office work, not a bodega. The arithmetic problem is the same: nobody adds the pieces up.

So the honest answer to how long an order takes from first message to cash is not in anyone's head. It can only be read from the dates on the documents the order leaves behind, if anyone dated them.

This is also why the people closest to the work are the wrong ones to blame for not knowing. Their job covers their slice. No job description in the building covers the whole clock. If the founder was the one person who walked the whole job every day, the whole-job clock lived in the founder's head, and it is worth finding out early whether anyone else ever held it. That question belongs early in a second-generation owner's first months.

Would the boss's estimate be any better than the staff's?

Not reliably, and the research suggests it errs the other way. In the fifth study of the same paper, observers predicting someone else's completion time overestimated it, and they made more use of relevant past experience than the people doing the work. A manager guessing how long a job should take and the person guessing how long it will take are likely to disagree, and both can be wrong.

Imagine the meeting this produces. The owner thinks a job should take two hours. The staff say it takes most of the day. The meeting ends with a compromise somewhere in the middle. Two estimates negotiated into a third estimate is still an estimate, and the next meeting starts the same argument again.

For a second-generation owner the stakes are higher. Changing a process on the strength of your own estimate of how long it should take, against the estimate of people who have done it for years, is a contest between two guesses. A count of the last several times the job was done gets you out of the contest. It turns a disagreement about competence into a question about dates, and dates can be checked.

How can you tell an estimate from a count?

Ask where the number came from. A count can be shown: a dated document, a log, a list of the last several jobs with a start and a finish for each. An estimate arrives instantly, comes out round, and describes a typical day rather than a particular one. Run any number about time you are given through the checks below before you plan, staff or price against it.

  • ·It is round. Two hours, three days, about a week. A count of several real jobs comes out as a range, not a round number.
  • ·It came back immediately. Nobody opened a file, a logbook or a chat thread before answering.
  • ·It has no start and no finish. Ask when the clock starts and when it stops. If nobody can say, the number was never measured.
  • ·It describes a usual day. Words like usually, normally and on a good day mean the speaker is describing the case they have in mind, not the record.
  • ·It covers one person's part. The number for picking is not the number for the order.
  • ·Two people give two numbers. If the warehouse and the office disagree about the same job, neither has counted it.
  • ·It cannot be shown. The simplest test of all: can someone put the dates in front of you?

What should you do with the estimates you already have?

Keep them, write them down, and use them to choose what to count first. In the Waterloo thesis study, students who predicted longer did take longer: predicted and actual times were highly correlated even though the predictions ran short. Estimates like these can be useful for ranking jobs while being poor at sizing them. The mistake is to plan, staff or price against one as if it were a measurement.

Here is a check you can run on one job today, using records you already have.

  1. Pick one job that people describe in units of time, such as 'a delivery takes a day' or 'close takes a week'.
  2. Write down the estimate and who gave it, before you check anything. If two people give different numbers, write both down.
  3. Agree in one sentence when the clock starts and when it stops. For an order, that might be from the customer's first message to the signed delivery receipt.
  4. Find the last five times the job was done in records you already keep: dated receipts, invoice dates, chat timestamps, the logbook at the gate. Write down the start and the finish for each.
  5. Put the five durations next to the estimate. Note the shortest, the longest, and how many of the five finished within the estimate.
  6. Keep the sheet. The next time someone plans that job, the five real durations go on the table before the estimate does.

What if the dates do not exist?

Then that is the finding. A job that leaves no dated trail cannot be counted, and a job that cannot be counted will go on being estimated. At that point, fixing how the job is recorded comes before anything else, which is the third option set out in Build, buy, or fix what you have.

One warning about the first count. If it is used to blame whoever gave the estimate, the next estimate will be padded and the next record will be tidied before anyone sees it. The gap between estimate and count comes from how people judge time. It is nobody's fault, and treating it as somebody's fault is the quickest way to stop getting honest numbers.

Does closing the gap mean buying time-tracking software?

Not first. A timer on one person's screen measures that person's slice, and it is blind to the waiting between people. The dated records a job already leaves behind, read across the whole job from first message to cash, can tell you more about elapsed time than any timer can. Software can come later, once the job and its record are fixed.

I would fix and document a process before automating any part of it. Automating a broken process makes it faster, not better, and a timer bolted onto a process nobody has measured only produces faster guesses. Count first. Once you know what the job costs in hours, the decision about tools has a number behind it.

Common questions

Is the planning fallacy a sign that staff are lazy or dishonest?

No. It shows up in people with every reason to be accurate, such as students finishing a thesis that mattered to them, and it combines a realistic belief that work in general runs late with an optimistic forecast for the job at hand. Treating it as a character flaw teaches people to pad their numbers or stop giving them, and neither gets you closer to a count.

Are short jobs underestimated too?

Often not. Research on remembered and predicted durations notes that very short or unfamiliar tasks tend to be overestimated instead. The small jobs that feel endless may be smaller than they feel, and the long ones larger. Either way, a count is the only number that settles it.

Why not ask staff to log their own time for a month?

A time log filled in after the shift is a memory, and memory of duration is biased in the same ways an estimate is. Dates created as the work happens, such as a delivery receipt signed at the gate or the date on an invoice, are much harder to round off. Use those first, and ask people to log time only where no such record exists.

Who should do the counting?

Someone who does not own the estimate being checked, working from records rather than from interviews. The person who does the job should still check the start and finish points, because they know where the record is wrong. The Hidden Hours Audit sets out how to run the count across a whole process in a week.

Sources

If this is the problem you're sitting with, show us the task and we'll audit one workflow for free.

Show us the task

One email, now and then

Where the hours actually go

Every new post, and nothing else. No pitch, no schedule to keep up with, one click to leave.