sthreelabs · Notes · Most of the wait isn't work
Note · AI Most of the wait isn't work
Published 2 min read
In shortIn a 1990 Harvard Business Review article, Michael Hammer quoted an insurer's own estimate: a new application spent 22 days in process but was actually worked on for 17 minutes. The rest was waiting between desks. Most back offices still run this way. The fix is fewer handoffs, not a faster screen.
i.The 22 days
In a 1990 Harvard Business Review article, Michael Hammer quoted an insurer's own estimate: a new application spent 22 days in process, but was actually worked on for just 17 minutes. Everything a person did to it, added up, came to 17 minutes.
- Elapsed
- 22 daysin process, one insurer's estimate
- Worked on
- 17 mineverything people did to it
- Waiting
- 21 d 23 h 43 mbetween one desk and the next
The other 21 days, 23 hours and 43 minutes weren't work. They were the application waiting for the next person to get to it. At Mutual Benefit Life, the insurer Hammer described in the same article, most of the time went to passing information from one department to the next. Nobody involved was slow. The process was built out of handoffs, and every handoff came with a wait.
Hammer's advice was in his title: don't automate, obliterate. Ask why there are so many handoffs in the first place, instead of making each one faster. Speed up a bad process and you only get to the wrong answer sooner.
ii.It's still 1990 in a lot of back offices
Walk into almost any small or mid-sized business today and you'll find a smaller version of the same thing. A customer order that "takes a few days" because it passes through an inbox, then a spreadsheet, then a different system, then an inbox again. An invoice that sits for a week because someone has to retype it before it can go anywhere. None of that is really work. It's waiting, dressed up as work. It's also the first place we look.
iii.What we build instead
When we take on a project, the first question isn't "how do we make this screen faster." It's: where is the actual 17 minutes in this process, and what is everything else doing there?
Sometimes the answer is an integration that moves information straight from one system to another, the way we built live contract pricing into a distributor's ERP so a quote doesn't wait on someone checking three spreadsheets. Sometimes it's a small piece of software that reads a document and keys it in, instead of a person doing it by hand. Sometimes it's just removing a step that stayed in place because nobody had gotten around to taking it out.
The lesson from 1990 still holds. The fix is rarely a faster interface on the wait. It's finding the 17 minutes and building the business around that instead.
Running on a process like this? Tell us about it at [email protected]. We reply within 1 business day.
iv.Sources
- Michael Hammer, "Reengineering Work: Don't Automate, Obliterate," Harvard Business Review, July–August 1990.