Shared consciousness and breaking the decision bottleneck

Creating shared context throughout your organization enables faster, better decisions without traditional command structures. Here's how to break the bottleneck.

Shared consciousness and breaking the decision bottleneck
Photo by Trosh Bias / Unsplash

The decision bottleneck problem

Every fast-growing company hits the same wall. I’ve seen teams grind to a halt, not because of a lack of talent or effort, but because every meaningful decision had to crawl its way up the org chart. The result? Decision paralysis. I recall facing the same challenge at Chase: teams waiting for approvals, leads drowning in context-switching, and opportunities slipping by while everyone waited for a green light.

This isn't just a startup problem. It's the default trajectory for most organizations as they scale. The org chart gets more elaborate, but the real work starts to flow through informal networks, backchannels, and Slack threads. The formal structure becomes a bottleneck, not a support system. The result is organizational debt: a backlog of decisions that slow everything down. The cost? Missed market windows, frustrated teams, and a competitive disadvantage.

The classic org chart is a fiction. It shows neat boxes and clear reporting lines. But the real work flows through informal networks, crosses those solid lines, and ignores those carefully drawn boundaries. Most companies still act like the only way to make a big decision is to push it up the chain. The result is a system that can't keep up with the pace of change outside its walls.

What is shared consciousness?

Shared consciousness is the antidote. It's not just alignment or top-down communication. It's a living, breathing context that enables anyone, anywhere in the organization, to make decisions with confidence. While I’ve read about it most in the context of the military in Stanley McChrystal's "Team of Teams," it's just as relevant in tech, product, and any environment where speed and adaptability matter.

What does it look like in practice?

  • Everyone understands the market and customer context, not just the leadership team
  • Priorities and constraints are transparent, not hidden in a slide deck or a quarterly memo
  • Interdependencies are visible, so teams can anticipate and resolve conflicts before they escalate
  • There's a common understanding of how to make trade-offs, so people don't have to escalate every decision

Shared consciousness isn't about everyone knowing everything. It's about everyone knowing enough of the right things to act without waiting for permission. It's the difference between a team that's always asking, "Can we do this?" and a team that's asking, "What's the best way to do this?"

Real-world examples of shared consciousness in action

Let me share three concrete examples from organizations I've worked with that demonstrate how shared consciousness mechanisms operate in practice.

The Product Map

Drawing inspiration from FAST’s Product Map, we created our own version at Split that transformed how teams understood our strategy and execution plans. Unlike roadmaps that quickly become outdated, this visual tool combined elements of Opportunity Solution Trees, Discovery Trees, and MECE frameworks in one view.

The map organized information in layers - from strategic objectives at the top to specific tasks at the bottom. Color-coding showed what was in active development, what was coming next, and what was in discovery. Product managers, designer, and engineers maintained it together during weekly sessions.

What made this powerful was how it created a shared foundation for decision-making. Teams could see how their work connected to strategic goals, understand tradeoffs, and spot dependency risks early. This mechanism reduced coordination overhead by more than half and eliminated most "why are we working on this?" questions. It became our most referenced artifact - the first thing people checked when making decisions or starting new work.

The Single List

At Tinybird, we’ve used the "Single List" - a stack-ranked set of priorities across all product and engineering work that ties directly to our North Star metrics and current goals. Unlike disconnected roadmaps and backlogs that compete for attention, this unified system creates absolute clarity on what matters most right now.

The list lives in our wiki where everyone can access it. Each item includes its impact on metrics, alignment with goals, and links to deeper context. We follow a pretty simple rule: nothing gets worked on that isn't on the list, and everything happens in priority order.

What makes this powerful is how it removes decision friction. Teams don't waste time wondering what to work on next. When priorities change, we adjust the list in our weekly leadership meeting with clear context. This transparency transforms collaboration: product & engineering teams seek clarification because they understand why something matters, and teams join the effort on critical initiatives because they can see their importance. The noise disappears, and everyone aligns around what truly matters.

