Beta Codex and the Peach Model: Decentralized Orgs

Most organizations still run on a management model that was designed for a different century. Authority flows downward through layers of approval. Information flows upward through layers of filtering. The people closest to customers and markets, the ones who see problems first and understand them best, are the ones with the least authority to act.

This is not a flaw in execution. It is a flaw in the model itself. Command-and-control hierarchies were built for environments where stability was the norm and predictability was a reasonable assumption. In complex, fast-changing markets, that assumption fails. The organization moves at the speed of its slowest approval chain, and by the time a decision reaches the person who can authorize it, the context that informed it has already changed.

Beta Codex offers a fundamentally different starting point. Rather than trying to fix the pyramid (flattening it, adding dotted lines, creating matrix structures) it replaces the pyramid entirely with a decentralized network model. The related Peach Model provides a concrete metaphor for how this network is structured: a center that serves, and a periphery that leads.

This guide explains what Beta Codex is, where it came from, how its 12 laws work as an interdependent system, how the Peach Model inverts traditional hierarchy, and how it compares to other organizational frameworks. It is written to be useful whether or not you ultimately adopt Beta Codex, because the principles it articulates apply across many approaches to decentralized organization.

Alpha vs. Beta: Two Fundamentally Different Organizational Models

Beta Codex draws a sharp line between two ways of organizing work. It calls them Alpha and Beta, not as a quality judgment, but as a distinction between two internally consistent systems.

Alpha organizations operate on a command-and-control logic. Decisions are centralized. Authority flows from the top. Performance is managed through targets, incentives, and compliance. Planning is done annually, budgets are fixed, and departments are divided into functional silos. The underlying assumption is that complexity can be managed by concentrating intelligence at the top and cascading instructions downward.

Beta organizations operate on a decentralized, networked logic. Decision-making is distributed to the teams closest to the work. Performance emerges from market interaction, not from hitting internally prescribed targets. Structure is organized around value creation, not around reporting lines. The underlying assumption is that complexity is best handled by the people who encounter it directly, not by those who observe it from a distance.

Dimension	Alpha (Command-and-Control)	Beta (Decentralized Network)
Authority	Centralized at the top	Distributed to the periphery
Structure	Hierarchical pyramid	Center-periphery network
Decision-making	Manager-driven	Team-driven, market-informed
Performance	Fixed targets, incentives	Relative targets, intrinsic motivation
Planning	Annual budgets, long-range forecasts	Adaptive, rhythm-based
Information flow	Filtered through management layers	Transparent, flowing freely
Coordination	Bureaucratic, rules-based	Dynamic, value-creation-based
Success metric	Hitting prescribed targets	Comprehensive organizational fitness

The critical insight of Beta Codex is that these two systems are not compatible. You cannot install Beta principles on top of an Alpha structure and expect coherent results. Telling teams they are “empowered” while retaining centralized budget approval and individual performance incentives creates contradiction, not transformation. Beta Codex is a coherent system, and it asks organizations to choose which system they are operating, rather than trying to blend incompatible logics.

Origins: From Beyond Budgeting to Beta Codex

Beta Codex did not emerge in a vacuum. Its intellectual roots trace back to the Beyond Budgeting movement, which began in the late 1990s when a group of researchers and practitioners started questioning why organizations continued to rely on annual budgets, fixed targets, and command-and-control management, practices that consistently produced gaming, short-termism, and rigidity.

The Beyond Budgeting Round Table (BBRT), founded in 1998, studied organizations that had abandoned traditional budgeting and found that the most successful ones had not merely changed their financial processes; they had changed their entire management model. The research revealed that budgets were not the root problem. They were a symptom of a deeper issue: a centralized, plan-and-control approach to organizing work that was fundamentally mismatched to complex, dynamic environments.

Niels Pfläging, a management thinker and author, was deeply involved in this research. Over the course of the 2000s, he synthesized the Beyond Budgeting findings with insights from systems theory, complexity science, and organizational design to articulate a more comprehensive framework. In 2008, Pfläging and the community around him rebranded the work as Beta Codex and founded the BetaCodex Network, an open-source community dedicated to advancing decentralized organizational principles.

The rebranding was intentional. “Beyond Budgeting” suggested the framework was primarily about financial management. In reality, it was about the entire management model: how authority is distributed, how decisions are made, how performance is understood, and how organizations relate to their markets. “Beta Codex” captured this broader scope: a codex of principles for building Beta organizations, as distinct from Alpha ones.

