Automation as Anesthesia
By Marzena Burakowska | May 20, 2026
A monthly reporting workflow that has run silently for three years stops producing output on a Monday morning. The data source changed its schema over the weekend, and the pipeline can no longer parse the file. Leadership wants the report by end of day. The team pulls up the runbook, half a page, mostly screenshots. The original developer moved to another department eighteen months ago. Two people start tracing through the code, trying to reconstruct what each transformation step was actually meant to do. By the time the report goes out, it’s Wednesday.
This isn’t a story about bad engineering. It’s a story most of us in digital innovation have lived through, in one form or another. And it points to something we don’t talk about enough.
Automation as Anesthesia
Automation as an aesthesia. That’s the most simple way I can describe it.
When a process is automated well, it disappears. It stops demanding attention, stops requiring thought, and becomes something that simply happens. That’s the whole promise, and it’s a real one.
But there’s a side effect we underestimate: when people stop performing a task, they stop understanding it. The reasoning behind each step, the edge cases, the small judgments that used to live in someone’s head, all of it fades. Not loudly, not visibly. Knowledge erodes silently until something breaks, and then we discover how much of it was already gone.
The Delegation Trap in Large Corporations
In large organisations, this cognitive erosion gets amplified by structure. Responsibility for automated processes drifts outward and downward, to vendors who own the tooling, to platforms that abstract away the logic, to junior teams who inherit the what without ever being taught the why.
Each handoff is rational on its own. Each one looks like a good delegation. But layer them together and you end up with processes that nobody truly owns. There are people accountable for outputs and people accountable for uptime, but the conceptual ownership, the deep understanding of why the process exists and how it actually works, has quietly evaporated.
Why This Creates Operational Vulnerability
The risk shows up in three concrete places.
Process improvement stalls. You cannot optimise what you no longer understand. Teams end up adding workarounds on top of workarounds because the original logic is opaque. Optimisation becomes archaeology.
Incident response slows.When automation fails, recovery depends on knowledge that has atrophied. The team that should be solving the problem in twenty minutes spends three hours reverse-engineering their own system.
Vendor lock-in deepens. Without internal understanding, switching costs become prohibitive. You don’t choose the vendor anymore; the vendor chooses you, because nobody on your side knows enough to migrate away.
None of these failures looks dramatic on a normal day. They show up as slower roadmaps, longer outages, and contracts you can’t walk away from.
The Role of the Manager
This is where managers in digital innovation have a role that goes beyond delivery.
We are not just shipping automations. We are, whether we name it or not, the guardians of organisational understanding. Our job is to make sure that when we remove a task from someone’s daily work, we don’t also remove it from the organisation’s collective memory.
That means resisting the temptation to measure success only in processes automated and hours saved. It means asking a second question: who still understands this, and how do we keep that understanding alive?
Practical Principles
A few guardrails I’ve found useful, none of them revolutionary, however, all of them are often skipped.
Document the why, not just the what. Step-by-step instructions decay quickly. Reasoning lasts longer. Every automation should come with a short explanation of the business logic it encodes, and the decisions that shape it. Keep that documentation in a dedicated shared folder that everyone on the team knows how to find.
Monitor what you’ve automated. Build a simple dashboard with usage volume, successful runs, and failure rates for your key automations. Governance of automation isn’t just about building it well; it’s about knowing how it behaves over time.
Review automation. Periodically, have someone walk through the current version of the automated process to validate their performance, relevance, and check if there is possibility of improvements with new technologies.
Treat automation as a skill multiplier, not a skill replacement.The goal is to free people for deeper work, not to make the underlying work invisible to them.
Closing
Automation is one of the most powerful tools we have. It is also one of the easiest to misuse, not through bad engineering, but through quiet abdication.
The point of automating a process isn’t to stop thinking about it. It’s to free people to think about harder things, including the process itself. Efficiency without understanding is just fragility with a faster runtime.
The question worth asking on every digital innovation team is, what have we automated, and do we still understand it?
Unless stated otherwise, EVERGO Partners grants a non-exclusive, royalty-free license to use, share and reference selected content published on this website for non-commercial purposes, with attribution.
Written by:
Partner
