When Should Systems Replace Human Interaction?
People record intent. Automation records reality. Good systems know the difference.
You’ve probably been in this meeting.
Someone spends ten minutes explaining numbers that already exist in three different systems. Someone shares their screen. People ask clarifying questions.
Eventually the meeting actually begins.
We point to situations such as this one as examples of poor organizational communication. In many cases, though, the problem isn’t communication at all.
It’s a systems design problem.
Organizations often talk about systems replacing meetings and human interaction. Sometimes they should. Sometimes they shouldn’t. And sometimes the system shouldn’t replace interaction at all; it should simply record what actually happens in the real world.
The real design question isn’t whether systems eliminate human interaction. It’s which interaction should exist in the first place.
Some interaction is necessary because people are reasoning together. Other interaction exists only because information hasn’t been made visible yet.
Good systems eliminate the second kind.
Too many systems get this wrong.
When a System Should Replace Human Interaction
Some conversations and meetings happen only to transfer information.
Consider a hypothetical team that runs a weekly service health review.
Before a shared monitoring dashboard existed, engineers gathered information from Slack threads, incident tickets, and deployment logs. Someone assembled a summary of outages and errors before the meeting and presented it to the group.
The first part of the meeting was always spent reviewing what had happened.
Which services went down?
How long were they unavailable?
What was the severity?
Although people were talking, most of the meeting involved transmitting information that already existed somewhere.
After the team implemented a shared incident dashboard, the structure of the meeting changed. Incidents appeared automatically in one place. Severity levels were visible. Resolution times were tracked. Anyone could review the data before the meeting began.
The meeting itself didn’t disappear, but its purpose shifted. Instead of recounting incidents, the team discussed patterns. Why were certain failures recurring? Were there architectural weaknesses behind them? Which services needed deeper attention?
The system didn’t eliminate the meeting, but it eliminated the need to explain the same information repeatedly.
When interaction exists only to convey information, a system should usually replace it.
When a System Should Support Human Interaction
Not all interaction is informational.
Some interaction exists because people need to interpret situations, apply judgment, or make decisions under uncertainty.
In those cases, replacing the interaction would be a mistake.
What the system should do instead is support the interaction by giving people a shared view of the situation. When everyone enters a discussion already looking at the same information, the interaction improves immediately. Participants arrive prepared. Assumptions get challenged earlier. The discussion can move directly to reasoning.
In this role, the system isn’t replacing human interaction. It’s enabling better interaction.
When Systems Drift From Reality
There is a third situation that appears frequently in operational systems: the system attempts to represent reality but slowly drifts away from it.
Consider a conference room reservation system.
On paper it solves a simple coordination problem. Employees reserve rooms through a calendar, and the system tells everyone which rooms are available.
In practice, the real world rarely aligns perfectly with the system. People reserve rooms and never show up. Meetings run long. Teams use empty rooms that were technically booked by someone else.
The calendar might say the room is reserved until two o’clock, but when someone walks past the room it is empty.
At that point people stop trusting the system. Instead of checking the calendar, they ask each other whether the room is actually free.
The system still exists, but it is no longer authoritative. Interaction returns because the system no longer reflects reality.
This pattern appears across many operational systems. Whenever a system drifts away from reality, people fall back to human interaction.
A Better Mental Model
One useful way to think about systems is to separate intent from reality.
People are good at describing what they intend to do. Systems coordinate processes. Automation is good at recording what actually happens.
A simple mental model is this:
People record intent.
Automation records reality.
Consider a delivery company.
A dispatcher schedules a route and assigns deliveries to a truck. That step records intent; it describes what the organization plans to do.
Reality is recorded automatically. The driver scans the package when it arrives. GPS records the truck’s location. The system logs the delivery time.
Now the system can show both things clearly: what was supposed to happen and what actually happened.
When reality is captured automatically, the system stays trustworthy.
When systems rely on people to manually report reality after the fact, accuracy tends to decline.
Why Systems Often Fail
Many enterprise systems quietly assume that people will faithfully maintain data about the real world.
In practice, they rarely do.
Sales activity tracking provides a common example. A company might require salespeople to log every call and email in a CRM in order to create visibility into sales activity.
But the actual work happens elsewhere. Calls happen on the phone. Conversations occur in email threads and messaging apps.
Logging the activity becomes a separate task.
At first people try to keep the system accurate. Over time entries become rushed or incomplete. Some activities are never recorded at all.
Eventually the system stops reflecting what actually happened. Once that happens, people stop trusting it.
The system was designed for reporting rather than for the work itself.
Replace Interaction Only When the Process Is Clear
Systems should replace human interaction when the interaction exists only to transfer information and the process itself is well understood.
If the rules are clear and the outcomes can be modeled in the system, automation works well.
But much of real work does not fit that pattern.
When processes are new, complicated, or ambiguous, human interaction matters. When decisions depend on judgment or intuition, discussion is essential.
In those situations the system should record the outcome of the interaction rather than attempt to eliminate it.
The Problem With “Single Source of Truth”
Enterprise architecture discussions often revolve around the phrase “single source of truth.”
In practice, that phrase often implies that other systems contain incorrect or outdated information. One system is considered authoritative while others may drift.
We should aim for something better.
The goal should not be a single location where truth resides. The goal should be systems designed so that the truth stays consistent everywhere.
Achieving that requires thoughtful synchronization and discipline about how many platforms hold critical data. When done well, systems reinforce each other instead of contradicting each other.
Designing Systems That Stay Close to Reality
Systems that support good decisions tend to follow a few simple principles.
Real-world actions should connect directly to system actions. Work should not happen in one place and then be reported somewhere else later.
Whenever possible, systems should observe events automatically rather than relying on manual updates.
Exceptions should surface quickly. When reality diverges from expectations, the system should make that visible.
And perhaps most importantly, systems should avoid asking people to maintain data that the system could capture on its own.
The Real Question
The question isn’t whether systems should replace human interaction.
The question is whether the interaction exists for information or reasoning.
If it’s information, systems should replace it.
If it’s reasoning, systems should support it.
And when reality changes, automation should record it.