The BetaCodex Network operates as an open-source community. Its principles are freely available, its resources are shared, and it does not prescribe a single implementation path. This open, non-dogmatic character distinguishes it from more formalized frameworks that require certification, licensing, or adherence to a specific constitution.

The 12 Laws of Beta Codex

The 12 laws are the backbone of Beta Codex. Each law is framed as a contrast (“this, not that”) clarifying what the principle advocates and what it explicitly rejects. They are not a menu from which you select the items that appeal to you. They form an interdependent system: adopting some while ignoring others creates internal contradictions that undermine the whole.

The laws can be understood in three groups: how the organization is structured, how it makes decisions and handles performance, and how it coordinates and adapts.

Structural Laws: How the Organization Is Built

1. Team autonomy: connectedness with purpose, not dependency

Teams are the foundational unit of a Beta organization. They operate with genuine autonomy, not the cosmetic autonomy of a team that is “empowered” but still waits for approval. Autonomy here means that teams are connected to the organization’s purpose and to each other, but they are not dependent on hierarchical permission structures. They can act, decide, and learn from the results of their actions.

2. Federalization: integration into cells, not division into silos

Rather than dividing the organization into functional departments (marketing, engineering, finance), Beta Codex advocates for federalized cells, cross-functional units that contain the capabilities they need to create value. These cells are integrated with each other and with the whole, rather than operating as isolated silos that hand work back and forth across departmental boundaries.

3. Leadership: self-organization, not management

This law does not eliminate leadership. It redefines it. In a Beta organization, leadership is a distributed function that emerges from the work itself, not a position assigned from above. Self-organization means that teams take responsibility for their own coordination, governance, and improvement. Managers as a layer of the hierarchy are replaced by leadership as a shared practice.

Performance Laws: How Success Is Understood

4. All-around success: comprehensive fitness, not mono-maximization

Alpha organizations tend to optimize for a single metric: shareholder value, revenue growth, or cost reduction. Beta Codex argues that this mono-maximization is dangerous. Healthy organizations optimize for comprehensive fitness, balancing financial health, employee engagement, customer satisfaction, social impact, and adaptive capacity. Like a living organism, an organization that maximizes one dimension at the expense of others becomes fragile.

5. Transparency: flow intelligence, not power obstruction

Information in a Beta organization flows freely. Transparency is not a corporate value statement; it is a structural principle. When information is transparent, intelligence emerges from the flow of data through the system. When information is hoarded or filtered, it becomes a tool of power rather than a source of collective intelligence. Transparent information enables teams to make informed decisions without waiting for someone higher up to interpret the data for them.

6. Market orientation: relative targets, not top-down prescription

Traditional organizations set fixed targets from the top: “grow revenue by 15%,” “reduce costs by 10%.” These targets are often disconnected from market reality and create perverse incentives (sandbagging, gaming, short-termism). Beta Codex replaces fixed targets with relative targets, benchmarks compared to market conditions, competitors, and past performance. Teams orient toward market reality, not toward an internally prescribed number that may or may not reflect what the market actually demands.

7. Conditional income: participation, not incentives

Individual performance bonuses and incentive schemes are a cornerstone of Alpha management. Beta Codex rejects them. The evidence against individual incentives is substantial: they narrow focus, encourage gaming, undermine collaboration, and produce anxiety rather than motivation. Beta organizations share success collectively through profit-sharing and participation models, recognizing that value creation is a team and organizational achievement, not an individual one.

Adaptation Laws: How the Organization Learns and Evolves

8. Presence of mind: preparation, not planned economy

Annual budgets and strategic plans create an illusion of control. Beta Codex replaces this with preparation: building the capacity to respond to whatever the market presents, rather than committing to a plan that will be obsolete within months. This is not about having no direction. It is about holding direction lightly and adjusting course as new information arrives.

9. Rhythm: tempo and groove, not fiscal-year orientation

Organizations need rhythm, but not the artificial rhythm of fiscal quarters and annual planning cycles. Beta Codex advocates for natural rhythms tied to the work itself: sprint cycles, market cycles, product cycles. When the calendar dictates the pace, the organization is managing time rather than managing value creation.

10. Mastery-based decision: consequence, not bureaucracy

