Psychology · Cralgo ·
A team builds a manual export script because an enterprise resource planning system lacks an API endpoint. A product group institutes a weekly sync across three squads because a shared database migration keeps locking tables. An operations desk keeps an offline spreadsheet of inventory allocations because reconciliation runs in batch at midnight.
Eventually, the infrastructure updates. The ERP exposes a clean REST interface with webhooks. The shared database is decoupled into isolated services with event streams. The core ledger moves to real-time stream processing.
Yet months—often years—later, the export script still runs on a local cron job. The weekly cross-squad review remains on calendars with full attendance. The offline spreadsheet is still updated by hand every morning before nine.
The initial technical or structural constraint is gone, but the workaround persists. Understanding why requires examining what happens to human behaviour and social safety when an ad-hoc adaptation solidifies into organisational habit.
The origin of shadow workflows
A shadow process rarely begins as rebellion. It almost always begins as a local, rational response to an unyielding bottleneck.
When formal architecture blocks task completion, individuals face a choice: miss operational goals while waiting for formal governance to adapt, or construct a parallel mechanism that routes around the obstruction. The parallel mechanism solves the immediate problem. It restores agency, lowers acute friction, and allows work to flow.
In systems thinking, this is a compensating feedback loop. The primary system fails to provide a necessary capability, so an informal subsystem emerges to provide it.
However, the shadow process does not operate in a vacuum. While it runs, it alters the environment around it. It produces auxiliary dependencies, reshapes social expectations, and redistributes cognitive load. By the time the formal constraint is removed, the shadow process is no longer just solving the original constraint; it is solving problems created by its own existence.
Mechanisms of persistence
Why does the removal of the constraint fail to collapse the workaround? Several psychological and operational mechanisms act together to insulate the shadow process from retirement.
1. The psychological cost of unverified safety
When a tool or manual ritual protects an individual from public failure, it acquires asymmetric emotional value.
If an engineer relies on an offline checklist because deployments historically failed without warning, that checklist represents personal protection against reputational risk. Even when automated deployment pipelines add automated rollbacks, health checks, and canary verification, the operator’s mental model remains anchored to the failure state the checklist prevented.
To stop running the manual check requires trusting a newly deployed capability that has zero personal track record. Trusting an abstraction carries asymmetric downside: if the automated system fails, the individual is blamed for neglecting their habitual precaution. Continuing the shadow process carries almost no visible downside, only invisible drag. The ritual persists as insurance against ambiguity.
2. Adaptation drift and collateral utility
A shadow process rarely remains static. Over time, teams append secondary functions to the workaround that the original system was never intended to handle.
Consider the offline spreadsheet created to bypass slow inventory batch jobs. Over eighteen months, team members add custom colour coding for priority orders, embedded notes explaining why a supplier delayed a shipment, and manual formulas calculating warehouse commission.
When the underlying ERP system finally introduces real-time inventory updates, it replaces the primary function (knowing on-hand inventory levels), but it does not replace the accumulated secondary functions (the historical annotations, the custom priority markers, the informal consensus notes).
The team cannot abandon the shadow process without abandoning the accumulated collateral utility it has gathered. The primary constraint was lifted, but the process has anchored itself to a dozen micro-needs that the replacement technology does not address.
3. Asymmetric legibility between formal and informal systems
Architectural changes are legible to engineering leads, enterprise architects, and systems designers. Informal human adaptations are legible only to the people executing them.
When leadership approves capital expenditure to modernise an API or eliminate a manual reconciliation step, success is typically measured at the system boundary: the endpoint exists, tests pass, latency drops. The project is marked complete.
However, the individuals running the shadow workflow are rarely integrated into the validation loop of the formal fix. They may not know the constraint has been fully removed, or they may understand the technical capability exists but lack the operational mandate to decommission their workaround. Because the workaround is informal, it does not appear on system architecture diagrams; because it does not appear on diagrams, no project plan allocates time to unwind it.
4. Sunk cost and competence preservation
Operating a shadow process requires an investment of skill. People become experts in the exact idiosyncrasies of their workarounds. They know which cell in the sheet breaks if an apostrophe is entered; they know which stakeholder must be pinged five minutes before a manual script is executed.
This expertise confers status. Within an operational unit, the person who knows how to operate the informal machine is indispensable. Deprecating the shadow process in favour of a centralised, automated interface flattens that distinct domain knowledge. It replaces personal agency with a standardised button. Resistance to decommissioning is frequently an unconscious defence of acquired competence.
Conditions that determine longevity
Not every shadow process outlives its origin. The degree to which a workaround persists depends on specific organisational conditions:
| Condition | High persistence | Rapid deprecation | | :--- | :--- | :--- | | Visibility of the workaround | Kept inside departmental boundaries; viewed informally as "just how we get it done." | Explicitly documented as temporary debt with a named sunset condition. | | Consequence of failure | High personal accountability for errors; punitive remediation culture. | High psychological safety; errors in the automated path are treated as systemic defects, not personal negligence. | | Secondary function load | High; the workaround has absorbed edge cases, commentary, and custom reporting. | Low; the workaround performs exactly one narrow, mechanical data transfer. | | System trust calibration | Low; previous formal modernisation initiatives had unaddressed edge-case regressions. | High; new tooling is demonstrated to handle edge cases reliably in operational contexts. |
The risk of forceful eradication
When technical leadership discovers that obsolete workarounds are still operating, the immediate instinct is often punitive: deprecate credentials, block access, or mandate immediate compliance with the official architecture.
This approach often misfires. If the shadow process persisted because it had accumulated collateral utility or provided psychological safety against edge-case failures, forcibly severing it reintroduces systemic fragility. When users are stripped of a tool that gave them local control, they do not automatically adopt the official pathway with confidence; they either invent a more obscured shadow process or retreat to passivity, letting failures occur at the system boundary without intervention.
Addressing an obsolete process requires separating its historical trigger from its current purpose. One must Cralgo the underlying workflow—distinguishing between the technical constraint that prompted it and the operational realities that sustain it—before attempting to replace human habits with system defaults.
Decommissioning a workaround requires structural intervention across three dimensions:
1. Auditing accumulated collateral utility: Identify what information, notation, or edge-case handling the informal process provides beyond its original remit. If the new system cannot store or reflect those elements, an alternate home for that context must be established before the shadow tool is retired. 2. Transferring verification responsibility: If individuals retain manual verification rituals out of fear of failure, the responsibility for system correctness must be visibly lifted from their shoulders. As long as the operator bears personal liability for downstream errors, they will run their private checks regardless of what formal documentation advises. 3. Formalising sunset criteria during build: When workarounds are first tolerated or established, a formal sunset metric must be defined. Without a pre-negotiated condition for its retirement, an informal habit will default to permanence.
An organisation’s technology stack changes through discrete deployments and architectural decisions. Human habit and perceived safety change through accumulated evidence of stability. When an old workaround refuses to die, it is rarely due to obstinance; it is evidence that the formal system has removed the technical barrier without yet satisfying the human requirement for predictability and control.
***
Explore the question at Cralgo in our ongoing /research into how organisational context and human judgement interact with technical systems.
Frequently asked questions
How does a shadow process differ from technical debt?
A shadow process is an informal workflow or workaround developed outside sanctioned operational procedures to bypass a bottleneck. Technical debt is unaddressed code complexity or deferred architectural work within the formal codebase. A shadow process often arises as an operational response to technical debt.
Should leadership simply disable access to force adoption of the formal system?
Only if the workaround performs a purely mechanical task with no secondary dependencies. If the process has accumulated collateral utility—such as informal notes or custom priority tracking—abrupt termination will break downstream human workflows. Identifying what value the process carries beyond its original remit is essential before removal.
Why do operators continue running manual verification steps after automation is proven stable?
Persistence is primarily driven by asymmetric risk: the individual faces direct consequences if the formal automation fails, but faces no immediate penalty for continuing their manual verification ritual. Until the cost of failure is culturally decoupled from the individual, the manual ritual remains rational behaviour.