This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
When we hear the word “anarchy,” most people think of chaos and disorder. But Andrew Harmel-Law, author of O’Reilly’s “Facilitating Software Architecture,” proposes a radically different interpretation — one that could transform how software organizations function. In a this episode of Software-Architektur im Stream, Harmel-Law explored anarchistic principles as a viable alternative to traditional hierarchical organizational structures, challenging our assumptions about how development teams should operate.
Redefining Anarchy for Software Teams
Rather than synonymizing anarchy with chaos, Harmel-Law distinguishes between two definitions. While one describes disorder and absence of authority, the more relevant interpretation for software development refers to voluntary, self-organized structures that reject centralized hierarchical control. This distinction proves crucial because it reveals what many successful software organizations already practice intuitively.
Anarchistic organizations share four key characteristics: they’re voluntary, short-lived, functional, and small. These principles might seem counterintuitive in enterprise software development, yet they address persistent organizational pain points. How many teams struggle with ceremonies that don’t serve their purpose? How many developers feel trapped in architectural review boards and approval chains? These symptoms suggest that traditional hierarchy isn’t serving modern software development needs.
The Four Principles in Practice
Voluntariness doesn’t mean everyone participates equally in organizational design. Rather, it enables those who wish to step up and take responsibility to do so. Harmel-Law’s experience managing a 90-person team at Capgemini demonstrated this principle: when he devolved responsibility for recruitment, sales engagement, and team management, people voluntarily took on these “glue roles” and excelled precisely because they chose to.
Temporary structures counterintuitively prevent knowledge silos and the “bus factor” of one — the problem that one person’s departure brings critical operations to a halt. By rotating roles and distributing expertise across teams, organizations build resilience. The Quakers’ practice of limiting leadership positions to three years reflects deep psychological insight: longer tenures breed vested interests that resist necessary change.
Functionality serves as the ultimate metric. Rather than adhering to dogmatic team sizes, anarchistic organizations ask: “Is this structure doing what it needs to do?” Some teams might be smaller, others larger — what matters is whether they genuinely serve organizational goals.
Smallness doesn’t prevent scaling. Instead of imposing hierarchical layers, emerging federations of autonomous teams coordinate around shared business problems. This mirrors how microservices architecture avoids monolithic integration buses.
Building Trust Without Abandonment
Harmel-Law addresses the elephant in the room: managers and shareholders derive authority from hierarchy. How can you convince control-oriented stakeholders to embrace anarchistic principles?
The answer lies in framing and experimentation. Instead of invoking “anarchy,” speak of self-managing, responsive organizations that adapt quickly to market changes. Start small — perhaps by allowing any team member to propose architectural decisions or rotating technical leadership. Prove the model works through measurable improvements: better retention, higher utilization, reduced absence due to illness.
Netflix provides a compelling case study. By constantly experimenting with removing organizational policies — trusting employees to make ethical expense decisions, empowering non-executives to make strategic pivots — Netflix maintains minimal structure while maximizing responsiveness. This approach doesn’t contradict accountability; rather, it distributes it widely.
The AI Dimension
As artificial intelligence reshapes software development, Harmel-Law advocates conscious adoption. LLMs should expand options and facilitate human decision-making, not replace it. The anarchistic lens demands awareness: What power are we ceding? Where does genuine autonomy matter? By maintaining critical consciousness while leveraging AI’s capabilities, organizations can harness these tools without abdicating responsibility.
Conclusion
Anarchistic principles offer not utopian solutions but practical frameworks for organizations struggling with hierarchical constraints. The question isn’t whether to abandon structure entirely, but whether current structures genuinely serve organizational and human needs. By experimenting with voluntary participation, temporary assignments, functional accountability, and small autonomous teams, software organizations can build more responsive, resilient, and ultimately more human-centered systems. Start small, remain skeptical, experiment boldly—and discover whether your organization needs less hierarchy and more purpose.