Automation is attractive because it promises movement without attention.
A file arrives.
A job starts.
A record is processed.
A notification is sent.
A deployment continues.
A report is generated.
No one needs to touch the process.
That can be wonderful.
But automation has an uncomfortable property:
it is extremely good at repeating whatever logic we give it, including logic we do not fully understand.
If a manual workflow contains unclear ownership, hidden states, ambiguous transitions, or undocumented assumptions, automation does not remove those weaknesses.
It often makes them harder to see.
Before automating a process, I increasingly want to ask a simpler question:
Can we clearly describe the state of the work before the machine starts moving it?
If the answer is no, automation may be premature.
A Manual Process Can Hide Ambiguity
Humans compensate for incomplete systems constantly.
A task is marked “Ready,” but everyone knows it still needs one check.
A spreadsheet says “Done,” but the person maintaining it remembers that two rows are exceptions.
A report is “Generated,” but someone knows it is not safe to send until the morning data refresh finishes.
A deployment script stops, and the engineer knows from experience that one retry is safe.
None of this may exist in the formal workflow.
The process works because people carry missing state in their heads.
That can make a workflow appear more mature than it is.
Then someone says:
Let’s automate it.
Now the hidden reasoning has to become executable.
The machine does not know what everyone “usually means.”
It only knows what the system explicitly represents.
Automation Forces Ambiguity Into Code
Suppose a manual publishing process looks like this:
Draft.
Review.
Publish.
Simple.
Then we automate it.
Immediately, questions appear.
What if review requested changes?
What if the author resubmits?
What if approval expires after the content changes?
What if publication is scheduled for later?
What if the publishing job runs but confirmation is lost?
What if the article is approved but a required image is missing?
What if publication succeeds but indexing fails?
The original process did not suddenly become complicated.
It was already complicated.
People had been resolving those questions informally.
Automation simply removed the human layer that was masking them.
This is why automation projects often discover workflow problems that seemed not to exist before.
State Is More Than Status
Many systems have a Status field.
That does not automatically mean the process has a good state model.
Imagine:
Pending
Pending what?
Review?
Payment?
External synchronization?
User action?
Scheduled execution?
A status label is useful only if it tells us something operational.
A meaningful state should help answer:
What is true now?
What has already happened?
What can happen next?
Who or what is expected to act?
What conditions must be satisfied before the state changes?
That is much richer than simply displaying a badge.
Model the Transitions Too
States without transitions are incomplete.
Suppose an item can be:
Draft.
Approved.
Published.
The obvious transition appears to be:
Draft → Approved → Published.
But can an approved item return to Draft?
Can a published item be corrected?
Does editing an approved item revoke approval?
Can publication be scheduled?
Can publication fail?
Can the scheduler retry?
Can the item become archived?
These transitions define the real workflow.
If they are not explicit, automation will invent behavior somewhere.
Perhaps in controller logic.
Perhaps in a background worker.
Perhaps in a database trigger.
Perhaps in a collection of conditions added over time.
That logic becomes architecture whether we intended it or not.
It is better to define the transitions deliberately.
Make Invalid Transitions Difficult
A good state model does not merely describe what should happen.
It constrains what should not happen.
A draft should not accidentally become published because one flag was set incorrectly.
A failed payment should not move to fulfilled.
A task waiting for review should not be completed by a scheduler that ignores the review state.
A deployment should not progress to production if validation has not passed.
The system should know which transitions are valid.
This can be represented through:
workflow rules,
state machines,
domain logic,
database constraints,
service boundaries,
or explicit orchestration.
The implementation can vary.
The important part is that the rule exists somewhere authoritative.
Visibility Comes Before Speed
Automation conversations often begin with speed.
How many minutes can we save?
How many clicks can we remove?
How many items can we process automatically?
Those are useful questions.
But speed only helps when the process is moving in the correct direction.
A fast ambiguous workflow is still ambiguous.
It just reaches the wrong state faster.
This is why I would rather have a slower workflow whose state I can inspect than a faster workflow whose behavior I cannot explain.
Speed is optimization.
Visibility is control.
Control should come first.
State Should Be Observable From Outside
A strong automated system should be able to answer:
What are you doing?
Not philosophically.
Operationally.
A background job should have a state.
A scheduled publication should have a state.
A deployment should have a state.
A synchronization attempt should have a state.
A report generation request should have a state.
Queued.
Running.
Waiting.
Succeeded.
Failed.
Canceled.
Conflict.
Unconfirmed.
Whatever the process actually requires.
If an operator must inspect raw logs to guess whether work is happening, the system is not yet very observable.
Logs are important.
They should not be the only way to discover basic state.
Avoid the Invisible Middle
Many weak automations have two visible states:
Not started.
Finished.
Everything between them is invisible.
This creates anxiety.
Did the job start?
Is it stuck?
Is it waiting for something?
Did it retry?
Has it partially completed?
Is it safe to run again?
The more consequential the operation, the more dangerous this becomes.
Consider a data migration.
If the only states are:
Not Run
and
Complete
then a migration interrupted at 63% has no honest representation.
The system may need states such as:
Prepared.
Running.
Partially applied.
Verification required.
Rolled back.
Completed.
The exact names do not matter.
The truth does.
Progress Is Not Always Percentage
Visibility does not require fake precision.
Some systems respond to the need for state by showing a progress bar:
67%.
But where did 67 come from?
If the process has ten steps of wildly different cost, “step 7 of 10” is not necessarily 70% complete.
If an external dependency can stall indefinitely, percentage may be meaningless.
Sometimes state is more useful than progress.
For example:
Validating input.
Waiting for external approval.
Applying database changes.
Verifying deployment health.
These messages tell us what the system is doing without pretending to know exactly how much time remains.
Good observability should reduce uncertainty, not decorate it.
Ownership Is Part of State
Yesterday’s article examined how defaults quietly guide behavior.
Earlier, we looked at handoffs.
Automation connects directly to both.
A workflow state is incomplete if nobody knows who owns the next action.
Consider:
Waiting
Waiting for what?
A person?
A system?
A date?
A third party?
A retry window?
A better state might be:
Waiting for QA approval.
Or:
Waiting for external payment confirmation.
Or:
Scheduled for execution at 09:00 UTC.
Now the state carries responsibility or condition.
The work becomes easier to reason about.
Automation Should Not Hide Ownership
There is a temptation to treat automated processes as ownerless.
The machine owns it.
But machines execute.
They do not own outcomes.
Someone still needs responsibility for:
configuration,
failure policy,
incident response,
permissions,
dependencies,
and changes to the workflow.
If an automated job fails for three days, who notices?
If it begins producing incorrect output, who decides whether to stop it?
If a dependency changes, who updates the integration?
If nobody can answer these questions, the automation may be technically active while operationally abandoned.
Automation reduces manual execution.
It does not eliminate stewardship.
Define the Waiting States
One of the most useful things a workflow can do is represent waiting honestly.
Systems spend enormous amounts of time waiting.
Waiting for a human.
Waiting for a network.
Waiting for an external API.
Waiting for a scheduled time.
Waiting for resources.
Waiting for another process to finish.
Yet waiting is often represented as “In Progress.”
That creates false information.
An item may be “In Progress” for five days while consuming no resources and requiring no active work.
Now metrics become misleading.
Cycle time becomes difficult to interpret.
Ownership becomes unclear.
If waiting matters operationally, represent it.
Waiting for Customer
is different from:
Processing
which is different from:
Retry Scheduled
which is different from:
Blocked by Dependency.
The distinctions help both humans and automation make better decisions.
Time Can Be Part of the State
Some transitions depend on time.
A publication is approved but scheduled for tomorrow.
A retry should happen after fifteen minutes.
A temporary access grant expires at midnight.
A job should remain available for seven days.
These are not merely timestamps attached to records.
They affect what the system is allowed to do next.
A useful model might say:
State: Scheduled
Eligible at: 2026-10-02 09:00
Now the scheduler has an explicit condition.
This is much better than hiding the rule inside a cron job and leaving the item itself labeled “Ready.”
The state should reveal why execution has not happened yet.
Idempotency Becomes Easier When State Is Explicit
Earlier in this series, we explored unconfirmed operations and safe retry.
Clear state models make that problem much easier.
Suppose a publication job is:
Published
A retry arrives.
The system can say:
This logical operation already completed.
If the state is:
Publishing
the system may wait or verify.
If:
Failed before publication
the system may safely retry.
If:
Unconfirmed
the system should verify authoritative state first.
The state tells the retry logic what is safe.
Without it, retries become guesswork.
This is why reliability features often depend on good state modeling underneath.
Hidden State Creates Duplicate Work
Imagine a task appears open.
Someone begins working on it.
In reality, another person already completed the work but forgot to update the tracker.
The system’s visible state and actual state diverged.
Now effort is duplicated.
Automated systems experience the same problem at larger scale.
A job queue thinks an operation is unprocessed.
The external system already received it.
The worker sends it again.
A scheduler thinks content is unpublished.
Publication already succeeded.
It runs again.
Many duplicate-work problems are really state-synchronization problems.
The cure is not merely better deduplication.
It is better agreement about authoritative state.
Choose the Authoritative State Owner
This is one of the most important architectural decisions in automation.
Where does truth live?
If three systems all maintain their own copy of the workflow state, disagreements are inevitable.
Imagine:
Content platform: Published
Scheduler: Completed
Blog: Pending
Which one is correct?
The answer should not depend on whichever screen someone happens to open.
A strong design decides which system owns which state.
Perhaps the content platform owns editorial status.
The scheduler owns execution status.
The blog owns delivery status.
Now each system has a clear responsibility.
The combined workflow may still span multiple services, but truth is partitioned intentionally rather than duplicated casually.
Do Not Automate an Argument
Sometimes a process contains unresolved disagreement.
Team A believes approval happens before scheduling.
Team B believes scheduling can happen before approval.
One system treats publication as immediate.
Another assumes publication is always queued.
People resolve the difference manually.
Then the organization tries to automate the workflow.
That is not an automation problem.
It is a governance problem.
Code cannot eliminate disagreement by hiding it.
If anything, code freezes one side of the disagreement into behavior.
Before automating, settle the rule.
Who owns the decision?
What does approval mean?
When is scheduling allowed?
What state is authoritative?
Automation should implement a decision.
It should not become the place where an undecided policy accidentally gets decided.
Make the Manual Workflow Explicit First
One practical approach is to model the manual process before automating it.
Not with a giant process map.
A small table may be enough.
For each state:
What does it mean?
Who owns it?
What transitions are allowed?
What evidence is required?
What happens if the transition fails?
For example:
Immediately, hidden questions begin appearing.
What happens if Approved content changes?
Can Scheduled return to Draft?
Who owns failed publication?
That is useful.
Finding ambiguity before automation is cheap.
Finding it in production is not.
Manual Operation Is a Prototype
This is a perspective I find helpful:
A manual workflow can be a prototype for automation.
People performing the process reveal:
exceptions,
retries,
waiting states,
missing information,
ownership problems,
and real-world sequencing.
Instead of viewing manual work only as waste to eliminate, study it.
Where do people pause?
Where do they ask for confirmation?
Where do they maintain side notes?
Where do they create duplicate spreadsheets?
Where do they check something “just to be safe”?
These behaviors often indicate state the official system is failing to represent.
The manual process contains clues about the automation you actually need.
Side Channels Reveal Missing State
A particularly strong signal is the existence of side channels.
A team has a ticket system, but they also maintain a spreadsheet.
Why?
A publishing platform exists, but editors message each other in chat to confirm whether an article is really live.
Why?
A deployment pipeline reports success, but engineers still run a manual health check.
Why?
Sometimes these are habits.
Often they are compensating for missing visibility.
Before eliminating the side channel, understand what information it provides.
Perhaps the spreadsheet tracks ownership.
Perhaps the chat provides acknowledgement.
Perhaps the manual health check verifies a state the pipeline does not observe.
Automating the official path while ignoring the side channel can remove the very mechanism keeping the process trustworthy.
Automation Should Reduce Ambiguity, Not Just Labor
A successful automation should leave the process easier to understand.
Not only faster.
Ask after the change:
Can we see what is happening?
Can we explain why an item is waiting?
Can we tell who owns the next action?
Can we verify whether an operation completed?
Can we retry safely?
Can we distinguish failure from uncertainty?
Can another person understand the workflow without asking the original developer?
If automation saves ten minutes but makes those questions harder, it may have traded labor cost for cognitive cost.
That trade can be surprisingly expensive.
Good Automation Produces Evidence
When an automated transition happens, leave a trace.
Not necessarily a huge audit log.
Enough evidence to reconstruct important events.
For example:
Publication scheduled at 08:13.
Scheduler claimed job at 09:00.
Publish request ID 7F92.
Delivery confirmed at 09:00:04.
Public revision 118.
Now the operation is inspectable.
If a problem appears later, support does not need to guess.
Evidence converts invisible automation into understandable automation.
State History Is Often More Valuable Than Current State
Knowing that something is Published is useful.
Knowing how it reached that state can be more useful.
Draft → Review → Returned → Review → Approved → Scheduled → Published.
That history can explain:
delay,
ownership,
retry behavior,
and unusual outcomes.
This does not mean every tiny change needs permanent storage.
But consequential state transitions often deserve history.
A state history is a compact narrative of the process.
It tells us how reality moved.
State Transitions Can Become Decision Trails
This connects with another theme from the series.
A transition may occur because of a decision.
For example:
Review → Returned
Reason:
Source citation incomplete.
Or:
Approved → Draft
Reason:
Content materially changed after approval.
Now the state history preserves not only movement but meaning.
This becomes particularly powerful in regulated, medical, financial, or editorial systems where the reason for a transition matters.
The workflow itself becomes a lightweight knowledge record.
Do Not Confuse Automation With Autonomy
Automation means a machine performs a defined operation.
Autonomy means the machine decides more of what should happen.
Those are different levels of responsibility.
A scheduler publishing an already approved article at a specified time is automation.
A system deciding on its own which unpublished article should go live may be autonomy.
Both can be useful.
They require different levels of trust.
The more decision-making authority we delegate, the more important explicit state, policy, and observability become.
A system should not quietly acquire autonomy because a sequence of automations happened to accumulate.
Start With Boring Automation
There is a healthy class of automation that does not require much judgment.
Copying a confirmed value.
Generating a repeatable artifact.
Running deterministic tests.
Checking a known condition.
Moving an item after an explicit event.
Producing a notification from authoritative state.
These are often excellent first targets.
They have clear inputs.
Clear outputs.
Clear success conditions.
And clear recovery paths.
The glamorous automations are not always the most valuable.
Boring automation is often reliable automation.
Automate the Stable Part First
Some processes are half stable and half evolving.
Do not wait forever for perfect stability.
But isolate the stable part.
Suppose editorial review changes frequently, while publication delivery is well defined.
Automate the delivery.
Keep the review process flexible.
Suppose deployment approval policy is changing, but environment verification is stable.
Automate verification.
Keep approval manual.
This allows automation to create leverage without freezing the part of the process that still needs learning.
Automation should crystallize understanding, not prevent it.
A Workflow Should Be Explainable in Plain Language
One of my favorite tests is simple:
Can someone explain the workflow without referring to implementation details?
For example:
An article begins as a draft. After the author submits it, a reviewer either returns it for changes or approves it. Approved content can be published immediately or scheduled. Scheduled content remains approved but not public until the selected time. Publication must be confirmed by the delivery platform before the article becomes Published.
That explanation is architectural.
No controller names.
No table names.
No queue technology.
No framework terminology.
If we cannot explain the state model clearly in ordinary language, automating it may be premature.
The code will not clarify a concept we have not clarified ourselves.
Visibility Changes Behavior
Once state becomes visible, something interesting happens.
Teams begin noticing problems they previously treated as normal.
Why are twenty items waiting for review?
Why do jobs remain in retry state for six hours?
Why are approved items returning to draft so frequently?
Why does one transition take ten times longer than another?
Visibility turns vague frustration into observable questions.
This makes improvement possible.
You cannot systematically improve a state you cannot see.
Automation Then Becomes Safer
After the state model is visible, automation becomes much more straightforward.
The machine can act on explicit conditions.
If Approved and scheduled time has arrived, publish.
If Publish request is unconfirmed, verify.
If verification shows completion, mark Published.
If verification shows no publication, retry with the same operation identity.
If RetryCount exceeds policy, move to ManualReview.
Now automation follows the model.
It does not invent one.
That is a much healthier architecture.
From Defaults to State
Yesterday’s article argued that the default is a decision.
Today’s idea sits directly beneath it.
A default determines what state a system begins in.
Automation determines how that state moves.
If the states are vague, both defaults and automation become dangerous.
If states are explicit, we can reason about them.
We can choose safer defaults.
Define valid transitions.
Assign ownership.
Make retries reliable.
Design clearer interfaces.
Create better metrics.
Preserve history.
And automate with confidence.
Make Reality Legible First
Automation is not the beginning of a mature process.
It is often a later expression of maturity.
First, understand the work.
Name the states.
Clarify ownership.
Define the transitions.
Expose waiting.
Represent uncertainty honestly.
Choose the authoritative source.
Observe what happens.
Then automate the parts whose behavior is stable enough to trust.
The goal is not to make people watch machines work.
The goal is to create systems that can keep working without constant human intervention while remaining understandable when humans need to return.
That balance matters.
Invisible automation feels magical when everything succeeds.
When something fails, magic is not useful.
State is.
So before teaching the machine how to move the work, make sure the system can answer a more basic question:
Where is the work now?
Once that answer is clear, automation stops being a leap of faith.
It becomes a controlled transition between states we already understand.