Decisions should be made by the people with the most relevant knowledge and the closest proximity to the consequences. This is not democracy (everyone votes) or autocracy (the boss decides). It is mastery-based decision-making: the person or team with the deepest understanding of the problem and the most direct stake in the outcome makes the call. Bureaucratic approval chains add delay without adding wisdom.

11. Resource discipline: expedience, not status-orientation

In Alpha organizations, resource allocation is driven by hierarchy and status: the most powerful department gets the biggest budget. In Beta organizations, resources flow to where they create the most value. This requires discipline, a willingness to redirect resources based on market signals rather than internal politics.

12. Flow coordination: value-creation dynamics, not static allocations

Coordination in a Beta organization is dynamic. Resources, attention, and effort flow toward emerging opportunities and away from diminishing ones. This replaces the static allocation model where budgets are fixed for the year and cannot be redirected without bureaucratic processes that take months.

The System Principle

These 12 laws are interdependent. Adopting team autonomy (Law 1) without transparency (Law 5) leaves teams flying blind. Introducing relative targets (Law 6) without removing individual incentives (Law 7) creates contradictory signals. Pursuing flow coordination (Law 12) while maintaining annual budgets (violating Law 8) means the dynamic principle has no structural support.

This is why Beta Codex insists that the laws are a system, not a checklist. Partial adoption does not produce partial results; it produces confusion. Organizations considering Beta Codex should understand this upfront: the commitment is to a coherent model, not to selected practices.

The Peach Model: Center, Periphery, and Why the Edges Lead

The Peach Model is Beta Codex’s structural metaphor, a way of visualizing how a decentralized organization is actually organized. It replaces the pyramid with a peach.

The Metaphor

In a traditional pyramid, the top is where decisions are made and the bottom is where work gets done. Information and authority flow vertically. The people at the base, those closest to customers, markets, and the actual work, have the least power.

The Peach Model inverts this. Imagine a peach:

• The periphery (the flesh of the peach) consists of cells that have direct contact with the market: customer-facing teams, sales units, product teams, service delivery groups. These are the value-creating parts of the organization. They interact directly with customers, partners, and external stakeholders. They see market signals first. They learn first. They adapt first.

• The center (the pit of the peach) consists of cells that do not have direct market contact: support functions like HR, finance, legal, IT infrastructure, and internal services. These cells exist to serve the periphery, not to control it.

The Periphery Leads

This is the most counterintuitive, and most important, principle of the Peach Model: the periphery leads. The center serves.

In a traditional organization, the center (headquarters, C-suite, corporate functions) sets strategy, defines targets, and tells the periphery what to do. The Peach Model reverses this relationship. The periphery is where the organization encounters reality. Market intelligence, customer needs, competitive dynamics: these are sensed at the edges, not at the center. The periphery learns directly from the market. The center learns from the periphery. The center cannot learn directly from the market because it has no direct contact with it.

This inversion has practical consequences:

• Strategy emerges from the periphery. Instead of the center handing down a five-year strategy, strategic direction is shaped by what peripheral teams learn from market interaction.
• The center provides services, not instructions. Finance provides financial analysis to help peripheral teams make decisions; it does not dictate spending limits. HR supports talent development in the periphery; it does not enforce standardized performance reviews.
• Functional integration happens in the periphery. Rather than splitting expertise into departments (a marketing department, an engineering department, a sales department), the Peach Model integrates functions into peripheral cells. A customer-facing cell contains the marketing, engineering, and operational capabilities it needs to serve its market autonomously.

Why It Works

The Peach Model works because it aligns organizational structure with the flow of value and information. Value is created at the edges, where the organization meets its market. Information is freshest at the edges, where signals have not yet been filtered, summarized, or delayed by management layers.

When the periphery leads, the organization becomes adaptive. Teams that see a market shift can respond to it directly, without waiting for the signal to travel up a hierarchy and a decision to travel back down. When the center serves, support functions become genuine enablers rather than bureaucratic gatekeepers.

“During the process of mapping out the way our company currently worked with Peerdom, it was like a revelation…we learned things about our 20 year old company that we never saw before and were so much the richer for it.” — Sean Daly, Director, SOLID Structures & Infrastructure

Beta Codex Compared to Other Organizational Frameworks

Beta Codex is one of several frameworks that challenge traditional hierarchy. Each has a different origin, emphasis, and implementation style. Understanding the distinctions helps organizations choose the approach, or combination of approaches, that fits their context.

