Lisanne Bainbridge’s Ironies of Automation identified a pattern in 1983 that still plays out in modern systems. Automation that removes humans from routine tasks but keeps them responsible for exceptions creates skill degradation. Operators monitor instead of operate, losing the expertise needed when automation fails. Ironically, comprehensive dashboards meant to give “full visibility” often accelerate this degradation by maximizing cognitive load.
I’ve seen this repeatedly in monitoring infrastructure. The system knows which metric crossed a threshold but shows you fifty graphs. You spend cognitive cycles figuring out what the alert already determined. Recent Harvard research on AI oversight found that under high cognitive load, evaluators shift from complementary decision-making to cognitive substitution. They stop evaluating and just approve what the system suggests. The comprehensive UI doesn’t enable better decisions. It overwhelms capacity until people defer to automation.
Why Information Dumps Persist Link to heading
Adding dashboards is organizationally cheaper than questioning what information actually matters. Each team adds their metrics. Each incident spawns new graphs. Nobody removes anything because “someone might need it.” The result is monitoring systems that, as Google’s SRE documentation notes, become “so complex that it’s fragile, complicated to change, and a maintenance burden.”
Google explicitly trended toward simpler monitoring with better post-hoc analysis tools, avoiding systems that try to learn thresholds automatically. They call out reducing cognitive load as a design goal. Charity Majors’ work on observability takes this one step further; where the goal no longer comprehensive dashboards for known metrics but the ability to ask new questions when debugging unknown problems. Traditional monitoring gives you all the data but true observability gives you the interface to find what matters right now.
Partial Automation and Visibility Link to heading
I’ve found automation evolves gradually, not through big-bang replacements. You automate parts with clear, stable requirements first. The parts needing judgment stay interactive but get better tooling. Do-nothing scripts follow this pattern the most through decomposition, verification checkpoints, and incremental replacement. Lowering the barrier to automate matters more than immediate time savings.
The challenge is keeping automation visible as it accumulates. Alert rules and deployment checks outlive their original context. Nobody remembers why we verify this condition or why this pipeline step exists. Background processes lose the “why” over time. Like the context that’s solely in commit messages from three years ago or tribal knowledge that left with the engineer who wrote it. When automation is built as if its meant to be UI, the intent stays visible. The decisions stay structured. Even if they don’t, its more intuitive to guess through trial runs.
Netflix’s approach, from Gergely Orosz’s architecture analysis, was building consoles that surfaced exactly what engineers needed to act on. Not comprehensive views of system state-targeted interfaces for specific decisions. UI that narrows decision space rather than expanding it.
Sadly, I am seeing this break down in current times. The 2025 DORA Report notes that monitoring tools “were built for a world where humans wrote code at human speed.” High-frequency decisions with tight latency budgets can’t wait for human review. But that threshold is higher than teams assume in the AI (or more broadly, automation-heavy) world. For most operational work, the bottleneck isn’t execution speed. It’s cognitive load. Automation that reduces the mental work of figuring out what action to take often beats automation that removes humans entirely but leaves them responsible when it fails.
For teams that invest in narrowing decision space through better UI, I forsee greater ability to scale operational capabilities without scaling headcount proportionally. In more simpler terms, if you focus on doing few things well, you’ll “Do More With Less”. This has a compounding effect where each well-designed interface makes the next one easier to build because patterns emerge and engineers spend less time context-switching between information-dense tasks like dashboards or code-reviews.
I also see that the teams struggling with “not enough bandwidth for oncall” often have comprehensive monitoring and they’re generally drowning in data. The teams handling higher load with smaller oncall rotations usually have targeted interfaces that surface exactly what needs human judgment and automate the rest. Different constraint, same pattern. Something to keep striving for.