A voice memo becomes a post, a thread, and a slide deck. A client form creates a project and sends a welcome email. My feed is full of demonstrations like these.

The useful question comes after the demo. What happens when a service changes, a name is transcribed incorrectly, or a client asks something the form did not anticipate?

Getting the system to run is one job. Keeping it useful is another.

Someone still owns the result

I move between different tools for research, writing, and production. I review client proposals and video briefs. I read the research before I send it anywhere.

Some of that work can be automated. But I still need to decide whether the result fits the person and the problem.

A workflow can complete every step and send the wrong document. An answer can sound confident and miss the question. A finished run tells me that the process ran. I still have to check what it produced.

Count the work after launch

Before I automate a task, I want answers to four questions:

  • Who notices when the result is wrong?
  • Who fixes the system when an input or service changes?
  • Can someone complete the task if the automation stops?
  • Is the time saved worth the time spent checking and maintaining it?

A small, stable task with an obvious result is a good place to start. Formatting a report is easier to check than deciding what the report should recommend.

The difference is useful when choosing where a person needs to stay involved. It does not mean every task needs the same amount of review.

Keep the parts that need your judgment

I want less time spent on repeated formatting and more time on the proposal itself. That means separating the mechanical steps from the decisions that deserve attention.

Start by doing the task well enough to understand it. Notice the exceptions. Then automate a part you can test, with a way to recover when it fails.

Sometimes the right answer is a simple rule. Sometimes an AI tool helps. Sometimes a person is still the quickest and most reliable choice.

I want the maintenance work included in that decision from the start.

There is research behind that concern. Sculley and colleagues’ 2015 paper on machine learning systems describes maintenance risks from data dependencies and changes outside the system.

The paper is about machine learning, rather than every simple automation. I take it as a reason to check the surrounding system, not just the demo.

Common Questions

“Does this mean I should avoid automation?” No. It means checking the cost of keeping it useful, as well as the cost of building it.

“What if I am too busy to review every result?” Choose checks that match the consequence of an error. Keep review where a mistake would matter most.

“What happens when the tools improve?” Test the new option on real examples. Keep it if the result and the ongoing work improve.

Before I automate something, I want to know what it will take to keep it useful.