The Tasks That Take Three Weeks Are Never the Hard Ones

The complaint

A six-person agency team, mostly client work, two or three projects running at any time. The founder's complaint was about variance rather than speed: "some things take two days and some things take a month, and I can never tell which in advance."

That is a worse problem than being slow. A slow team that is predictable can still make commitments. This team could not quote a delivery date without either padding it absurdly or being wrong.

The working theory was complexity. Some work is genuinely harder, hard work takes longer, and estimating difficulty is famously unreliable. Everyone agreed, because it is obviously true.

What the outliers said

They took the twelve slowest items of the previous six months, everything above three weeks, and wrote down what each one had actually been waiting for.

Nine of the twelve had been waiting on a client. Copy that had not arrived, a logo in the wrong format, an approval on a design, access to a staging environment, a decision about a payment provider.

Two had been waiting on an internal decision that needed the founder, who had been travelling.

One was genuinely technically hard.

The reframe

The long tail of their delivery time was not made of difficult work. It was made of ordinary work that had been started before it was ready to be finished.

This is the part that reframes the variance problem. If slow items were slow because they were hard, the fix would be better estimation, and better estimation is famously not available. If slow items are slow because they were started prematurely, the fix is a policy about when to start, which is entirely within your control.

It also explains why the variance felt unpredictable. Technical difficulty is at least partly visible up front. Whether a client will answer an email in two days or three weeks is not visible at all, and it has nothing to do with the work.

Why this shape is so common

Starting an item before its dependency is resolved feels productive and is the default behaviour of every team, for a reason worth naming: starting is the only action always available to you. Chasing a client is uncomfortable, waiting looks like idleness, and there is always something you could technically begin.

So the item gets started, gets eighty percent finished, and then sits. It occupies a slot of work in progress, it accrues age, it needs to be re-explained to its author every time they return to it, and none of that shows up as a problem anywhere. The team is busy. The board looks active.

And because a partially finished item is psychologically closer to done than an unstarted one, it keeps its position in everyone's mental model of the project long after it has stopped moving. See aging work in progress.

What to change on Monday

One question before anything is started: is there anything we need from someone outside this team to finish this?

If yes, do not start it. Ask for the thing, and pick up something else. The item stays in the backlog, where waiting is free, rather than in progress, where waiting is expensive.

That is the entire intervention. It is not a process, it is one question, and it fits inside whatever you already do when you pick up work. The agency above added it to their weekly review and their 85th percentile cycle time dropped by more than half over two months. Their median barely moved, which is exactly right: they had never had a median problem.

The second-order effect is the useful one. Asking the question forces you to chase the client before the work is blocked rather than after, which is both earlier and a much easier conversation to have.

The metric to watch

Your 85th percentile cycle time, not your average. The average hides this completely, because nine slow items among two hundred barely move it while dominating your ability to make a promise. See cycle time scatterplots.

Then do the exercise itself, which takes twenty minutes and is worth more than the metric: list your slowest twelve items and write down what each was waiting for. Almost every team finds one category accounts for most of them, and it is almost never difficulty.