How "Turning To One Another" Actually Works in Organizations
Margaret Wheatley Turning To One Another describes a principle from her broader complexity-in-leadership framework. The idea is straightforward enough that it gets misused constantly. Organizations spend years building hierarchies, KPIs, and reporting structures, then wonder why employees don't collaborate when something unexpected happens. Wheatley's point is that the primary unit of change isn't the system — it's the quality of human connection. Most people reduce it to "have nicer meetings." That's wrong. The core insight comes from complexity theory: organizations are living systems, not machines. When you treat them like machines, you get brittle performance under normal conditions and catastrophic failure under stress. Turning to one another means creating the conditions where information flows laterally instead of routing exclusively through formal channels. It means people feel permitted and motivated to reach out to someone three levels down or in a completely different department when they notice a problem. I spent about eight years working in organizational development after my first career in operations management. One of the things I kept seeing was the gap between what companies claimed and what their actual information architecture rewarded. You'd have a mission statement about collaboration pinned above the breakroom whiteboard, while the performance review system penalized anyone who spent more than twenty percent of their week on cross-functional work that didn't show up on a quarterly scorecard.
The practical mechanism
Wheatley draws on research showing that the density and quality of social ties within a network predicts organizational resilience better than any structural metric. The mechanism isn't abstract. It involves deliberate practices: regular cross-functional gatherings that aren't status reports, shared physical or digital spaces where informal interaction happens, and leaders who model vulnerability rather than control. When a project hits an unexpected blocker, people who already know each other solve it in a phone call. People who don't know each other spend three weeks escalating through layers. The specific practices I've seen work include what some organizations call "hosting" — leaders taking responsibility for creating conditions where conversation happens naturally, rather than trying to manage outcomes directly. This is different from team-building exercises. It's structural. You change the default layout, the meeting rhythms, the recognition criteria, and the physical or digital environment.
A real problem I encountered
I once worked with a mid-sized healthcare organization that had tried to implement something inspired by this concept. They bought a collaboration platform, held a kickoff workshop, and then went back to their normal hierarchy. Six months later, nobody used the platform. The problem wasn't the tool. It was that their budget approval process still required signatures from seven different managers, and anyone who bypassed that process to get a quick answer from a colleague lost credit on their quarterly review. The workaround was brutal but simple. We identified three to four high-visibility projects where the existing process was clearly failing — slow turnaround, repeated errors, customer complaints. We got executive sponsorship to temporarily suspend the normal approval chain for those projects only, and paired people from different departments together with explicit permission to make decisions without escalation. Within six weeks, the completion time dropped from an average of eleven days to three. The data was loud enough that the suspension became permanent for similar work, and the cultural shift followed.
Get the Full Details
What people miss about this approach
Counter-intuitively, turning to one another requires more structure upfront, not less. The assumption that it means "just let people talk" is the fastest way to fail. Without intentional design, the people who already know each other will keep talking to each other, and the existing power dynamics will reproduce themselves in every new conversation. You have to engineer the mix. Another thing beginners get wrong: they treat this as a soft skill initiative. It's not. It's an information architecture problem. Organizations are networks of information flow. If you want different behavior, you change what information is visible to whom, when, and in what format. Wheatley's work connects directly to the concept of "perturbation" in complex systems — small disruptions that push the system into a new configuration. Creating opportunities for people to turn toward each other is a deliberate perturbation.
When it doesn't work
Be honest about the limits. This approach breaks down in situations requiring strict compliance, safety-critical decision-making, or highly specialized technical work where only certain people have the relevant expertise. A surgeon doesn't benefit from turning to the billing department when making an intraoperative decision. Nuclear plant operators don't solve problems through decentralized conversation. The concept applies to adaptive challenges, not technical ones — a distinction Wheatley herself emphasizes throughout her work. There's also the scaling problem. What works at fifty people becomes genuinely difficult at five thousand. You need layered structures — small collaborative units embedded within larger hierarchical ones. Some organizations handle this with autonomous teams or squad models. Others just layer it on top of existing structure and wonder why it creates confusion rather than clarity. If your organization's primary failure mode is bureaucracy and slow response to change, this approach addresses the root cause. If your primary failure mode is lack of discipline or inconsistent execution, you're applying the wrong lever. That mismatch shows up most often in companies that adopt the language without assessing whether their actual problems are adaptive or technical in nature.
