Engineers have a reliable failure mode: encountering a manual task once and immediately building infrastructure for it. The task takes twenty minutes; the automation takes six hours, needs maintenance, and handles the one variation that existed at the time. Six weeks later the process changes and the tool becomes a source of confusion rather than leverage.
A rule that holds up
Do it manually the first time. On the second occurrence, write down the steps. On the third, automate the steps you wrote down. This works because by the third time you know which parts are stable and which vary, and the written procedure is most of the specification.
The exceptions are worth naming: automate immediately when the manual version is dangerous, when it must run at a time nobody is awake, or when correctness depends on doing exactly the same thing every time. Deploys and backups are automated on day one for reasons that have nothing to do with frequency.
Documentation is automation's first stage
A written procedure is undervalued because it is not impressive. But it removes the memory dependency, it lets someone else do the task, it survives a tool change, and it is the artefact you automate from. Many processes never need to progress past this stage, and that is a good outcome rather than a half-finished one.
Count the true cost
- Build time, which is always underestimated by a factor most of us know and ignore.
- Maintenance, which is permanent and grows with the number of systems it touches.
- Debugging under pressure, because automation fails at inconvenient moments and someone must understand it then.
- Knowledge loss, since a fully automated process nobody has performed manually becomes opaque within a year.
Against that, the saving is minutes multiplied by frequency. Run the arithmetic honestly and a large share of proposed automation is a hobby with a business justification attached.
The best automation removes a decision, not a keystroke. Anything that still requires judgement halfway through has not really been automated.
What to automate first
Prioritise by risk rather than by frequency: things that are easy to get wrong, things where a mistake is expensive, things done under time pressure. A checklist beats a script for anything requiring judgement, and a script beats a person for anything requiring precision. Choose by the nature of the task, not by how much you enjoy building tools.
Join the conversation
Discussion0
Join the conversation. Sign in to leave a response or reply to comments.