One Team

At Chase UK, we tackled dependency problems in our marketing technology group with a radical principle: become One Team. We dissolved the boundaries across domains, teams, and functions, creating a single unified MarTech team with shared accountability for outcomes.

This One Team focused exclusively on our highest-priority initiatives. We replaced siloed standups with a single daily meeting, maintained one backlog, and pursued one goal. There was never any question about what mattered most.

The impact was transformative. The concept of "dependencies" nearly vanished because the people who needed to collaborate were already part of the same team with shared objectives. Decision-making happened naturally because everyone had the context to understand tradeoffs.

This approach cut our delivery time nearly in half and changed our fundamental understanding of team structure. We learned that true shared consciousness emerges most powerfully when you stop optimizing for functional expertise and start optimizing for outcome delivery without artificial boundaries.

Why traditional solutions fail

Most attempts to fix decision bottlenecks just add more process. SAFe, Scrum-of-Scrums, and matrix orgs pile on bureaucracy and competing priorities. Information becomes a power play: leaders hoard it, teams get partial context, and even "empowered" teams are left guessing.

Even the best-intentioned "empowerment" efforts fall flat if teams don't have the context to make good decisions. You can give a team all the autonomy in the world, but if they don't know what matters, what's changing, or how their work fits into the bigger picture, they'll either freeze or go off in the wrong direction.

Business impact and ROI

The business impact of faster decisions compounds over time. Companies with strong shared consciousness typically see:

  • Shorter time-to-market for new features
  • Faster response to competitive threats and market opportunities
  • Higher employee satisfaction and retention
  • More consistent execution across teams

Teams I’ve led across various organizations have seen dramatic improvements in deployment frequency, lead time, and team satisfaction after investing in shared consciousness mechanisms. The ROI showed up not just in speed metrics but in business outcomes: faster customer acquisition, better retention, and increased innovation.

Key metrics to track include decision velocity (time from need to decision), escalation rate (percentage of decisions pushed upward), and team confidence (how comfortable teams feel making decisions without approval).

Addressing common skepticism

When I introduce shared consciousness, I typically encounter several forms of resistance:

"We'll lose strategic alignment"

This usually comes from senior leaders who worry that distributing decision-making will create chaos. The counterargument is that shared consciousness strengthens alignment rather than weakening it. At Split, we actually saw more consistent execution after we started leveraging Product Maps because everyone understood not just the what, but the why.

The key is to start with clear boundaries. Explicitly define which decisions can be made autonomously and which need consultation. Don't fight this concern. Acknowledge it and use it to define clearer boundaries.

"This will slow us down"

Middle managers often worry that spending time on context-sharing will reduce productivity. When I faced this at Chase UK, I tracked the time spent in traditional status meetings versus our new single cross-functional team approach. The results were clear: we cut meeting time by 35% while accelerating delivery.

To address this concern, start small and measure results. Pick one team or one project and implement a single shared consciousness mechanism. Track decision latency before and after. The numbers will speak for themselves.

"Our culture won't support this"

This objection often comes from organizations with deeply ingrained command-and-control cultures. My response is twofold. First, I've implemented these approaches in environments from startups to Fortune 50 banks. Second, the desire for autonomy and purpose is universal.

The key is matching your approach to your current culture. Start where you are, not where you wish you were. Then evolve gradually as trust builds.

Getting started

Start by mapping where decisions get stuck in your organization. Where do things slow down? Where do teams wait for approvals? That's where you need to inject more context, not more process.

Creating shared consciousness requires both mechanisms and culture. On the cultural side, focus on:

  • Psychological safety: Teams need to feel safe sharing incomplete information and asking questions
  • Truth over comfort: An environment where honest conversation trumps comfortable silence
  • Learning orientation: Treating mistakes as learning opportunities rather than failures

Try implementing one of the mechanisms I've described. Start small: maybe a Product Map for your team, or an initial attempt at a Single List for your most critical project. Observe what changes when context becomes visible and shared.