Intentional Organizations Don’t Happen by Accident

-The difference between a system that learns and one that simply trudges forward

A story I heard recently has stayed with me.

A new owner takes over a facility. He’s hands-on, engaged, clearly different from what came before. One of the first things he notices: the break room refrigerator has been broken for weeks. He says, immediately, “Why didn’t anyone tell me? Order a new one and get it here tomorrow.”

A week later, nothing had changed. The person responsible had ordered a cheaper option with a two-week lead time because under the previous owner, cost always won. Nobody escalated because, under the previous owner, nothing ever got done anyway.

So the new owner went out that night, bought an industrial fridge himself, installed it before morning, and apologized to the staff.

The refrigerator wasn’t the problem. The system was.

The previous leadership had conditioned people to prioritize minimal cost over meeting basic needs. The new owner had to show, through action, that responsiveness was the new expectation. Until he did, the old rules still ran the place…silently, automatically, without anyone making a conscious decision to follow them.

That’s what an accidental organization looks like from the inside. Nobody chose it. Nobody designed it. It simply drifted into being.

The root cause is almost never the people

When something is slipping the instinct is to look at behavior. The slip could be a deadline, a process, a leader’s confidence that the work is actually on track. Who dropped the ball? Who should have escalated?

But the root cause I see most often, both inside organizations and across industries, is systemic: unclear ownership, overlapping responsibilities, structures that create territorialism, and information that never travels to the people who need it. These aren’t personality problems. They’re design problems.

You can coach an individual to navigate a broken system. There are limits, though, when the system itself is the problem.

The proprietary data wall

One of the most expensive patterns I see is one I call the proprietary data wall. Teams quietly relearn the same painful lessons because the mechanisms of failure are never shared – not across functions, not across projects, and not across product lines.

The intent is usually protection: protecting people, protecting liability, protecting the company. The effect is stagnation.

Vector illustration by macrovector/freepik

Here’s the part worth sitting with: in many industries, the reporting systems themselves reinforce the wall. Medical device manufacturers file MDRs (Medical Device Reports) when a device may have caused or contributed to a serious injury or death. Automotive has mandatory reporting obligations tied to safety defects and recall decisions. NASA has spent years trying to break down what it calls reliability silos across programs and contractors.

These systems exist for good reason. But notice what they’re designed to capture: incidents after the fact, routed through regulatory and legal channels. What they don’t do (can’t do, by design) is share the mechanisms of failure upstream, across organizations, before the next team makes the same mistake.

When liability dictates what gets documented in Lessons Learned, organizations don’t become safer. They just become quieter. And quiet systems don’t learn.

The shift that high-performing organizations make isn’t about abandoning protection. It’s more precise than that:

They share failure mechanisms, not proprietary designs.
They shift from “Who caused it?” to “What did we miss upstream, and how do we prevent it in the next FMEA?”
They treat Lessons Learned as strategic inputs, not compliance artifacts filed away after a project closes.

For quality and engineering leaders, this isn’t about blame or liability exposure. It’s about protecting future design decisions, reducing rework, and building organizational memory that outlives any single project team.

The mark of a mature quality culture is one where learning compounds instead of resets.

A note on AI and organizational memory

The proprietary data wall is exactly where AI has real, practical utility. Not theoretical potential, but capability available now. Pattern recognition across large, messy, cross-project failure data is something AI can do. Consider what AES Corporation accomplished with safety audits: using AI on existing audit data, they reduced audit time from 14 days to one hour with a significant improvement in accuracy. That’s not a pilot program. That’s what happens when you apply the right tool to a data problem that already exists.

The bottleneck in most organizations isn’t the technology. It’s the data: inconsistent formats, incomplete records, and knowledge that lives in someone’s head rather than a system. Getting your data in order is the harder and more important work. But it’s worth starting.

Humans still own the judgment. AI can surface a pattern across a hundred FMEAs; it cannot tell you whether that pattern matters for your next design decision. That part requires someone who understands the context. Use AI for insights. Keep humans in the loop as the control.

If your team isn’t experimenting with this now, you’re leaving organizational memory on the table.

What intentional looks like

GE didn’t tackle quality issues by asking people to try harder. They invested in shared systems: common language, decision frameworks, visible process data. These ensured leaders could see the work instead of guessing at it.

Toyota didn’t “arrive” at excellence. They treated learning itself as a system, one that compounded over time instead of resetting with each project. That’s why their performance looks effortless from the outside.

The difference isn’t resources, culture, or the right hire. It’s that these organizations made intentional choices about how work would flow, who owned what, and what would happen when something went wrong.

Intentionality is a system, not a personality trait

This is the part leaders sometimes resist: the work of becoming intentional isn’t a one-time project. It’s an ongoing operating discipline.

It means building shared language – not acronyms, which keep people out, but clarity that travels across roles and functions. It means structured conversations: using a flowchart when you need to understand who owns what, a fishbone diagram when you’re exploring a failure, a concept framework when you’re still shaping the problem.

And it means connecting strategy to daily decisions. When people understand how their work connects to the bigger picture (and who their internal and external customers are) decision-making improves. Accountability becomes easier when roles are clear.

vector illustration by katemangostar/Freepik

A word of caution: over-constrained is still accidental

Can you go too far? Absolutely. Too much structure, too much documentation, and suddenly the system exists to be obeyed rather than to help people think. Gates that stop work instead of guiding it. Approval processes with no clarity on what’s actually being approved.

The question to keep asking is: how does this help people make decisions in their work? If you can’t answer that, the structure probably isn’t earning its place. Intentional systems are agile. If you find yourself unable to move, the pendulum has swung from accidentally undefined to accidentally over-constrained. Both are design problems.

The shift that gives me the most hope

Leaders usually bring me in when something is slipping. What I’ve found, consistently, is that I don’t need to push them to change. Once the system becomes visible and they can actually see what’s going wrong and why, the adjustments come naturally.

Clarity has a way of doing that. It turns a vague, demoralizing problem into a solvable one.
That’s the work: not fixing people but making the system visible. And then designing something better: deliberately, iteratively, with the humility to adjust when it breaks.

Intentional organizations don’t happen by accident. But they do happen.

Want to see where your system is leaking quality before it reaches engineering?

Subscribers get the Strategic Quality Integration Checklist: six diagnostic questions that reveal gaps in how your organization integrates quality from the earliest design stages. It’s a fast read with a high signal-to-noise ratio. Check what’s working. Anything left blank is your next leverage point.

You’ll also get access to the Swipe File Vault: practical templates and frameworks you can apply right away, built on the same principles as the checklist.

And if you want to talk through what this looks like in your organization specifically, visit qualityduringdesign.com/talk. Twenty minutes. No pitch. Just clarity on your next best move.