Stop Blaming Your Culture: The Real Reason Your Business Is in Chaos

Picture this. It's 2006, and Airbus is getting ready to deliver the biggest, most ambitious passenger jet ever built. Every A380 "superjumbo" has about 330 miles of wiring running through it, roughly 100,000 individual wires. Then the wiring harnesses built in Hamburg show up in Toulouse for final assembly, and they don't fit.

Here's the thing: nobody was careless, nobody had a bad attitude. The teams in Germany and Spain were designing on an older version of their CATIA design software (version 4), while the teams in France and the UK had moved up to version 5. The two versions didn't pass wiring data back and forth cleanly, so lengths and routes worked out in one place came out wrong in the other. Thousands of really talented people were doing their jobs well. They just weren't working from the same information.

And the fallout was huge. Deliveries slipped about two years. The CEOs of both Airbus and its parent company, EADS, stepped down. Airbus said the delays would cut its expected profits by about €4.8 billion (roughly $6 billion at the time).

Nobody would read that story and say, "Wow, Airbus has a culture problem." But when the same thing happens on a smaller scale in our own companies (the spec that got updated in one system but not the other, the spreadsheet that was "the latest version" right up until it wasn't), that's exactly where a lot of us go.

So let me ask you: does your organization feel like it's always fighting fires? Are your teams stuck in endless meetings, redoing work, and tripping over miscommunication? A lot of leaders just shrug and call it the "cost of doing business."

But what if that cost is a lot bigger than you think? It's really common for organizations to spend 40% or more of their resources on this kind of reactive, non-value-added work. We call it "corrective action."

The good news? This chaos isn't inevitable. It's a symptom of something deeper in the system. Let's talk about what's really going on, and the architectural discipline that can turn a reactive, scattered business into a unified, proactive one that keeps getting better.

1. Your Culture Isn't Broken—Your Information Architecture Is

This is the big one. Organizational chaos is usually an architectural problem, not a cultural one. All that firefighting? It's actually a pretty rational response. You've got dedicated people working hard to make up for a broken system that isn't giving them clear, trustworthy information.

W. Edwards Deming, the quality pioneer, was saying this decades ago. He figured that the vast majority of problems (94%, by his estimate) come from the system, not the individual. Or, as the Deming Institute puts it:

"A bad system will beat a good person every time."

You can hang "Do it right the first time" posters all over the building, but if the information underneath is a mess, it won't work. You can't fix a system problem by blaming the people stuck inside it.

Think about it: people can't do it right the first time if they don't get the right information the first time.

In my experience, a broken information architecture usually comes down to three things:

• Unclear or Ambiguous Requirements: When requirements are vague, incomplete, or live only in somebody's head as "tribal knowledge," people have to guess. Those guesses turn into errors that get caught late, when they're way more expensive to fix. How much more? A NASA study on error costs found that a requirements mistake caught in testing costs about 21 to 78 times more to fix than if you'd caught it up front. If it makes it all the way into operations, it can cost anywhere from 29 to more than 1,500 times more.
• Uncontrolled Changes: When plans and requirements keep shifting without a real process to manage them, teams end up working off conflicting or outdated information. That means wasted effort, and processes that fall apart as soon as the business starts to grow.
• Departmental Silos: When there's no shared source of truth, information gets garbled every time it's handed from one group to the next. And those disconnects show up in expensive ways, on the shop floor or in front of your customer.

Sometimes silos don't just cost money. Sometimes they cost you a spacecraft. Back in 1999, NASA lost the $125 million Mars Climate Orbiter because one team's software reported thruster data in imperial units (pound-force seconds) and the navigation team's software expected metric (newton-seconds). Both teams were packed with brilliant engineers. What broke was the hand-off between them: a requirement nobody had spelled out and checked on both sides.

That's why this shift in thinking matters so much. It takes the focus off blaming people and puts it on fixing what's actually broken.

2. You're Not in the Product Business; You're in the Requirements Business

One of the core ideas behind CM2 is a pretty big reframe of what a business actually does. Running a business really comes down to managing requirements. Everything anyone does in your organization should trace back to a requirement that says what needs to get done.

In this model, a requirement isn't real until it's written down, validated, and released as a controlled "dataset." That's how you get rid of the chaos that comes from tribal knowledge, hallway conversations, and requirements buried in a dozen different spreadsheets and email threads. Those are where most of the costly mix-ups start.

Tribal knowledge is a shaky foundation for any business. When someone walks out the door, what they knew can walk out with them, for good. One of my favorite (and scariest) examples: in the 2000s, the U.S. National Nuclear Security Administration needed to make more of a classified material, code-named "Fogbank," for a weapons refurbishment program. The plant that made it in the 1980s had closed, hardly any records of the process had been kept, and most of the people who knew how to make it were gone. According to the U.S. Government Accountability Office, figuring it out again cost about $69 million extra and set the program back at least a year. And later accounts said the original material actually depended on an impurity from the old process, something nobody had ever bothered to write down.

Now, most of us aren't building weapons. But the same pattern shows up everywhere. McKinsey has estimated that knowledge workers spend about 1.8 hours a day, nearly a fifth of their week, just searching for and gathering information. That's a lot of time spent hunting for answers that a good information architecture would just hand them.

So here's the takeaway: information is a real business asset. It deserves the same care and discipline you'd give your finances or your inventory. The quality of your designs, processes, and requirements drives the quality of everything you put out.

3. "Configuration" Isn't Just for Engineers Anymore

When most people hear "configuration management," they think of something the engineering department does, like keeping parts lists and drawing revisions straight. CM2 takes that idea and blows it wide open, turning it from a technical detail into a real business principle.

Here's how CM2 defines it:

A configuration is "the arrangement of anything in a given context."

That means your whole enterprise is really a set of connected configurations that all need to be managed. And it's not just technical data. It covers the four pillars of your business:

• People: How skills, roles, and teams are arranged.
• Processes: The workflows that deliver value.
• Systems: The technology that supports the business.
• Data: The lifeblood of the organization, including how it's structured and connected.

Go back to the A380 for a second. The parts were designed right, and the people were more than capable. What nobody was managing was the configuration of the systems (two versions of the same design tool) and the data moving between them. If you think of configuration as an engineering thing, a software version is just an IT detail. Under CM2, it's part of the product, and it can cost you billions.

That's what makes this idea so powerful. It gets leaders to stop seeing their organization as a bunch of separate departments and start seeing it as one connected "system of systems" that has to be managed together.

4. Stop Controlling Change and Start Accommodating It

Change is the one thing you can count on in business. But a lot of management systems treat it like a threat to be kept to a minimum. And that's how you end up with slow, bureaucratic processes that kill innovation.

On the flip side, change with no discipline at all can be a disaster. On August 1, 2012, Knight Capital, one of the biggest stock traders in the U.S. at the time, rolled out some new trading software. A technician copied the new code onto seven of the company's eight servers and missed the eighth. On that one server, a reused setting woke up some old, retired code, and it started firing off millions of orders nobody meant to place. In about 45 minutes, Knight lost more than $460 million. The SEC later pointed out that the firm didn't have a written procedure requiring someone to double-check the rollout. Within months, the company had to be rescued and was then sold.

Knight's problem wasn't too much change. It was a change that went out with no real impact assessment and no controlled rollout.

CM2 takes a different approach, and it might sound backwards at first: build an infrastructure so solid and efficient that change becomes routine. Something you can welcome as a chance to improve, not something that throws everything into chaos.

The CM2 closed-loop change process makes that possible by splitting up the work. Instead of one big change board trying to do everything, there are three separate groups:

• Enterprise Change Assessment (ECA): A team of subject matter experts who dig into the facts. They put together a thorough, data-driven impact analysis, so decisions aren't made on gut feel.
• Change Review Board (CRB): The business decision-makers. They look at the case the ECA puts together and make the go/no-go call, without getting dragged into technical debates they're not set up for.
• Change Implementation Board (CIB): The hands-on team that figures out the "how" and "when" of rolling a change out, so approved changes don't fall apart in execution. (Something like "make sure the new code is on all eight servers" is exactly the kind of thing this team owns.)

And to keep things moving, there are two paths: a Full-Track for complex, high-risk changes, and a quicker Fast-Track for the 75–85% of changes that are routine and low-risk. That's how change goes from being a threat to being a real advantage.

Conclusion

On the surface, Airbus, NASA, the nuclear weapons program, and Knight Capital don't have much in common. But every one of those expensive failures comes back to the same thing: good people working from information that was incomplete, inconsistent, never written down, or out of control. Not one of them was a culture problem.

The way out of the chaos isn't getting better at fighting fires. It's taking a disciplined, architectural approach: treating information like the asset it is and making change something you handle with confidence instead of dread. Fix the system, and you free up your good people to do great work. That's how a reactive, scattered business becomes a unified, proactive one that keeps getting better.

So here's my question for you: what if the biggest thing holding your company back isn't the market or the competition, but the invisible, broken way your own information is put together?