The Shared Circuit

Estimated reading time: 3 minutes

“The scariest dependencies are the ones nobody thought to call a dependency.”

Michel Paquin

The story

Last year, we were leaving the main dining room on a Mediterranean cruise when the lights went out.Not just the lights. Everything. Propulsion stopped. Water stopped. Even the toilets stopped — they need electricity to run the pumps that drain the waste.

For two hours, our ship drifted quietly somewhere south of Italy, dark from bow to stern, a few thousand people stuck in hallways they couldn’t see, waiting for one system to come back online.

Nobody had thought about the toilets. Why would they? Toilets aren’t electrical. Except on that ship they were — silently wired through the same circuit as the lights and the engines. You only discover a dependency like that when it fails. And when it fails, everything it was quietly propping up fails with it, all at once, in ways that look unrelated until you trace them back.

Organizations run on the same kind of wiring.

The shared circuit

Call it the shared circuit: one system, one approval chain, one vendor, or one person’s tribal knowledge that quietly underlies functions everyone assumes are independent.

Finance thinks it has nothing to do with customer support. Until the same third-party API goes down and both stop working the same afternoon. Sales thinks it’s insulated from a hiring freeze in operations. Until the one person who knew how to configure the CRM leaves, and suddenly deals stop moving too.

On the ship, nobody mapped the toilets to the engine room. There was no reason to — until the two hours in the dark made the connection impossible to ignore.

Why it stays invisible

A shared circuit hides in plain sight for a simple reason: it works. Every single day, it works. And a system that has always worked quietly gets reclassified in people’s minds from “fragile thing we depend on” to “just how things are.”

Nobody budgets time to map a dependency that has never once caused a problem.That’s exactly what makes it dangerous. The dependency isn’t hiding because it’s small. It’s hiding because it’s reliable — until, for two hours off the coast of Italy, it isn’t.

When this doesn’t apply

If your organization is small enough that everyone already knows exactly where the single points of failure sit, you don’t need a mapping exercise — you need to keep talking to each other, which you’re already doing.

And this isn’t a license to chase every theoretical dependency to the point of paralysis. Cataloguing infinity isn’t diligence, it’s anxiety wearing a spreadsheet. The goal is finding the two or three circuits that would take everything else down with them — not documenting every wire in the building.

What to do this week

Pick one process your team treats as routine and reliable. Ask out loud: “if this went down for two hours, what else would silently stop?”Write down whatever surprises the room. Those surprises are your shared circuits.

Michel Paquin

Michel Paquin is a Senior Commerce Transformation Leader and Senior Lead Consultant in Commerce Strategy at Valtech, based in Montreal. He helps organizations improve transformation execution through clearer governance, operating models, decision frameworks, and measurable outcomes. He writes about decision velocity, commerce transformation, AI adoption, and the systems that make change stick.

All new articles directly in your inbox? Subscribe to my Entreprise Transformation Newsletter

* Please note that I am unable to accept mandates outside of my engagement with Valtech.