The Automation Trap: When Technology Becomes a Substitute for Leadership
There is a very specific facial expression that appears when someone has explained the same point eight different ways and the room still misses it.
You know the look…
It is the look of someone who has drawn the process on a whiteboard, simplified the language, added the business case, removed the jargon, added the jargon back because someone asked for “more strategic framing,” and then watched someone confidently say, “Right, but can’t the system just automate that?”
That is the feeling this picture captures. It is the exhausted face of someone realizing the room still thinks the problem is the tool. The technology. The platform. The software. The automation. The AI model. But in many cases, the real problem is much deeper. The company has not agreed on how the work should actually work. And that is one of the most exasperating feelings in business: when people just do not get it. Smart people. Capable people. Experienced people. People who know the business. Yet somehow, the conversation keeps drifting back to the technology because technology feels easier to discuss than ownership, accountability, process discipline, decision rights, incentives, and all the other messy human things that determine whether transformation works.
That is where Jim enters the story.
Every company has a Jim.
Jim may not actually be named Jim. He may be Linda in scheduling, Carlos in maintenance, Priya in quality, Denise in customer service, or Mike on third shift. But every organization has someone who knows how things really work.
Jim knows which report is official and which report everyone actually trusts. Jim knows which field in the system matters, which field is decorative, and which field will unleash an ancient workflow last understood by someone who retired during the Obama administration. Jim knows why Plant 3 does things differently. Jim knows why Customer X gets special treatment. Jim knows why the dashboard number never matches the spreadsheet. Jim knows why the “standard process” requires twelve exceptions before lunch.
Jim is the person people call when the system says one thing, the documented process says another, and reality is standing in the corner holding a wrench.
In some companies, Jim is treated like an employee. In reality, Jim is the operating system. Jim is middleware with a badge. Jim is a human API in a quarter-zip, holding together years of process debt, tribal knowledge, undocumented exceptions, political compromises, and “temporary” workarounds that have somehow become permanent infrastructure.
Ok, that is exaggerated. But gosh, we can all relate. 🤣
Because every organization has a person, or a small group of people, who quietly absorb the ambiguity everyone else has learned to ignore. They remember why the process changed, who approved the exception, which customer needs special handling, which spreadsheet has the real number, and which report will create chaos if anyone uses it too literally. Jim keeps the business moving through a combination of experience, memory, judgment, favors, shortcuts, and just enough sarcasm to remain emotionally balanced. Jim is valuable. Jim is experienced. Jim is often underappreciated. Jim is also a signal that the organization has converted operating complexity into personal dependency. And that is where automation gets dangerous.
When the Process Lives in Jim’s Head
I am a huge believer in technology. I have built much of my career around it. I believe in automation, AI, industrial data, connected operations, software platforms, analytics, and better digital workflows. The right technology can create enormous value. It can improve visibility, reduce variation, increase speed, strengthen quality, simplify decision-making, and scale better ways of working.
But technology has a limit. It can automate a defined process. It can expose a problem. It can accelerate a decision. It can standardize a workflow. It can generate a recommendation. It can even make Jim’s life easier. What it cannot do is magically turn Jim’s undocumented survival guide into a scalable operating model. That is where many transformation programs get into trouble. Companies believe they are automating a process, but the process does not really live in the system. It lives in Jim’s head. It lives in the spreadsheet Jim keeps on his desktop. It lives in the calls Jim makes when the formal workflow gets stuck. It lives in the exceptions Jim remembers because nobody else does.
The company thinks it is buying automation. In reality, it is trying to automate Jim. And Jim is hard to automate because Jim is doing more than completing tasks. Jim is interpreting context. Jim is navigating history. Jim is balancing formal rules against practical reality. Jim is translating between what the system says, what the process claims, what the customer needs, what the plant can actually do, and what the business promised by Friday at 3 p.m.
The Demo Never Includes Jim
One of the great illusions of enterprise technology is the product demo. The demo is beautiful. The workflow is logical. The data is clean. The approval path is clear. The dashboard updates instantly. The exception process behaves politely. Someone clicks a button, and the business outcome appears with suspicious elegance.
Everyone nods. Someone asks whether it has AI. Someone else asks about integration. Finance asks about ROI. IT asks about security. Operations asks whether it can be configured. The vendor answers smoothly.
Jim is nowhere to be found. The demo does not show Jim saying, “That works unless it is the end of the quarter and the order came through the old customer code.” It does not show Jim explaining that the system says inventory is available, but the material is sitting in quarantine and nobody updated the status because the person who does that is covering another shift. The demo shows what technology can do in an environment where the surrounding decisions have already been made. Most organizations are full of decisions that have been delayed, softened, localized, customized, or quietly handed to Jim.
That is why technology projects often wobble once they leave the demo environment. The feature may work exactly as designed, while the organization discovers its process was less clear than the slide suggested. The company had not agreed on what should be standardized. It had not agreed on which exceptions matter. It had not agreed on who owns the end-to-end process. It had not agreed on whether local flexibility creates value or simply protects old habits. It had not agreed on which data definition wins when three functions use three different numbers. Jim knew all of this already. Jim has been sitting in the back of the room, emotionally aging, waiting for everyone else to catch up.
Automation Can Make Jim Faster
This is the automation trap. And I mean that almost literally, because sometimes these projects feel like the old childhood game Mouse Trap. Remember that thing? You spent forever building this ridiculous contraption with ramps, gears, levers, a boot, a bathtub, a diving board, and a tiny cage, all supposedly designed to catch one little mouse.
As a kid, it was thrilling. You would sit there rubbing your hands together, eyes wide, practically whispering, “Oh yes, this is going to be amazing.” Then you would turn the crank, the marble would roll, the lever would swing, the boot would kick, the ball would drop, and somewhere around step seven the whole thing would jam because one plastic piece was half a millimeter out of place.
Modern Version of ‘Mouse Trap’ (Automation Edition) Created by ChatGPT 5.5
That is how some automation projects feel. The organization builds an elaborate chain reaction around a process that nobody fully understands. Step one triggers step two. Step two triggers an approval. The approval triggers a notification. The notification triggers a workflow. The workflow triggers an escalation. The escalation triggers a dashboard. The dashboard triggers a meeting where everyone asks why the number is wrong. And somewhere in the middle of the whole thing, Jim quietly says, “Yeah, that only works if the order type is coded correctly, which it usually isn’t.” Perfect. Wonderful. The marble has left the track.
When a process is clear, governed, trusted, and well understood, automation can make it faster, more consistent, and easier to scale. That is where technology becomes leverage. But when a process is full of exceptions, side agreements, unclear ownership, competing metrics, manual judgment calls, and “that’s how we do it here” logic, automation often does something very different. It turns confusion into choreography. It turns the workaround into a workflow. It turns the exception into configuration. It turns tribal knowledge into system logic. It gives every old habit a username, a timestamp, and a notification setting.
In other words, it makes Jim faster. But making Jim faster is not the same thing as making the organization better. If Jim is compensating for an unclear process, automation may simply help him compensate more efficiently. If Jim is translating between conflicting definitions, automation may simply move those conflicts through the business at higher speed. If Jim is holding together years of undocumented exceptions, automation may preserve those exceptions with a cleaner interface and a more impressive project name. That is how companies confuse digitization with improvement. They automate an approval process without asking whether the approval adds value. They build a dashboard without aligning the metric. They implement AI recommendations without agreeing what a good recommendation looks like. They standardize a workflow without understanding why the real work keeps escaping the official process.
The old process was slow and confusing. The new process is fast and confusing. Congratulations. Jim now has a portal, a workflow queue, and probably an overdue mandatory training module called “Digital Transformation Champion Basics.”
The Jim Test
Every automation project should include a simple test: what happens if Jim is unavailable for two weeks?
If the answer is “nothing major,” the process may be reasonably mature. If the answer is nervous laughter, the company has work to do. If the answer is “we would probably need to call him,” the process lives in Jim’s head. If the answer is “we tried that once and it was a disaster,” congratulations, you have found the real transformation opportunity.
The Jim Test reveals the difference between a real process and a performance. A real process can be taught, measured, governed, improved, and scaled. A performance depends on specific people improvising their way through complexity. Many companies run on performances while pretending they have processes. Jim is often the star of the show. This is especially true in manufacturing and industrial environments, where the formal process and the real process often only resemble each other from a distance. The quote looks different than the scope. The scope looks different than the process. The process looks different than what operators actually do. The data model looks elegant until it meets three shifts, four plants, two naming conventions, a regional exception, and Jim explaining that the system is “technically right, which is why it is wrong.”
For years, I underestimated this. Earlier in my career as a sales engineer, I tended to see problems through a product lens. Find the pain, match the product, deliver the solution, solve the problem. Sometimes that worked. But as I moved from sales into strategy and spent more time with executives, plant leaders, transformation teams, IT organizations, and operations groups, I started to see the larger system around the product. The product mattered. The process mattered more than I expected. The operating model mattered even more. And Jim, somehow, kept appearing at the center of the story.
Jim taught me a lesson many technology conversations avoid: an excellent product can still land inside an organization that has not agreed on the basics.
What Jim Knows Should Become Organizational Knowledge
The answer is to learn from Jim before trying to automate around him. Sit with Jim. Walk the actual process. Compare the documented workflow to the lived workflow. Find where people leave the system and enter the spreadsheet. Identify which exceptions create value and which ones protect comfort. Separate expert judgment from unnecessary variation. Ask which decisions Jim makes because he has unique expertise and which decisions Jim makes because nobody else took ownership.
Then turn that learning into organizational capability. Document what matters. Standardize what should be consistent. Preserve flexibility where flexibility creates value. Assign ownership. Define decision rights. Clean up data definitions. Retire zombie reports. Challenge sacred exceptions. Redesign the work before digitizing the work. And please, stop asking the tool to make decisions the business has not made. That is the leadership work hiding underneath many automation conversations. It is less glamorous than the demo. It takes longer than buying the platform. It requires more courage than approving the budget. It asks leaders to confront the way work actually happens, rather than the way the slide says it happens.
The Point
I still believe in technology. I still believe in automation, AI, industrial data, connected operations, and the power of well-designed systems to improve how companies work. But I also believe every transformation leader should spend more time looking for Jim.
Find the person everyone calls when the process breaks. Find the spreadsheet everyone quietly trusts more than the official system. Find the customer exception nobody documented. Find the report that actually drives behavior. Find the local workaround that survived every standardization initiative. Find the decision that has no clear owner because Jim has always handled it. That is where the real transformation conversation begins.
Technology can accelerate change, create visibility, improve consistency, and scale better ways of working. It can also preserve confusion with impressive speed when the organization refuses to confront how work actually happens. Jim can help you understand the business. Jim can show you the gap between the process and reality. Jim can help you identify where automation will create value and where it will simply digitize dysfunction. Just do not confuse Jim with a scalable operating model. When the process lives in Jim’s head, the first step is admitting that Jim has been carrying an organizational problem everyone else learned how to ignore. And if someone still asks, “Can’t we just automate Jim?” then show them the picture. That face exists for a reason.
