I’ve had these conversations dozens of times. An executive reaches out—sometimes exploring options, other times already deep into the hiring process. And the opening is always the same: optimistic, ambitious, urgent. “We need to move faster”. “There’s untapped value in our data”. “We should be doing more with AI”. “We’re leaving alpha on the table”.

They’re not wrong. The opportunities are real. But somewhere between the enthusiastic kickoff and the third or fourth meeting, the energy shifts. The language changes. We’re no longer talking about what we could build. We’re talking about what’s breaking.

The spending on data keeps climbing—new vendors, new tools, new headcount. But key employees are still leaving, exhausted from battling infrastructure problems. Employees are spending days and months preparing vital reports, battling data quality issues and reconciling across departments. And when regulators come asking questions, responses are late, hesitant, and uncomfortable.

These aren’t attractive problems. They don’t inspire teams or impress boards. So they often get repackaged as “modernization”, “AI adoption”, anything that sounds forward-looking rather than remedial. The rebranding may be pragmatic, even necessary. But whatever the label, the foundational work remains urgent. Without it, the bleeding continues—quiet, persistent, compounding across every corner of the business.

The executives I talk to, they know. They’ve known for a while. They just haven’t known how to fix it—or whether it was even fixable.

The Stitching Problem

When a boxer takes a bad cut during a fight, the cutman goes to work immediately—stitches, pressure, whatever it takes to stop the bleeding and get the fighter through the round. It’s tactical and necessary — win or lose stakes are high. But no boxer builds a career on stitches. Recovery means months of proper healing, adjusting technique to avoid the same vulnerability, and reconditioning the body to be more resilient. The stitches buy you the time and help you go through the day. They don’t make you a champion.

The same principle applies to running data organizations.

Stitching is tactical. It doesn’t always come in the flavor of fixing a data issue or re-running a pipeline. A business team reacting to a market situation and running ad hoc queries to navigate is an example. Having the business execute on the spot — with the access, training and experience to do it — is real value. Quality, automation, cost and predictability still need to be addressed the next day.

Multi-strategy funds—which are in the business of providing capital and tools to independent investment teams (often called pods)—offer a clear example. When portfolio managers join and capital is committed contractually, thoughtful funds pay particular attention to each strategy’s needs and focus on creating platform advantages to support them at scale. Without this investment, portfolio teams face the challenge of building their own capabilities to enable alpha generation—work that can take a systematic team six to twelve months before they even start trading. Now multiply that across dozens of teams. The economics break down quickly: duplicate data roles across pods, orphaned licenses, compliance blind spots from lack of visibility, and ultimately performance erosion as teams spend more time fighting data issues than generating returns.

Successful business planning starts with deliberate, strategic investment in data and AI infrastructure—creating a living data DNA that breathes through every part of the organization. You can’t raise champions on stitches, and you can’t build a competitive data organization on tactical patches. You can build one on trust.

The Erosion of Trust

While the saying goes “trust is earned, not given,” in organizations there’s often an implicit trust from employees and stakeholders in the “system” that makes things work. We trust that the business will continue doing well, that payroll will process, that compliance protocols are being followed, that the data we’re looking at reflects reality. This baseline trust is what allows organizations to function at scale.

But what happens when that trust erodes? Let me share a dramatic example that reveals just how catastrophic this can become.

Chernobyl: When Trust in the System Dies

In the Soviet nuclear industry of the 1980s, the “system” was expansive and authoritative. It was characterized by massive, state-directed expansion, extreme secrecy, and centralized control under powerful government ministries. State protocols also governed operations. Classified documentation controlled what information operators could access. The official story was clear: Soviet nuclear technology was superior, safe, and infallible. This was necessary to maintain public trust at home, secure lucrative international reactor contracts, apply geopolitical influence and project Soviet power through technological superiority.

The reality underneath was different.

The RBMK reactors—including Chernobyl’s Reactor No. 4—had a known design flaw. Under certain low-power conditions, they could become dangerously unstable due to something called a positive void coefficient. This wasn’t speculation; Soviet engineers knew about it. But the information was classified, compartmentalized, kept from the operators actually running the reactors. Due to the secrecy protocols, people controlling the system didn’t have the full picture of what they were controlling. The instrumentation was chronically unreliable. Sensors malfunctioned regularly, gave contradictory readings, or displayed data points that seemed impossible.

Operators encountered this constantly, but the official intervention procedures were often unworkable. Safety protocols were written by bureaucrats and theoreticians who didn’t appreciate actual plant operations. Following the manual to the letter could be impractical, sometimes even dangerous. Reporting these discrepancies wasn’t an option—it invited scrutiny and suggested disloyalty. So operators developed informal tactical knowledge passed down through shifts: ignore that particular reading, this procedure doesn’t work in practice, trust your instincts and trust the underlying system.

The Incident

On April 26, 1986, Reactor No. 4 operators were conducting a safety test. As the test proceeded, their instruments began showing alarming readings. The reactor was entering a dangerous state. Warning signals activated.

The operators didn’t believe them. Years of experience had taught them that the instruments lied, that alarms were often false, that their operational knowledge was more reliable than the data in front of them.

The reactor exploded at 1:23 AM.

The Aftermath

Thirty-one people died immediately—operators, firefighters, plant workers. The UN estimates some 4,000 deaths ultimately attributable to radiation exposure; the Union of Concerned Scientists and Greenpeace put the toll much higher—potentially tens of thousands. Pripyat, the city, was evacuated permanently: a 1,000-square-mile exclusion zone remains uninhabitable.

The economic impact was staggering. The Soviet Union spent an estimated 18 billion rubles on the immediate response and containment—roughly $18 billion in 1986 dollars, equivalent to well over $50 billion today. Belarus alone lost 20% of its annual budget to dealing with contamination and relocation.

But the deeper damage was to the system itself.

Chernobyl shattered the illusion of Soviet technological superiority. It exposed the rot underneath—the secrecy, the institutional dysfunction, the systematic prioritizing of appearance over reality. The trust that held the system together—the implicit faith that the state knew what it was doing, that the official version reflected reality—evaporated. Within five years, the Soviet Union ceased to exist. Mikhail Gorbachev later wrote that Chernobyl was “perhaps the main cause of the collapse of the Soviet Union.”

The Pattern

The operators at Chernobyl weren’t villains. They were professionals doing their jobs in an environment where the foundational system—reactor design, instrumentation, operational protocols—had been compromised from the start. They adapted, improvised, and developed workarounds because the official infrastructure couldn’t be trusted. They made the best decisions they could with incomplete information in a system that punished transparency.

Not every organizational failure ends in explosions or a collapse—but they’re catastrophic in their own right, within their own scope. When employees lose faith in central systems, they create silos—shadow tools, departmental databases, personal spreadsheets. Failed transparency from the top breeds isolation at the bottom, and management learns about the fragmentation only after the damage has compounded.