Dimension	Beta Codex	Holacracy	Sociocracy	Teal	Agile at Scale	RenDanHeYi
Origin	Beyond Budgeting research (2008)	Brian Robertson (2007)	Gerard Endenburg (1970s)	Frederic Laloux (2014)	Various (SAFe, LeSS, Spotify)	Haier / Zhang Ruimin (2005)
Core metaphor	Peach (center-periphery)	Nested circles	Linked circles	Evolutionary organism	Tribes, squads, guilds	Microenterprises
Authority model	Periphery leads, center serves	Constitution-governed roles	Consent-based circles	Self-management + wholeness	Team-level autonomy	Entrepreneurial autonomy
Decision-making	Mastery-based	Integrative process	Consent (no objections)	Varies by practice	Team-level	Market-driven
Structure	Federated cells	Roles and circles	Circles with double-linking	Emergent, principle-based	Cross-functional teams	Microenterprises as platforms
Formality	Principles-based, adaptive	High (formal constitution)	Moderate (principles + process)	Low (philosophical)	Moderate to high	Moderate
Adoption path	Systemic shift (all 12 laws)	Constitutional adoption	Gradual, circle by circle	Cultural evolution	Framework-specific rollout	Enterprise restructuring
Key strength	Market-aligned, anti-bureaucratic	Governance clarity	Inclusive decision-making	Humanistic philosophy	Delivery speed	Customer-driven innovation
Primary risk	Requires full commitment to system	Rigidity, over-governance	Decision fatigue	Vagueness, hard to operationalize	Framework bloat	Scale requirements

Key Distinctions

Beta Codex vs. Holacracy: Holacracy provides a detailed governance constitution with specific rules for meetings, proposals, and role definitions. Beta Codex operates at a higher level of abstraction: it defines principles rather than processes. An organization can practice Beta Codex using holacratic governance within its cells, or it can use entirely different governance mechanisms. The two are not mutually exclusive, but they operate at different levels. For a detailed walkthrough of holacratic practice, see the holacracy tools and practices guide.

Beta Codex vs. Sociocracy: Sociocracy’s strength is its consent-based decision process and double-linking structure. Beta Codex is less prescriptive about how decisions are made within cells. It cares that decisions are made by those with mastery and proximity, but it does not mandate a specific process. Organizations that value sociocratic decision-making can practice it within a Beta Codex structure. For more on sociocratic principles, see the sociocracy guide.

Beta Codex vs. Teal: Teal organizations, as described by Frederic Laloux, share many values with Beta Codex: self-management, wholeness, evolutionary purpose. The difference is in specificity. Teal is a philosophical orientation. Beta Codex is a codified set of principles with a specific structural model (the Peach). Organizations inspired by Teal often find that Beta Codex provides the structural framework to operationalize Teal’s aspirations.

Beta Codex vs. Agile: Agile frameworks (Scrum, SAFe, LeSS) focus primarily on delivery: how teams build products and deliver value. Beta Codex addresses the entire organizational model: structure, authority, performance, coordination, and strategy. Agile practices can operate within Beta Codex cells. The two are complementary, not competing.

Beta Codex vs. RenDanHeYi: Both models emphasize autonomous units with direct market connection. RenDanHeYi, pioneered at Haier, organizes the company into microenterprises that operate like internal startups. Beta Codex’s Peach Model and RenDanHeYi’s microenterprise structure share the same insight: value creation happens at the edges. The difference is primarily cultural and contextual. For organizations exploring RenDanHeYi, see the RenDanHeYi tools and visualization guide.

The takeaway: these frameworks are not mutually exclusive. Many organizations combine Beta Codex’s structural principles with sociocratic decision processes, agile delivery practices, and holacratic role definitions. What matters is internal coherence. Whichever combination you adopt, the pieces should reinforce rather than contradict each other.

Implementing Beta Codex: A Practical Path

Adopting Beta Codex is not an overnight event. It is a systemic shift that requires deliberate, phased action. The following steps provide a practical path forward, informed by both the theory and the experience of organizations that have made the transition. Notably, IDEAL-Werk restructured its entire organization using Beta Codex principles in just 11 days, demonstrating that when commitment is clear, transformation can happen faster than most people expect.

Step 1: Understand the Current System

