What the Holacracy? Basics and Benefits of Flat Organizations in Development — Open Source CXO Ep. 19 | Active Logic
Most software organizations run on traditional hierarchies — managers, directors, VPs — where authority flows from the top. But what happens when you strip that away? In this first of two episodes with Geoff Vandegrift, CTO of Ad Astra, the conversation dives deep into holacracy: a self-management system that distributes authority to roles rather than individuals, and what it looks like in practice for software development teams.
Ad Astra’s mission — helping higher education institutions optimize course offerings and improve student graduation rates — provides an interesting backdrop for this organizational experiment. When your product directly impacts student outcomes, the stakes of how you structure your engineering team are higher than typical SaaS.
Key Insight: What Holacracy Actually Is (And Isn’t)
Holacracy is often misunderstood as “no managers” or “everyone does whatever they want.” In practice, it’s more structured than traditional hierarchy — just structured differently. Instead of people holding permanent positions of authority, authority is distributed to roles that can be held by anyone and change frequently.
Key principles that Geoff describes:
- Roles, not job titles. A person might hold multiple roles (e.g., “API Lead,” “Incident Responder,” “Onboarding Mentor”) and can add or drop roles as the organization’s needs change.
- Distributed decision-making. Decisions are made by the person holding the relevant role, not escalated to a manager. This dramatically speeds up the pace of routine decisions.
- Governance through process. Changes to roles and team structures happen through defined governance meetings, not executive fiat.
- Tension-driven evolution. When someone encounters a “tension” — a gap between how things are and how they could be — they propose a change through the governance process.
Key Insight: Self-Managed Teams in Practice
The most practical part of the conversation covers how Ad Astra’s engineering teams operate day-to-day under this model. Developers take ownership of their work in a way that traditional organizations struggle to achieve. Code review isn’t a gate controlled by a senior engineer — it’s a shared responsibility. Technical direction emerges from team consensus rather than architect mandates.
The benefits are real: faster decision-making, higher engagement, and a sense of ownership that drives quality. When every developer feels like an owner rather than an executor, the quality of their work improves.
But Geoff is honest about the challenges too. Self-managed teams require a level of maturity and communication skill that not every individual has. Conflict resolution, which a traditional manager handles, becomes a team responsibility. And accountability — figuring out what happens when someone isn’t performing — is harder without a clear reporting structure.
Key Insight: Cloud-Native Architecture and Organizational Structure
An interesting thread in the conversation connects organizational structure to technical architecture. Ad Astra’s move to cloud-native, serverless architecture parallels their organizational shift toward flat teams.
This isn’t coincidence. Conway’s Law — the observation that systems tend to mirror the communication structures of the organizations that build them — works in both directions. A decentralized team naturally builds decentralized systems (microservices, serverless functions, event-driven architectures). A hierarchical team naturally builds monolithic systems with centralized control.
For organizations considering architectural modernization, the implication is clear: changing your technology without changing your team structure will create friction. The architecture and the organization need to evolve together.
Key Insight: When Flat Structures Break Down
Geoff identifies the scenarios where holacracy and flat structures struggle:
- Crisis situations. When the production system is down, you don’t want governance meetings — you want someone clearly in charge coordinating the response.
- Strategic direction. Self-managed teams are excellent at execution but can struggle with long-term strategic alignment. Someone needs to set the destination even if the team chooses the route.
- Performance management. Peer-based accountability sounds great in theory but is uncomfortable in practice. Most people avoid difficult conversations with colleagues.
- Scaling. Flat structures that work beautifully with 12 people can collapse at 40. The informal communication channels that replace formal hierarchy don’t scale linearly.
Key Insight: Higher Education Technology Challenges
The conversation also covers Ad Astra’s domain: helping colleges and universities optimize course scheduling to improve graduation rates. This is a data and analytics challenge at its core — analyzing enrollment patterns, prerequisite chains, classroom availability, and student behavior to recommend optimal course offerings.
The impact is significant: when students can’t get into required courses, they extend their time to degree (costing them money) or drop out entirely. Optimizing scheduling is one of the highest-leverage interventions a university can make.
Takeaways
- Holacracy is more structured than hierarchy, not less. It distributes authority to roles through defined processes, not chaos.
- Self-management requires maturity. Not every team is ready for it. Invest in communication skills and conflict resolution training.
- Organizational structure and architecture are connected. If you want microservices, you need autonomous teams. If you want autonomous teams, you need distributed authority.
- Flat structures have failure modes. Know when to invoke command-and-control (crises, strategic decisions) even in a flat organization.
- Start small. Pilot holacracy with one team before rolling it out organization-wide.
