The Illusion of Automation: Tools That Increase Complexity

There is a widely held belief in engineering organisations that more automation is always better. More CI/CD stages, more deployment tools, more monitoring integrations, more infrastructure-as-code modules. The belief is understandable — automation does deliver value when it is well-designed and appropriately targeted. But the cumulative effect of automation decisions made in isolation, across multiple teams over multiple years, is often a toolchain that is more complex, more fragile, and more cognitively demanding than the manual processes it replaced.

Automation as Complexity Debt

Automation creates complexity debt in the same way that code creates technical debt. Each automated process is a piece of software that must be maintained, debugged, and updated as its dependencies change. A CI pipeline with forty stages, each dependent on a specific version of a specific tool, is a fragile system. When it breaks — and it will break — the debugging cost is high and the blast radius affects every team that depends on it. The automation that was supposed to reduce operational burden has become operational burden.

The Tool Accumulation Problem

Engineering organisations accumulate tools the way codebases accumulate dependencies: opportunistically, without a coherent strategy, and with much more velocity than the corresponding cleanup. A tool is adopted to solve a specific problem. The problem evolves or disappears. The tool remains because removing it is riskier than leaving it. After five years, the toolchain contains tools that nobody fully understands, tools that do overlapping things, and tools that are used by one team and unknown to everyone else.

When Automation Creates More Work Than It Saves

The automation value calculation is straightforward in theory: if the cost of building and maintaining the automation is less than the cost of the manual process over time, the automation delivers value. In practice, this calculation is consistently optimistic. The build cost is underestimated. The maintenance cost is ignored entirely. The frequency of the manual process is overestimated. And the side effects — integration complexity, debugging overhead, on-call burden — are not accounted for.

The Cognitive Load Tax of Over-Tooled Pipelines

Cognitive load is the invisible cost of toolchain complexity. Engineers who must understand ten different tools to complete a deployment workflow are engineers who are spending cognitive capacity on tooling rather than on the product. This cost does not appear in any metric but is visible in onboarding time, debugging time, and the anxiety that accumulates when nobody fully understands the system they are running.

Three Signs Your Automation Is Making Things Worse

First, your build pipeline takes longer to run than the manual equivalent would take. Second, debugging a failed deployment requires more expertise than the deployment itself requires. Third, your toolchain has more failure modes than the system it deploys. Any one of these signals is worth investigating. All three together indicate an automation investment that has delivered net negative value.

Platform Engineering: Golden Paths Over Tool Freedom

The most effective response to toolchain complexity is not more governance — it is better defaults. Golden paths are opinionated, well-supported deployment patterns that make the right choice the easy choice. Instead of giving teams the freedom to choose any tool, platform teams provide a curated set of tools with strong documentation, working examples, and clear migration paths. Teams that need to deviate can, but the default path removes the decision overhead for the majority of use cases.

How to Audit and Rationalise Your Toolchain

A toolchain audit starts with a tool inventory: every tool in use, its purpose, its owner, its cost, and the teams that depend on it. Tools with no clear owner, tools that duplicate capabilities, and tools that are no longer actively maintained are candidates for removal. The audit should produce a rationalization plan with a clear target state — fewer tools, better integrated, with clear ownership. The plan should be executed incrementally, removing tools one at a time rather than in a big-bang migration.

What Good Automation Governance Looks Like

Good automation governance is not a committee that approves every tool adoption. It is a set of clear criteria that teams use to evaluate whether a new tool is worth adopting, a process for retiring tools that no longer earn their place, and a platform team or guild that maintains the opinionated defaults that most teams should use. The goal is not to prevent automation — it is to ensure that automation decisions are made with an honest accounting of the full cost of the tools being adopted.