Before changing anything, map what exists. Identify where decisions are currently made. Trace how information flows. Understand which teams have market contact and which do not. This mapping exercise reveals the actual operating model, which often differs significantly from the official org chart.

This is not a cosmetic exercise. You cannot build a center-periphery structure without understanding which teams are genuinely peripheral (market-facing) and which are genuinely central (support-oriented).

Step 2: Identify the Periphery

Determine which teams have direct contact with the market: customers, partners, external stakeholders. These are your peripheral cells. They might be sales teams, product teams, service delivery groups, or customer success units. The common thread is direct market interaction: they see signals, respond to needs, and create value at the point of contact.

Step 3: Redefine the Center’s Role

Support functions (HR, finance, legal, IT) become the center. Their role shifts from controlling to serving. This is often the most difficult cultural shift, because support functions in traditional organizations derive their influence from gatekeeping: controlling budgets, approving decisions, enforcing compliance.

In a Beta organization, the center’s purpose is to make the periphery more effective. Finance provides analysis and insight, not spending limits. HR supports talent development, not standardized evaluation processes. Legal provides guidance, not veto power.

Step 4: Start With One Team

Pilot Beta Codex principles with a single peripheral cell. Give them genuine autonomy: authority over their own decisions, transparency into the information they need, and relative targets tied to market performance rather than internally prescribed numbers. Observe what happens. Learn from the friction points. Adjust before scaling.

Step 5: Shift to Relative Targets

Replace fixed, top-down targets with relative benchmarks. Instead of “grow revenue by 15%,” the question becomes: “How are we performing relative to our market, our competitors, and our own trajectory?” Relative targets are honest. They cannot be gamed by negotiating easy goals, and they remain relevant regardless of how market conditions shift.

Step 6: Remove Individual Incentives

This step often meets the most resistance, but it is essential. Individual bonus schemes undermine collaboration, encourage gaming, and focus attention on the wrong things. Replace them with participation models: profit-sharing, team-based recognition, or conditional income structures that reward collective success.

Step 7: Federate Into Cells

As the pilot succeeds, expand the model. Organize the periphery into functionally integrated cells, cross-functional teams that contain the capabilities they need to serve their market segment. Connect the cells to each other and to the center through transparent information flows, not through reporting hierarchies.

Step 8: Make the Structure Visible

A decentralized structure is useless if nobody can see it. Map the organization so that every team, every role, and every relationship is visible and navigable. This is where organizational mapping becomes essential, not as a documentation artifact, but as a living tool that people use daily to understand who does what, who to talk to, and how work flows.

“Smart, simple, flexible and transparent. A game-changer for truly agile organizations.” — Germain Augsburger, BKW

Step 9: Iterate and Evolve

Beta Codex is not a destination. It is a way of operating that evolves as the organization and its market evolve. Regularly revisit the balance between center and periphery. Check whether the 12 laws are reinforcing each other or whether gaps have emerged. Treat the organizational structure as a living system that requires ongoing attention, not a project with a completion date.

Making the Peach Visible: Tools for Beta Organizations

One of the practical challenges of any decentralized model is visibility. In a traditional hierarchy, reporting lines are clear. You can draw them on a whiteboard. In a center-periphery network, the relationships are richer, more dynamic, and harder to represent with boxes and lines.

This is where organizational mapping tools become important. A Beta organization needs a way to visualize:

• Which teams are peripheral (market-facing) and which are central (support-oriented).
• How cells relate to each other: dependencies, collaborations, information flows.
• Who holds which roles within each cell and across the organization.
• How the structure has changed over time as the organization adapts.

Peerdom’s circle and tree views naturally map to center-periphery structures. You can represent peripheral cells as autonomous circles with their own roles and accountabilities, and central cells as support functions connected to the periphery they serve. The network view makes the relationships between cells visible, not just reporting lines, but the actual flow of collaboration and value creation.

This matters because the Peach Model only works when people can see it. If the structure lives only in someone’s head, or in a slide deck from last year’s offsite, it is not operational. A living organizational map makes the peach visible to everyone: new hires, existing team members, and external partners.

“Peerdom is like ‘lifting the fog’ from an area you can’t quite see.” — Jon Barnes, Peerdom Companion

For organizations exploring any form of decentralized structure, whether Beta Codex, holacracy, sociocracy, agile, or a hybrid, the fundamental need is the same: make the structure explicit, navigable, and alive. For more on why dynamic org charts outperform static ones, and how role-based governance supports distributed authority, those guides cover the practical details.

