Before you automate anything,
find out where the hours actually go.

In the summer of 1990, Michael Hammer put a small aside in parentheses in his Harvard Business Review article “Reengineering Work: Don’t Automate, Obliterate.” An insurer had estimated that while an application spent 22 days in process, somebody actually worked on it for 17 minutes. Everything else was waiting, passing and checking.

I think about that ratio every time a leadership team shows me its AI shortlist. The list is almost always built from the visible work: the drafting, the data entry, the report someone spends Friday afternoon on. Those tasks are real and they are easy to demo. They are rarely where the hours go. Before we automate anything, we find out where the time actually sits, and most of the time it sits somewhere the shortlist never mentions.

17min

Hands-on work in an insurance application that spent 22 days in process, per HBR, 1990.

57%

Share of the average employee’s time spent in meetings, email and chat, per Microsoft, 2023.

900k

Distinct paths one multinational’s order-to-cash process took in a single year, per Wil van der Aalst, 2020.

41%

Share of startup-to-task mappings that land on tasks workers don’t want automated, per Stanford, 2025.

The hours hide between the steps

Hammer’s main case in that article was Mutual Benefit Life, then the eighteenth largest life carrier in the US. An application could pass through as many as 30 discrete steps, across 5 departments and 19 people. Typical turnaround ran from 5 to 25 days, “most of the time spent passing information from one department to the next.” Nobody inside any single department would have described their own step as slow. The delay lived in the handoffs, and handoffs belong to no one.

The fix was a new job. MBL created a case manager who owned an application from receipt to issued policy, with specialists on call as advisers. Turnaround dropped to two to five days, 100 field office positions went away, and case managers handled more than twice the volume the old process could. The same article mentions an East Coast insurer whose regional offices sent a series of reports to the home office for years. Nobody in the field knew they were simply filed and never read.

The title of the article is the instruction. Hammer argued that companies kept using computers to speed up processes designed before computers existed, and that the gains stayed small because the process itself was the problem. Ford’s accounts payable redesign, which I walked through in an earlier note, came from the same piece. Swap “computers” for “agents” and the argument needs no other edits.

Most of the day goes to work about the work

Thirty-five years later the waiting has moved into inboxes and calendars. Microsoft’s 2023 Work Trend Index, based on Microsoft 365 activity data, found the average employee spends 57% of their time communicating in meetings, email and chat, and 43% creating in documents, spreadsheets and presentations. In the same report, 62% said they spend too much time searching for information.

The June 2025 edition, Breaking down the infinite workday, got more granular. The average worker receives 117 emails and 153 Teams messages a day, and is interrupted by a meeting, email or notification every two minutes during core hours, about 275 times a day. Microsoft found that 57% of meetings were ad hoc calls with no calendar invite, which means they never show up in anyone’s picture of the week.

Asana’s Anatomy of Work Index 2021, a survey of over 13,000 knowledge workers in seven countries, put a name on this: “work about work.” Respondents said they spend 60% of their day on it, meaning chasing status, searching for information, switching between apps and sitting in meetings about the work, and only the rest on the skilled job they were hired for. Unnecessary meetings alone cost each of them 157 hours in the past year.

These are vendor studies, and the Asana figures are self-reported, so I hold the exact percentages loosely. The direction matters more. When a COO pictures where the order desk spends its time, the picture is of people doing orders. The data says that more than half the day goes to the coordination around the orders, and none of that coordination appears on a process chart.

The documented process covers a minority of real cases

Process mining makes this visible with system data instead of surveys. The software reads timestamps from an ERP or ticketing system and reconstructs every path a case actually took. Wil van der Aalst, the RWTH Aachen professor who built the first process mining techniques, describes in a 2020 paper on shared services the order-to-cash process of a large multinational: about 30 million cases a year, over 60 possible activities, and more than 900,000 distinct process variants in a single year. The most common variant occurred over 3 million times, roughly one case in ten.

His summary is that a small share of variants explains most cases, while the remaining 20% of cases account for 80% of the variants. Many of those rare paths “involve rework, passing the buck (leaving a difficult problem for someone else to deal with), communication errors, and repair actions.” He calls most deviations from the happy path operational friction.

That has a direct consequence for AI. An agent built on the process as documented will handle the happy path well. The happy path is also the part that already runs fastest. The exceptions, where the hours pile up and customers wait, are exactly the cases the documentation leaves out.

