the work between the work

most job descriptions name the visible work. researchers investigate. designers design. lawyers advise. operators keep things moving. but a surprising amount of each day is spent on the work between those verbs: finding the latest file, asking for missing context, translating an update for another system, checking whether someone replied, and rebuilding the story behind a decision.

this surrounding layer is easy to dismiss as administration. in practice, it is where a large share of knowledge work slows down.

the transition tax

every transition creates a small tax. information moves from a conversation into a document, from a document into a task, from a task into a review, and from a review into a decision. each move creates a chance for context to be shortened, duplicated, or lost.

the tax is rarely visible in a single dramatic failure. it appears as a hundred small interruptions:

• which version is current?
• what did we decide last time?
• who owns the next step?
• why is this blocked?
• can you send that again?

teams compensate with meetings, status messages, spreadsheets, and individual memory. those patches work, but they also become another layer that has to be maintained.

follow the artifact

a useful way to understand a workflow is to follow its central artifact rather than its org chart. the artifact might be a client request, a research claim, a contract, a design, a support case, or a proposed change.

ask what happens to it from arrival to resolution. which states does it pass through? what evidence accumulates around it? who can change it? what causes it to move? where does its context live at each point?

this exposes the real system. it also makes automation opportunities easier to see.

automate continuity

the obvious automation target is often the visible task: draft the document, summarize the call, classify the request. those features can save time. larger gains appear when the system also preserves continuity around the task.

a summary should know which project it belongs to. a decision should retain the evidence that supported it. a request should carry its history into the next tool. a handoff should arrive with the state of the work, not just a link and a sentence.

this is why connecting tools is not enough. a connection that only moves fields can reproduce the same fragmented workflow at higher speed. the system has to carry meaning forward.

good starting points

look for work with a few recurring signals:

• the same context is copied into several places
• people regularly ask for status that a system could already know
• a handoff depends on one person remembering the backstory
• work waits because the next owner is unclear
• decisions are recorded without the evidence behind them
• the final output exists, but the follow-through is manual

these are not necessarily model problems. they are system problems. the solution may combine software, automation, a model, and a carefully placed human decision.

a better measure

time saved is useful, but it is not the only measure. a better system can also reduce rework, make responsibility clearer, preserve the reasoning behind decisions, and let a new person understand the state of the work without scheduling a meeting.

the goal is not to remove every human step. it is to remove the unnecessary reconstruction between meaningful human steps.

that is the work between the work, and it is where a great deal of practical automation belongs.