Frequently Asked Questions

What is the difference between Beta Codex and holacracy?

Beta Codex is a set of organizational principles built around the center-periphery (Peach) model and the 12 laws. It defines what a decentralized organization looks like at a structural and philosophical level, but it does not prescribe specific governance processes. Holacracy is a detailed governance framework with a formal constitution, specific meeting formats, and defined roles. An organization could practice Beta Codex principles while using holacratic governance within its cells. Beta Codex operates at the organizational design level; holacracy operates at the governance process level.

Is Beta Codex compatible with agile?

Yes. Agile frameworks (Scrum, Kanban, SAFe, LeSS) focus on how teams deliver work. Beta Codex focuses on how the organization is structured, how authority is distributed, and how performance is understood. The two operate at different levels and are naturally complementary. Agile delivery practices can operate within Beta Codex’s peripheral cells, giving teams both structural autonomy and effective delivery methods.

Do all 12 laws need to be adopted at once?

Beta Codex is explicit about this: the 12 laws are an interdependent system. Adopting some while ignoring others creates internal contradictions. For example, giving teams autonomy (Law 1) while maintaining individual performance bonuses (violating Law 7) sends conflicting signals. That said, implementation is usually phased. Organizations introduce the laws progressively, but with the understanding that the full system is the destination, not a partial adoption.

What is the Peach Model in simple terms?

The Peach Model replaces the traditional organizational pyramid with a peach. The outer part (the periphery) represents teams that interact directly with customers and markets; they are where value is created. The inner part (the center) represents support functions like HR, finance, and IT; they exist to serve the periphery. The key principle is that the periphery leads and the center serves, which is the opposite of how most traditional organizations operate.

How does Beta Codex handle leadership?

Beta Codex does not eliminate leadership; it distributes it. Law 3 (Leadership) replaces management as a hierarchical position with self-organization as a shared practice. Leadership in a Beta organization is a function, not a title. It emerges from the work and is exercised by the people with the relevant knowledge and proximity to the problem. This does not mean there are no leaders. It means that leadership is decentralized and context-dependent rather than concentrated in a management layer.

Can large enterprises adopt Beta Codex?

Yes. Beta Codex was influenced by research into large organizations that had already abandoned traditional budgeting and command-and-control management. The Peach Model scales through federalization: the organization consists of cells that are autonomous but connected. Large enterprises may have dozens or hundreds of peripheral cells, each serving a different market segment, with central functions shared across the network. The key challenge at scale is maintaining transparency and coherence, which is why organizational mapping tools become essential.

What is the connection between Beta Codex and Beyond Budgeting?

Beta Codex grew directly from the Beyond Budgeting movement. The Beyond Budgeting Round Table (BBRT), founded in 1998, studied organizations that had abandoned traditional budgets and discovered that the most successful ones had changed their entire management model, not just their financial processes. Niels Pfläging synthesized these findings into a broader framework, which was rebranded as Beta Codex in 2008 to reflect that it addresses the complete organizational model, not just budgeting.

How do you measure success in a Beta organization?

Beta Codex replaces fixed, internally prescribed targets with relative performance measures. Success is evaluated against market conditions, competitor performance, and the organization’s own trajectory, not against a number negotiated in a budget meeting. Law 4 (All-around success) also broadens what counts as success: instead of maximizing a single metric (like shareholder value or revenue), Beta organizations measure comprehensive fitness across financial health, customer satisfaction, employee engagement, and adaptive capacity.

Start mapping your organization

Whether you are exploring Beta Codex, the Peach Model, or any approach to decentralized organization, the first step is the same: make your structure visible. Map your teams, roles, and relationships so that everyone can see how the organization actually works, not how a slide deck says it should work.

• Try the Beta Codex template: pre-configured with independent cells, decentralized structure, and no coordination roles. Built for organizations applying Beta Codex or Beyond Budgeting principles.
• Start mapping from scratch: Peerdom supports Beta Codex, sociocracy, holacracy, agile, Teal, RenDanHeYi, and hybrid models. Map your center and periphery, your circles and roles, your cells and networks, all in one platform.
• Browse all templates: explore templates for Beta Codex, sociocracy, holacracy, and more.
• Not sure where to start? Book a demo and we will walk through how your organization’s structure maps to the model you are exploring.