Make work easier before making it faster

A team can become faster at every task and still take longer to finish a job. Faster intake may send more incomplete requests to an already overloaded reviewer. The local improvement is real; so is the larger queue it creates.

Efficiency is useful when it reduces the effort and delay required for a complete result. The unit of analysis matters. A screen, a department and the whole customer journey can tell very different stories about the same change.

Count the time nobody is working

An approval may require five minutes of attention and wait four days to receive it. Improving the approval screen cannot recover most of that delay. The opportunity may lie in clearer authority, better preparation or a different review schedule.

This is also why keeping everyone continuously occupied can be a poor operating target. If every available minute is already committed, an urgent correction has nowhere to go except ahead of something else. Some spare capacity can make the overall service more responsive even when it looks inefficient on an individual calendar.

Follow a finished job across the waiting as well as the activity. Then distinguish the delays technology can remove from decisions the organization needs to make. The appropriate intervention becomes easier to see once “busy” and “useful work completed” are measured separately.

Find the avoidable effort

Useful candidates include copying information between tools, searching for the latest version, asking for information that was already supplied and correcting the same class of error. Each suggests a different intervention. Shared records may solve copying; a clear owner may solve waiting; better input validation may prevent rework.

Google’s SRE handbook discusses repetitive operational work in its chapter on eliminating toil. The business application is to examine recurring work closely before deciding what should be automated. Some of it should disappear from the process altogether.

For example, imagine a service company manually preparing a weekly status email because customers cannot see their job’s progress. Automating the email could be useful. It is also worth asking whether a simple status page would answer the question earlier and reduce follow-up calls. The choice depends on what customers need and whether the underlying status is trustworthy.

Protect the whole process

An improvement for one person can create work for someone else. A shorter intake form may increase clarification calls. Automatically accepting every request may overwhelm the scheduling team. Review the complete path before declaring a saving.

Compare a small sample before and after the change. Look at completion time, error frequency and the effort needed to handle exceptions. Keep the sample conditions reasonably comparable. A quiet week and a peak week do not tell the same story.

Give the saved capacity a purpose

Time saved is useful capacity, but it does not automatically become cash savings. Small fragments of time may make work less frustrating without reducing staffing costs. A larger uninterrupted block might allow someone to serve more customers or remove a recurring backlog.

Agree on that purpose before investing. If the aim is quicker service, measure waiting time. If the aim is fewer corrections, measure rework. Measure value explains how to connect a technical improvement to a result the business can recognize.

Start with one recurring source of friction and a modest intervention. A cleaner process often makes later automation cheaper because there is less confusion for the software to reproduce.

Use AI to return attention

Preparing a first draft, finding the relevant passage or investigating an unfamiliar part of a codebase can take substantial attention. AI can reduce that effort when the person using it has enough context to judge the result. The useful measure is whether the whole task becomes easier to finish correctly.

DORA’s research on AI-assisted development is a useful reference for technology teams. It directs attention to the surrounding delivery system as well as the tool. Track accepted work, rework and interruptions before assuming that faster generation has returned capacity.