Manual Work

What you do by hand before building systems around it

Doing work by hand before automating it is how you learn what the work actually requires, and skipping that step is the most common way to build a system that does the wrong thing reliably.

It is tempting to automate a process you only partially understand. The assumption is that AI will figure out the rest. It will not. Automation amplifies whatever process you give it. If the underlying process is not thought through, the automated version will be faster and more thorough at producing the wrong result.

Manual work is not a failure to automate. It is a learning phase. When you do something by hand ten times, you discover the edge cases, the judgment calls, the exceptions, and the moments where a human instinct quietly overrides the rules. Those discoveries are what a good automation brief is built from. Leave them out, and the system will not have them either.

There is also a readiness test embedded in manual work: if it is painful to do by hand, it is often because the inputs are messy, the process is unclear, or the standard is not defined. Those problems do not disappear when you automate. They become harder to see.

Make it visibleChoose one task you want AI to eventually handle. Do it yourself three times in a row, writing down every step, every decision, and every moment you hesitated. That document is your automation brief.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

Understanding before automating

Manual work teaches you what the task actually requires. That knowledge is the specification your AI system needs.

Catching the edge cases

Every process has exceptions. Manual work surfaces them; automation hides them until something goes wrong. AI needs the full picture, including the cases that do not fit the pattern.

Defining what done looks like

Until you can describe what a good result looks like in enough detail to evaluate it, you cannot build an AI system that produces it consistently.

Spotting the real bottleneck

Manual work often reveals that the bottleneck is not the execution but the inputs or the handoffs around it. AI needs the right problem to solve, not just a faster version of the current one.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

Which processes in your work are you thinking about automating that you have not yet done by hand enough times to fully understand?
What are the edge cases in a task you want AI to handle? Can you list them now?
If you had to write a step-by-step guide for someone to do this task for the first time, what would it say?
Where has your team automated something only to find the underlying process was unclear and the automation made things worse?
What would you need to learn about this task before you would trust an AI to handle it?

Readiness traps

Automating to escape a process you find tedious. The tedium is often a symptom of a process that needs design, not speed. Automating it locks in the design flaw.
Assuming that a process which works for one person will work as a system. Personal workarounds and informal steps disappear when you systematize, and the system breaks on the cases those workarounds were quietly handling.
Moving to automation before the output standard is clear. If two people on the team would evaluate the result differently, the system has no consistent target to hit.