Some of the most expensive technical problems inside a company do not look technical.
They look like capable employees doing “just one more manual step.”
Someone exports data from one system and imports it into another.
Someone maintains a spreadsheet because the main application cannot show what they need.
Someone sends the same reminder every week.
Someone double-checks records because the data is not fully trusted.
Someone knows how to fix a recurring exception that the software never learned to handle.
The company keeps moving.
So nobody treats it as a system problem.
That is the problem.
When People Become Part of the Architecture
Developers usually think about architecture in terms of services, APIs, databases, queues, and dependencies.
But organizations have human dependencies too.
A workflow might actually look like this:
CRM
|
v
Employee exports CSV
|
v
Spreadsheet cleanup
|
v
Employee imports data
|
v
Operations system
Technically, the systems are “integrated.”
Operationally, a person is the integration layer.
That person may be reliable enough that nobody notices the weakness.
Until they are unavailable.
Or the volume doubles.
Or another team needs the same process.
Or the workaround starts producing errors.
This is what makes human workarounds dangerous: they can make a weak system appear stable.
Workarounds Are Usually Rational
I do not think employees create workarounds because they dislike process.
Usually the opposite is true.
They are trying to get the job done.
If the software cannot support a real-world scenario, people adapt.
They build a spreadsheet.
They add a checklist.
They keep notes somewhere else.
They create a manual approval step.
They send a message to make sure something happens.
That resourcefulness is valuable.
But if the workaround becomes permanent, it starts carrying operational risk.
The important question is not:
Why are people bypassing the system?
It is:
What is the system failing to support?
That distinction changes how you investigate the problem.
The Workaround Becomes Invisible
The first time someone manually fixes something, everyone knows it is temporary.
Six months later, it may be normal.
A developer hears:
“That is just how operations does it.”
A manager hears:
“We always export it first.”
A new employee is told:
“Keep your own sheet because the dashboard does not show everything.”
At that point, the workaround is no longer an exception.
It is undocumented production logic.
And undocumented production logic is fragile, whether it lives in code or in someone’s head.
Strong Employees Hide Weak Systems
This is one of the more uncomfortable parts.
The better the employee, the longer the problem can remain hidden.
Strong people remember exceptions.
They know which fields are unreliable.
They know who needs to be chased.
They recognize patterns.
They fix errors before customers see them.
Leadership sees the output and concludes that the process works.
But sometimes the process works only because one person is applying a lot of invisible effort.
That is a scaling problem.
A system should not depend on one employee remembering that “customer type B needs the old report format unless region is X.”
If that logic matters, it needs to be visible somewhere.
Maybe in documentation.
Maybe in process design.
Maybe in software.
But not only in someone’s memory.
Do Not Automate the Workaround Too Quickly
A common engineering response is:
“We can automate that.”
Sometimes that is exactly right.
But automation is not always the first answer.
Suppose an employee manually copies data between two systems every morning.
You could build an integration.
Before doing that, ask why both systems need the data.
Maybe one system is redundant.
Maybe one team could work directly from the source.
Maybe the process exists because of an old policy that nobody needs anymore.
Automating unnecessary work simply makes unnecessary work happen faster.
The better sequence is:
Observe
↓
Understand
↓
Simplify
↓
Automate or Integrate
↓
Build Custom Software if Needed
That order matters.
Follow the Manual Step Upstream
When I see repeated manual correction, I try to trace it back to where the problem begins.
Imagine this process:
Customer submits form
|
v
Incomplete record
|
v
Operations reviews
|
v
Employee fixes missing fields
|
v
Record continues
The obvious solution is to make the correction step faster.
The better solution may be to improve validation at the point of entry.
Instead of:
bad input -> manual cleanup
you want:
validated input -> clean record
This sounds simple, but a lot of software projects miss it.
We optimize the visible pain instead of tracing the pain back to its source.
Private Spreadsheets Are Debugging Clues
Developers sometimes treat spreadsheets as the enemy.
I think that is a mistake.
A spreadsheet is often evidence.
If a team has expensive business software but still depends on a private sheet, ask what the sheet does better.
Maybe it combines data from three systems.
Maybe it tracks a field missing from the official product.
Maybe it gives a team a workflow the main system does not support.
Maybe the official reporting model does not match how the business actually operates.
The spreadsheet might be ugly.
But it is telling you what the users need.
That makes it useful input for system design.
When Automation Makes Sense
Some human work should absolutely become automated.
Good candidates usually have a few characteristics:
repeated frequently
predictable inputs
clear rules
little need for judgment
measurable output
costly or error-prone when done manually
Examples include:
status change -> send notification
new record -> validate required fields
approved order -> create downstream task
daily data -> generate standard report
system A update -> sync system B
These are good places to remove repetitive human effort.
But the goal should not be “automate more.”
The goal should be “use people where people add value.”
When Integration Is Enough
Not every gap needs custom software.
If two existing tools work well but employees spend hours moving information between them, an integration may solve the problem.
That might be:
an API integration
a webhook
an event-driven sync
scheduled ETL
middleware
an automation platform
The key question is whether the business logic is already understood.
If the workflow is stable and the systems simply fail to communicate, integration is often the cleanest answer.
When Custom Software Is Justified
Custom software becomes more interesting when the workaround is not caused by one missing connection.
It may be appropriate when:
the workflow is core to the business
multiple tools are being forced to behave like one system
employees maintain several parallel workarounds
exceptions are business-specific
generic software requires too much manual reconciliation
the company has outgrown the process assumptions built into existing tools
Even then, I would not start with features.
I would start with the work.
What information is created?
Where?
By whom?
Who needs it next?
What gets duplicated?
What gets corrected?
What gets lost?
What requires judgment?
What should stop existing entirely?
Those questions matter more than the framework or stack.
A Simple Audit for Tech Leaders
If you are a CTO, engineering manager, founder, or senior developer, ask your teams these questions:
What do you copy between systems?
What spreadsheet would cause problems if it disappeared tomorrow?
What do you manually check because you do not trust the software?
What reminder do you repeatedly send?
What exception does only one person know how to handle?
What information gets entered more than once?
What manual step increases directly with customer volume?
Which process would break if the most experienced employee took two weeks off?
Do not assume every answer requires code.
Some need documentation.
Some need process changes.
Some need deletion.
Some need integration.
Some genuinely need software.
The Engineering Lesson
I think developers should care about human workarounds because they are part of the real system whether we designed them or not.
The architecture diagram might show:
Frontend -> API -> Database
But the operational architecture might really be:
Frontend
|
v
API
|
v
Database
|
v
Employee exports data
|
v
Spreadsheet
|
v
Manual correction
|
v
Slack reminder
|
v
Another system
That second diagram is often closer to reality.
And until we understand it, we are not really understanding the system we are trying to improve.
The goal is not to remove humans from work.
It is to stop using skilled humans as permanent patches for problems that process or software should handle better.
That is a much more useful definition of automation.
I write more about this kind of workflow and software-design problem here: Your Best Employees Are Doing Work Your System Should Be Doing.
Top comments (0)