The Automation Trap: My Principles for Human-Centric System Design

Founders and operators love a simple narrative: if you can automate it, you should. The pull of frictionless scale is strong. We picture a perfect system of tools running 24/7, freeing up people for „more strategic“ work. But my experience building systems at JvG Technology tells me that narrative isn’t just incomplete. It’s dangerous.

This is the Automation Trap. The seductive belief that technology is a direct replacement for a human process, when it’s usually just a brittle amplifier of existing flaws. The question isn’t „Can we automate this?“ It’s „What kind of system will make us smarter, faster, and more resilient?“ Sometimes the answer is full automation. Often, it’s not.

The web is full of articles on the „hidden costs“ of automation. They mention maintenance and subscription fees, which is a start. But they miss the deeper risks: the erosion of institutional knowledge, the creation of rigid systems that can’t adapt, and the slow drift away from the customers you’re trying to serve. This isn’t a small problem. In practice, a significant percentage of automation projects fail to deliver their expected benefits in the first year.

Over years, I’ve developed a set of principles for Human-Centric System Design. It’s a framework for deciding when to automate, when to augment, and when to deliberately keep a person in the loop. This isn’t about being anti-technology. It’s about being pro-strategy—about building systems that serve the business, not the other way around.

A Note on Calculating the True Cost of an Automation (Beyond the Software Subscription)

The first step in avoiding the Automation Trap is to honestly assess the cost. Most leaders compare an employee’s salary to a software subscription and call it a day. This is a critical error. The true Total Cost of Ownership (TCO) is far more complex. Industry analyses often find that many AI projects overshoot their budgets for this exact reason—the hidden costs are ignored.

I use a simple TCO model to evaluate any new automation project. It forces a more disciplined conversation.

My TCO Model for Automation

1. Implementation Hours: This isn’t just setup time. It’s discovery, process mapping, data cleaning, integration, and testing. It’s my assessment that a primary reason for failed automation projects is automating a flawed process. If you haven’t budgeted significant time to redesign the process before automating, you’re setting yourself up for failure.
2. Maintenance Burden: The ongoing tax you pay to keep the system running. It includes software updates, API monitoring (what happens when a connected service changes its endpoint?), and user permission management. This isn’t a passive cost. It’s active work that someone on your team has to own.
3. Technical Debt: Every automation is a choice that constrains future choices. When you build a core process around a specific tool, you inherit its limitations. Migrating away from it in two years might be so expensive and disruptive that you’re effectively locked in. That’s a debt that accrues interest.
4. Training & Skill Atrophy: When a task is fully automated, the human skill associated with it decays. This „skills atrophy“ is a recognized risk. If the automation breaks, does anyone on the team still remember how to do the job manually? The cost of retraining or the frantic search for a fix during an outage is a real expense.
5. The Cost of Brittleness (Exception Handling): No automation handles 100% of cases. The real cost is in how it manages exceptions. Does it fail silently? Does it require a human to manually fix 10% of inputs? That 10% is a recurring, unpredictable cost in human hours. A system that’s 90% automated can easily be less efficient than a 100% manual process if the exceptions are painful enough to manage.

Before we move forward with any automation at JvG Labs or Mehrklicks, we run the numbers on all five categories. The analysis often shows that a „cheaper“ automated solution is actually far more expensive.

Project Case Study: Why We Didn’t Fully Automate Customer Support at Iberosattel

Theory is useful. A real-world example is better. At Iberosattel, our premium saddle brand, we faced a classic scaling challenge. Customer inquiries were growing. The temptation to implement a chatbot or a fully automated ticketing system was strong. It seemed like the efficient, modern solution.

We mapped the TCO and saw the financial costs, but the deciding factor was strategic. Iberosattel is a high-trust brand. Our customers are expert riders investing in equipment that is critical to their performance and their horse’s well-being. The relationship is consultative. A chatbot, no matter how clever, fundamentally misunderstands the customer’s need. They aren’t looking for an FAQ answer; they’re looking for nuanced advice from someone who understands the product and the sport.

Automating this touchpoint would have optimized for efficiency at the cost of brand equity. It would have sent a clear message: „We value your transaction, not your expertise.“

So we chose a different path. We rejected full automation and built a human-centric system to augment our support team. Here’s what that looked like:

