Technology & systems
Before you automate, make the task smaller.
A repeated task is a candidate for automation, not an obligation. Start by deciding whether it needs to happen at all. Then make the smallest useful version dependable before expanding it.
1. Write down one complete run
Pick a recent, ordinary example. Record the input, each decision, the output and how you knew it was correct. “Handle the weekly report” is too broad. “Combine three exported files and flag missing rows” is specific enough to examine.
Separate mechanical steps from judgment. Renaming files may be mechanical. Deciding whether an unusual expense is legitimate needs context. Keep that decision visible instead of burying it in a rule.
2. Count maintenance, not just minutes saved
Estimate the time per run and frequency. Then include setup, checking results, fixing failures and adapting when the input changes. A five-minute weekly task saves about four hours a year before maintenance; a complicated solution may cost more attention than it returns.
A useful first version can be a checklist, a saved query or a script you run yourself. A schedule is worth adding only when unattended execution has a clear benefit and a clear failure path.
3. Define the boundary
Write down what the automation may read, what it may change and what it must never do. Use the minimum access needed. Keep credentials out of source files and avoid copying customer or employer data into tools that are not approved for it.
- Input: which files or records are expected?
- Validation: what makes an input invalid or incomplete?
- Output: what result should a normal run produce?
- Repeat: what happens if the same input arrives twice?
- Recovery: can you undo the change or safely run it again?
4. Start with a reviewable result
For example, a file-cleanup script can first list proposed renames without touching anything. Compare that list against a small set of sample files, including duplicates and missing fields. Only enable changes once the preview is understandable.
For actions that send messages, delete records or spend money, keep a human review step until the failure cases are understood. A silent partial success is often harder to repair than an explicit failure.
5. Decide how it earns its place
After a few real runs, ask: did this save attention? Can I explain a failure? Could I stop using it without creating a mess? Keep a short note with its purpose, inputs, owner and recovery steps.
If the task changes constantly or still needs extensive checking, keep it manual for now. That is a valid design decision.
General educational guidance. Adapt it to your environment, permissions and risk. Examples are illustrative unless identified as project history.
← Back to all guides