In the humid workshops of the late eighteenth century, William Murdoch was known as the man who could make any machine breathe. As the right hand to James Watt, the titan of steam power, Murdoch was the one sent to the Cornish tin mines to fix the temperamental engines that pumped out the rising floodwaters.

While Watt was obsessed with the precision of his patents and the mathematical purity of pressure, Murdoch noticed something the blueprints ignored: the men operating the pumps didn’t always want them to work. A broken engine meant a day of rest; a perfectly efficient one meant harder shifts and fewer workers.

Murdoch’s invention worked perfectly in secret, but it was killed by the very man who should have championed it, leaving the world to wait another generation for the locomotive.

The Logic Trap in Modern Implementation

Because the history of technology is almost always written as a series of breakthroughs in logic, we often fail to see that it is actually a history of navigating human stubbornness. We assume that if a tool is better, it will be used. We assume that if a project plan is logical, it will be executed.

But as any seasoned Customer Success Manager (CSM) can tell you, the most dangerous part of any implementation isn’t the code-it’s the person in the room who loses power once that code goes live.

Take Hana, a CSM who recently walked into a kickoff meeting for a high-stakes software deployment. On the left side of the table sat Marcus, the project manager, armed with a Gantt chart so detailed it looked like a high-altitude map of the Himalayas. On the right sat Gary, the client’s IT lead.

Gary finally looked at her. “The old one was built for our needs,” he said. “This one is built for the CEO’s dashboard.”

In that moment, the project died. It wouldn’t technically “fail” for another four months, but the death warrant was signed right there. Marcus, however, didn’t see it. He looked at his screen, saw no technical blockers on the list, and moved to the next slide.

Because the spreadsheet only accounts for milestones that can be timestamped, it remains blind to the heavy silence that follows a demo, which is also how a perfectly calibrated engine can fail to turn over simply because the operator refuses to turn the key.

Managing the “Invisible Column”

This is the “Invisible Column” in the project plan. Every implementation has one, but no project management tool provides a field for it. It is the column for Organizational Resistance, or more bluntly, The IT Lead Hates This.

It is all elastic tension and no structural logic. A project plan that ignores politics is exactly like that sheet; it looks tidy in your hands for a second, but the moment you try to lay it flat, it bunches up into a chaotic, unusable mess.

The Anatomy of a Risk Register

To understand why this happens, we have to look at the anatomy of a standard Risk Register. In a typical professional services environment, risks are calculated using a simple formula: Probability x Impact.

If there’s a 50% chance a server will go down (Probability 3) and it would stop all work (Impact 5), the risk score is 15. This is a “High” risk. But how do you score the fact that Gary’s bonus is tied to the maintenance of the old system? How do you quantify the resentment of a middle manager who wasn’t consulted during the sales process?

These are human variables that carry a Probability of 5 and an Impact of 5, yet putting “Gary is annoyed” into a formal risk report feels unprofessional. So, we leave it out. We call it “soft stuff,” forgetting that soft stuff is what causes the most permanent hardware crashes.

Reading the “Trash”

Sky J.D., a man who spent the better part of a decade as a cook on a nuclear submarine, once told me that you could predict a mechanical failure three days before the alarms went off just by looking at the trash.

To Sky, the “trash” was a leading indicator of a propulsion failure. In the world of SaaS, the “trash” is the way an IT team responds to an email. If they take four days to answer a simple question about a webhook, they aren’t busy; they are signaling.

NextPath Workforce Solutions understands this nuance better than most. In the world of staffing, it’s easy to find someone who can manage a Gantt chart or configure an integration. It’s significantly harder to find a professional who knows how to read the “trash” in a client’s communication.

The best CSMs aren’t just technical experts; they are amateur sociologists. They are the ones who realize that the implementation isn’t just a software installation-it’s a territorial invasion. When a company brings in a new tool, they are effectively telling the local tribes that their old ways of hunting and gathering are now obsolete. If you don’t acknowledge the loss of that culture, the tribes will burn the new tools in the night.

Because we are trained to prioritize the “hard” data of timelines and budgets, the “soft” data of human ego is treated as a nuisance rather than a core metric. However, the ego has a higher melting point than steel and is more resistant to change than an encrypted database. If the project plan doesn’t have a strategy for the ego, the plan isn’t a strategy; it’s a wish.

The Cost of Ignoring the Hidden

I once worked on a project where the “Technical Lead” on the client side was actually a developer who had built the original in-house tool that our software was replacing. For six months, he found “bugs” that weren’t bugs. He raised “security concerns” that were actually standard industry protocols.

It wasn’t until a CSM took him out for a beer and asked, “What happens to the legacy code you wrote once we go live?” that the truth came out. He was afraid his best work was being deleted from the company’s history. Once we created a “Legacy Archive” project that he chaired-a purely symbolic gesture to honor his previous work-every “technical blocker” vanished overnight.

A Diplomatic Mission

The solution to the “IT hates us” problem isn’t better technology; it’s better personnel. It’s hiring people who have the emotional intelligence to see the invisible column and the courage to bring it up in the kickoff. It’s about moving away from the “implementation as a checklist” model and toward an “implementation as a diplomatic mission” model.

Although we may want the world to be a series of predictable logic gates, it remains a messy collection of people trying to protect their status, their routines, and their sanity. When you ignore the politics, you aren’t being “focused on the work”; you are being blind to the reality of how work gets done.

You are like the captain of a ship who refuses to look at the weather because “the engine is running at 98% efficiency.” The engine doesn’t matter if the waves are thirty feet high and the crew is hiding in the galley.

The next time you’re looking at a project plan, look for the gaps between the lines. Look for the names that are mentioned but never show up to the calls. Look for the departments that stand to lose the most if the project succeeds. That is where the real work of Customer Success happens.

It happens in the margins, in the subtext, and in the quiet conversations after the Zoom call ends. If you don’t have a column for it, you’d better find someone who can read the air, because by the time the risk shows up on the Gantt chart, it’s usually too late to fix the engine.

Murdoch knew it in the mines of Cornwall, and any CSM worth their salt knows it today: the machine only runs as well as the people who have to live with it.