AI does best on short, checkable tasks

The newest benchmarks measure AI at the level of a task, which is the level a work map needs. OpenAI’s GDPval, published in October 2025, built 1,320 tasks from the actual work product of professionals in 44 occupations, people with an average of 14 years of experience. The tasks took an expert about 7 hours on average. On the public subset, expert graders rated 47.6% of Claude Opus 4.1’s deliverables as better than or as good as the human one. Win rates were highest for tasks of 0 to 2 hours and declined steadily as tasks got longer.

Anthropic’s Economic Index report from January 2026 reads real usage instead of a test set. Claude completes tasks that require a college degree 66% of the time, and through the API it reaches 50% success on tasks that would take a person about 3.5 hours. When the authors adjusted their productivity estimate for those failure rates, it fell by about a third. Reliability, more than raw capability, decides how much of an estimated saving survives contact with real work.

Put next to the coordination data, this sharpens the question. Feasibility is a property of a specific task with a specific input and a specific check at the end. Nobody can score “accounts receivable” for feasibility. Someone can score “match a remittance email to open invoices and flag the ones that don’t reconcile.” A map at that resolution is the only thing that lets you put hours and feasibility in the same row.

The guess from the top usually misses

The clearest evidence that leaders guess wrong comes from a Stanford team led by Yijia Shao and Diyi Yang, with Erik Brynjolfsson, in Future of Work with AI Agents. They asked 1,500 workers across 104 occupations about 844 of their own tasks, and had AI experts rate what agents could do on each. Workers were positive about automation for 46.1% of tasks, mostly to free time for higher-value work. Then the team mapped Y Combinator startups to the same tasks: 41.0% of those mappings landed on tasks where workers did not want automation, whether or not the technology could do them.

The ten occupations where workers most wanted automation accounted for only 1.26% of Claude.ai usage in the period they compared. Startup investment clustered around software development and business analysis, and many of the tasks workers wanted help with, and that agents could already do, were left largely unaddressed. That is the same error at market scale that I see inside single companies, where the AI roadmap is written by the people furthest from the work.

A two-week work map

This is the method we use. It costs two weeks and one person who can run interviews and a spreadsheet.

Scope one value stream. Pick a flow with a clear start and end that crosses at least two teams: quote to order, order to cash, month-end close, claims intake, hire to first day. Twenty to eighty people is the right size. Name an owner who can change the process afterwards.

Interview eight to twelve people in days one to three. Two front-line people from each role that touches the flow, the person everyone sends the strange cases to, the team that receives the output downstream, and whoever administers the main system. Managers come last, so their picture does not anchor the others. Ask each person to walk through the last three cases they handled, in order, with the screens open. Real recent cases surface the workarounds that a description of a typical day leaves out.

Log time for five working days, days three to eight. Everyone in scope fills a simple sheet in 30-minute blocks, with one task name per block and one of four labels: core work, coordination (meetings, email and chat about the work), waiting or chasing, and rework or exceptions. Five days is enough to catch a weekly cycle and short enough that people keep filling it in. In parallel, pull 90 days of timestamps from the ERP, CRM or ticketing system and calculate, per case, elapsed time against touch time. You do not need process mining software for a first pass. A count of how many cases followed the standard sequence will do.

Score every task in days nine and ten. Build one table with a row per task and four columns that matter. Hours per week across the team, from the logs. A feasibility score from 0 to 3, one point each for: the inputs are digital and reachable, the output can be checked by a person in minutes, and the task fits in under two hours of expert work or splits into pieces that do. A worker-preference flag from the interviews, following the Stanford finding. And Hammer’s question, asked of every row before any other: does this task need to exist at all?

Rank and decide. Tasks that should not exist go on a separate list and get removed first, because deleting a report nobody reads beats automating it. Everything else is ranked by hours times feasibility. Our decision rule is simple: in this round, only the top three rows get an AI build, each with a baseline from the logs and an owner. A task that scores well on feasibility but sits low on hours waits, however good the demo looks.

The first output is usually uncomfortable. The top of the hours column is coordination and exceptions, and some of the biggest fixes are a decision right, a shared field in the ERP or a meeting that stops. Those ship in week three, before any agent.

If you run operations, pick the value stream this week, name its owner, and send the time-log sheet with a start date. Book the interviews with front-line staff before the managers. In two weeks you will have a ranked list with hours attached, and that list is what the AI budget should be approved against.