• A Centralized Knowledge Base: We built it for our internal team, not for customers. It has detailed answers, product specs, and situational advice, letting our experts respond faster and more consistently without losing their personal touch.
• Smart Templates, Not Canned Responses: We created templates for common inquiries, but they are designed as starting points. Our team customizes every response, ensuring the customer feels heard.
• Internal Triage System: A simple system routes inquiries to the right expert (fitting specialist, leather care expert, etc.). This gets the customer the best possible answer on the first try.

The result? Our response times improved, and our small team could handle more inquiries. But more importantly, we preserved the high-touch, consultative nature of our brand. We built a system that made our people better at their jobs, instead of trying to replace them. A conscious decision to prioritize the customer relationship over the allure of frictionless tech. It remains one of the best system decisions we’ve made.

The ‚Cyborg‘ Model: Building Dashboards That Augment, Not Replace, Strategic Thinking

The Iberosattel example points to a broader philosophy I call the ‚Cyborg‘ Model of system design. The goal isn’t to build a robot that does the work for you. It’s to build an exoskeleton that enhances the intelligence of the human operator.

Nowhere is this more critical than in how we handle data. The default is to build dashboards that display KPIs. We see charts for revenue, signups, and customer acquisition cost. It’s passive information. It tells you what happened, but rarely helps you understand why.

A ‚Cyborg‘ dashboard is different. It’s designed not to provide answers, but to prompt better questions. It connects data points to reveal second-order effects and guide a strategist toward deeper insights.

Here are the principles I use when designing these systems:

1. Contextualize Ratios, Don’t Just Show Metrics: A raw number is useless. A dashboard that says „100 New Users“ is less valuable than one that says „100 New Users, which is +15% WoW but with a 50% lower activation rate than last week’s cohort.“ The second version forces a question: „Why is this cohort’s activation rate so low?“
2. Highlight Anomalies and Thresholds: Let the system do the heavy lifting of monitoring. Instead of a human scanning charts for problems, the dashboard should actively flag when a metric crosses a predefined threshold. For example: „Support tickets from XYZ feature are 3x higher than average this week.“ That’s an immediate prompt for investigation.
3. Connect Leading and Lagging Indicators: Most dashboards show lagging indicators (like revenue). A useful system connects them to the leading indicators that drive them. It might show how a drop in website performance (leading) correlated with a dip in conversion rates two days later (lagging). This helps the operator see the cause-and-effect relationships in the business.

This approach turns a dashboard from a rearview mirror into a set of diagnostic tools. It keeps the human strategist in the driver’s seat, using the data system as a navigator to spot trouble they’d otherwise miss. It’s the difference between a system that reports the news and one that helps you write the headlines.

My Litmus Test for Re-introducing a Human into a Broken Automated Workflow

What do you do when an automation is already in place and causing problems? Unwinding a failed automation can be just as complex as implementing it. Over-engineering and a failure to plan for human oversight doomed massive projects like the Denver Airport baggage system. On a smaller scale, we see it all the time with broken lead routing or buggy inventory management.

For these situations, I’ve developed a simple diagnostic checklist. It’s a litmus test for deciding whether to fix an automation or re-introduce a human into the loop. It helps you step back from the technical details to make a strategic call.

If you have a workflow that feels brittle or is causing team frustration, run it through this audit. The clarity can save you countless hours of trying to patch a fundamentally broken system.

I’ve compiled these diagnostic questions into a worksheet you can use to audit your own systems.

Your Framework for Human-Centric Decisions

The goal of a systems thinker isn’t 100% automation. It’s to build the most effective, resilient, and intelligent organization possible. Technology is just one tool for that, and like any tool, it can be misused.

Avoiding the Automation Trap requires a shift in mindset. Instead of a binary choice between human and machine, we should be looking for the optimal combination of both.

My framework is simple:

1. Calculate the True TCO: Go beyond the subscription fee. Account for implementation, maintenance, technical debt, skill atrophy, and the cost of brittleness.
2. Align with Brand Strategy: Ask if the automation strengthens or weakens your core brand promise. As with Iberosattel, the most efficient solution can be the wrong one.
3. Augment, Don’t Just Replace: Apply the ‚Cyborg‘ Model. Design systems that make your team smarter, surfacing insights that prompt better questions.
4. Audit and Unwind When Necessary: Use the Litmus Test to regularly assess your automated workflows. Be prepared to put a human back in the loop when a system becomes more trouble than it’s worth.

By applying this human-centric lens, you move from being a reactive manager of tools to a proactive designer of intelligent systems. You start building a business that is not just automated, but resilient.