The biggest companies fail not because they lack resources, but because they can’t move fast enough. Kodak had the first digital camera. Blockbuster could have been Netflix. Nokia dominated smartphones before the iPhone.
What kills giants isn’t size—it’s rigidity. Traditional scaling approaches lock you into structures that become harder to change as you grow. You need special innovation teams for new opportunities. Massive reorganizations to respond to threats. Months of planning to pivot strategy. And when strategy shifts, you end up with massive layoffs in one division while frantically hiring for another—a costly, painful cycle that destroys both talent and morale.
Fluid scaling flips this. Your entire organization forms around work dynamically, at a moment’s notice. Not the other way around where work gets shaped to fit rigid structures. You become a cruise liner that pivots like a speedboat. A carrier group with the agility of a fast attack craft.
This isn’t theoretical. When COVID hit, organizations with fluid structures adapted in days. Traditional hierarchies took months. The difference between thriving and merely surviving.
When one collective isn’t enough
Dunbar’s number suggests 150 people as the limit for stable social relationships. LeSS Multi-team Product Backlog Refinements (mt-PBRs) are designed to max out at 8 teams, which assuming 7-9 people per team puts you at 50-75 people. There are experience reports of effective mtPBRs with 70 people and anecdotally, as many as 150. My experience suggests the sweet spot for fluid collectives lies somewhere just under 100, but the exact number matters less than the signals.
With fluid teams, vertical scaling is what enables collectives to tackle more priorities simultaneously, through being able to create more mission teams. This is powerful—you can accomplish more as an organization—but it eventually suffers from scaling challenges. You can only grow so big before you start running into some of the same issues you see when scaling static organizations, while starting to see some that are unique to the fluid approach.
I’ve found that the most reliable indicators of a collective that’s too large are how long it takes to sync and how much time the mission teams need to spend on coordination. When your weekly alignment consistently runs over 90 minutes, you’ve hit a breaking point. When mission teams spend more than 20% of their time coordinating with other mission teams rather than delivering, you’re losing the speed advantage.
The sync time matters because that’s where all mission teams realign. As the collective grows larger, this takes an increasing amount of time and effort:
- Every mission team needs to debrief to close the cycle
- Broader scope requires more strategic guidance and context to be provided
- More marketplace items get proposed and evaluated for priority
- It takes longer to form mission teams around that work
As for the coordination overhead, the more likely that mission teams will have overlaps or conflicts, necessitating coordination. You reach a point where the coordination overhead outweighs or even negates the benefits from fluidity.
PandaDoc hit this wall when their CTO couldn’t maintain the product backlog at 45 teams. When natural subgroups consistently emerge around the same people, problems, or products, lean into it rather than fighting it.
Finding the natural seams
One of the biggest risks in splitting collectives is creating internal silos that fragment the customer experience. It becomes increasingly difficult to remain customer-centric as the company is split into separate internal units. When I was at JPMC, their “One Chase” initiative tackled exactly this—customers felt like they were dealing with different companies when moving between Consumer, Private, Commercial, and Investment banking.
Your internal organization structure should be invisible to customers. They see ONE entity. They expect ONE relationship. Split in ways that preserve this unity.
Split along these lines:
- Value stream coherence: Group people around complete customer journeys where possible
- Knowledge boundaries: Respect natural expertise domains (billing, security, product areas)
While not optimizing for:
- Dependency management: Aim to reduce or eliminate dependencies as much as possible without killing the ability to collaborate
- Customer relationship preservation: Handoffs shouldn’t break customer context
Within collectives, optimize for learning, customer intimacy, and rapid cycles. Between collectives, optimize for alignment, shared standards, customer continuity, and strategic coherence.
Avoiding the local maxima trap
This is the same challenge fluid collectives solve within teams, just at a larger scale. In traditional organizations, each team prioritizes from its own backlog. When you take each team’s #1 priority however, you rarely see the organization’s top priorities being worked on. Static teams naturally optimize for their own continued existence, prioritizing what’s most meaningful to them, not the organization.
Within a collective, this gets resolved because teams form around the top priorities, ensuring you’re working on the most important things, regardless of the number of mission teams that form.
Once you start splitting collectives, you run the same risk but now at the organizational level. While there would likely be fewer collectives than teams, this risk is only reduced, not eliminated. You want your 3 collectives tackling the organization’s top 3 priorities, not priorities 3, 4, and 5.
Coordinating multiple collectives: The leadership layer
Here’s how you solve this challenge, applying the same principles we used for growing collectives but aiming for ultimate adaptability of the entire organization.
The solution combines distributed coordination with strategic direction through two connected mechanisms:
The leadership collective
The leaders of all collectives form their own coordinating collective, syncing less often than their respective collectives, but at regular enough cadence to be adaptive and responsive to feedback and learnings. I suggest at least every 2 weeks.
Their sync follows the same overall pattern as individual collectives:
- Share progress and learnings from their collectives at a higher level than individual missions—how they’re progressing against prioritized opportunities, what they’ve learned about the product, market, customer, and teams
- Review key metrics and performance through information radiators like dashboards, product maps, and throughput forecasters to add context rather than regurgitate visible stats
- Review investment priorities against learnings, especially blockers or need for additional capacity (or potentially less capacity)
- Assess new opportunities and challenges that have emerged since the last sync
- Populate the organizational marketplace with opportunities and problems the organization should tackle
- Focus on what to tackle, not how—which metrics to move, which problems to explore, which opportunities to pursue
- Stack rank priorities collectively across all collectives
- Collective leaders step up to tackle priorities based on domain fit, scale requirements, skills, capacity, and self-containment
- Identify cross-collective work and agree on how to best tackle it
- Provide strategic guidance and context that collective leaders need to bring to their next sync
Inevitably (and ideally) once this filters down into the collectives through their syncs, adjustments and refinements will be made to these plans based on the missions, ideas, and learnings that surface from the collectives.
This creates a feedback loop: strategic direction flows down, marketplace insights flow up, and ongoing synchronization maintains alignment without central control. This is critically important because we’re fallible and can’t guarantee that leadership will get everything right. This allows us to use the collective intelligence (pun intended) of the entire organization to make the best decisions we can about what we should be doing, but do so efficiently and continuously with information and decisions flowing upward, downward, and sideways.
Funding outcomes, not outputs through the investment review
The Leadership Collective handles coordination between collectives, but that’s only half the equation. You still need to connect their priorities to company strategy. That’s where the executive team comes in—not to micromanage execution, but to enable organization-wide adaptability through how they fund work so they can lead without control.
The traditional approach kills agility before teams even start. Individuals spend hours tracking time against hundreds of funding codes. Teams write “bulletproof” business cases for every initiative. Annual budgets lock you into decisions made months before market conditions change. By the time you get approval to pivot, the opportunity has passed.
The Investment Review flips this entirely. Instead of funding projects with predetermined outputs, you fund collectives with desired strategic outcomes. Instead of annual budget cycles, you reallocate capacity quarterly based on what you’re learning. Instead of tracking activities, you measure results.
Here’s how it works: executives allocate investment across strategic areas using time-based funding. You release allocated funds to each area through the next scheduled investment review. A collective focused on regulatory compliance might shrink while the AI collective grows—all without the bureaucratic overhead of project approvals and resource transfers.
This gives you the flexibility that traditional models destroy. When market conditions shift or new opportunities emerge, you can reallocate capacity in weeks, not months. When experiments succeed or fail, you can double down or cut losses at the next quarterly review.
The Leadership Collective provides the actual data that makes this possible. They understand what’s actually happening—which initiatives are creating value, where teams are hitting blockers, what new opportunities are emerging. Executives make investment decisions based on this intelligence combined with company vision, emerging risks and threats, and strategic priorities.
The result: teams focus on outcomes that matter rather than checking boxes on predetermined deliverables. The Leadership Collective reviews business metrics and customer value, not status reports about whether teams are “on schedule.” Everyone stays aligned to strategy while maintaining the freedom to adapt tactics as they learn.
Handling work that spans collectives
Some opportunities or challenges naturally span multiple collectives. Product launches need engineering, design, marketing, and operations. Security incidents require platform, product, and legal teams. These cross-collective initiatives follow the same fluid principles but with clear ownership and landing strategies.
Formation: During Leadership Collective syncs, cross-collective work gets identified and someone steps up to coordinate. They don’t manage the mission—they own the outcome and bring together people from other collectives as needed.
Staffing: People from relevant collectives join the cross-collective mission team temporarily. Their home collective releases them for specific commitments until the mission team determines they’re no longer needed.
Accountability: The mission lead syncs with the Leadership Collective, not to individual collectives. This prevents the “too many bosses” problem that kills most matrix organizations.
Landing strategy: Every cross-collective mission defines upfront how it ends. Does it become a permanent capability in one collective? Split into separate missions that land in different collectives? Or dissolve entirely once the goal is achieved?
Resource conflicts: When multiple cross-collective missions compete for the same expertise, the Leadership Collective makes the call based on organizational priorities. People can’t be in three places at once, so choices have to be made.
This approach keeps cross-collective work fluid and focused while preventing the coordination nightmare that usually comes with matrix structures.
Preserving culture while scaling
With collectives becoming the major units of cohesion and identity, company-wide connection becomes crucial for maintaining shared organizational identity.
Strategic rotation programs align people movement with investment priorities. When quarterly reviews show Payments needs more capacity while Investments has excess, people can rotate between collectives. This serves both strategic needs and individual development—many engineers prefer working on different problems rather than the same domain forever.
Cross-collective forums create communities of practice spanning collectives around disciplines (engineering, design, product) or interests (AI, accessibility, performance). These forums can propose their own missions when they spot opportunities that cross multiple collectives.
Company showcases happen monthly where each collective demos their latest work to the entire company. This isn’t just about celebrating wins—it’s about sharing ideas across collectives and maintaining awareness of what other collectives are building.
Different challenges naturally lead to different approaches. A collective focused on regulatory compliance will work differently from one driving innovation experiments. Embrace this diversity while maintaining connection points through forums, showcases, and strategic rotation.
The platform temptation
As collectives mature, you’ll see the same patterns emerge across them—similar infrastructure needs, repeated UI components, duplicate analytics implementations. The temptation is to immediately centralize these into platforms. Don’t.
Most organizations create platforms too early. Let collectives solve problems independently first. Extract to platforms only when the acceleration benefit is clear and substantial—meaning it demonstrably speeds up multiple collectives, not just reduces code duplication.
The following advice from a senior leader at Amazon I was talking to a while back sums it up nicely, “One is certainly better than Two but, Two is better than None.”
When platforms do make sense, consider them beyond just technology:
- Infrastructure platforms: Deployment, monitoring, security
- Experience platforms: Design systems, research, standards
- Data platforms: Analytics, intelligence, insights
- Operations platforms: People systems, finance tools
Platform collectives follow the same investment portfolio approach as other collectives. As strategic priorities shift, people rotate in and out of platform work. This prevents the ivory tower syndrome and ensures platforms stay connected to customer needs rather than becoming technology for technology’s sake.
Why this beats traditional scaling
Traditional frameworks optimize for predictability over adaptability. They work when you know what you’re building and just need to scale the execution. But in rapidly changing markets, they become anchors rather than accelerators.
SAFe gives you clear roles and predictable processes but buries you in ceremony. Every change requires updating multiple artifacts and getting approval from multiple layers. By the time you’ve planned the change, the market opportunity has passed.
LeSS keeps Scrum principles but forces everything through single product owners who become bottlenecks. New static teams can’t easily form around emerging opportunities. Cross-team coordination happens through representatives rather than direct collaboration.
Disciplined Agile Delivery offers flexibility through a toolkit of practices but requires extensive training to choose the right options. Teams spend more time deciding how to work than actually working. The mental overhead of constant process decisions slows delivery.
Scrum of Scrums coordinates through representatives, creating telephone-game information loss. Critical details get filtered out as they move up and down the hierarchy. Direct collaboration only happens within teams, not between them.
The Spotify Model promotes autonomy but creates accountability gaps. When everything is autonomous, nothing is coordinated. Innovation happens in isolated pockets rather than building on each other.
Fluid approaches respond in days, not quarters. Structure forms around opportunities rather than requiring opportunities to fit existing structures. Teams coordinate directly when needed, not through representatives. Decisions happen where the work is, not where the hierarchy dictates.
When fluid scaling fails
Not every attempt at fluid scaling will succeed. Common failure modes include:
Leadership commitment wavers: Executives get nervous during the messy middle phase and revert to command-and-control. This kills psychological safety and sends people back to playing it safe.
Middle management sabotage: Managers whose roles become less clear can actively undermine the transition. Address this early with transparent conversations about new roles or graceful exits.
Cultural mismatch: Some organizational cultures are deeply hierarchical and can’t adapt to fluid structures. Force-fitting fluid approaches in these cultures creates stress without benefits.
Insufficient investment in tooling: Fluid organizations need better information radiators and coordination tools than traditional hierarchies. Trying to run fluid at scale with spreadsheets and email is a recipe for chaos.
Over-engineering the model: Some organizations get so caught up in perfecting the fluid structure that they lose sight of customer value. The model serves the mission, not the other way around.
Recovery usually requires stepping back to a simpler version, addressing the root cause, and rebuilding trust before trying again.
The paradox of scale
This is what most leaders get wrong about organizational scale: they assume big organizations must move slowly. They design for control first, speed second. They build hierarchies that optimize for preventing mistakes rather than seizing opportunities.
But the paradox of scale isn’t that big organizations move slowly. It’s that we keep building them to be big first, fast second. Fluid scaling inverts this—you stay fast at any size because size becomes just a number, not an architecture.
When your organization forms around work rather than org charts, when teams come together and dissolve based on opportunities rather than annual planning cycles, when coordination happens through shared context rather than management approval—that’s when scale amplifies speed instead of constraining it.
The future belongs to organizations that can tackle any challenge, seize any opportunity, and pivot on a dime—regardless of size. Not because they’re small, but because they’ve learned to be fluid.
Key Takeaways:
- Scale without losing agility by forming structure around work, not hierarchy
- Watch sync duration and coordination overhead as splitting signals
- Use the Leadership Collective to prevent local maxima across collectives
- Fund collectives for outcomes, not projects for outputs
- Handle cross-collective work through temporary mission teams with clear ownership and landing strategies
- Don’t rush to platform teams—healthy duplication beats premature abstraction
- Speed at scale is the competitive advantage, not just scale itself
Essential reading for fluid scaling
Organizational systems:
- Thinking in Systems by Donella Meadows: Systems thinking fundamentals for understanding feedback loops and leverage points in organizational design
- The Principles of Product Development Flow by Donald Reinertsen: Advanced concepts on queues, capacity allocation, and economic decision-making in dynamic environments
- Brave New Work by Aaron Dignan: Practical playbook for building evolutionary organizations with decentralized decision-making
- Org Design for Design Orgs by Peter Merholz & Kristin Skinner: Structuring cross-functional groups and balancing autonomy with alignment
Funding models:
- Capacity-Based Funding Model: The Essential Field Guide (TeamForm): Value-based incremental funding that enables rapid pivots through quarterly cycles
- Funding Agility: Moving Beyond Project Budgets (Thoughtworks): Cultural and operational changes needed for persistent, product-focused team funding