Company as Code

My friend Jordan Husney sent me Daniel Rothmann's "Company as Code", which proposes treating your entire organizational structure as version-controlled code.

What? What would that look like?

• It would look like a company manifest. A single, declarative source of truth for how the organization works—who reports to whom, what policies apply where, which roles carry which accountabilities—written in a purpose-built programming language (a "domain-specific language," or DSL) modeled after infrastructure-as-code tools like Terraform.
• It would look like diff-able governance. Policy changes can be tracked like code changes, so you can see who changed what, when, and why. Charthop already “does this,” but without "all the other org context" built into a diff.
• It would look like a staging environment for your org. Want to model what happens if you merge two departments? If this existed, you’d spin up a branch, run the impact analysis, and merge when ready. (Again a thing Charthop does but without "awareness” and with a bunch of seemingly GUI-related latency. Funny that we forgive this kind of latency for LLMs but not for client-server interactions.)
• It would feel like compliance with a simple query. Rothmann's team spent "hundreds of additional person-hours" prepping for ISO 27001 by gathering evidence and mapping controls to policies so that they could prove to auditors that the company does what it says it does. If the policies were machine-readable from the start, most of that becomes a database query: show me every control that maps to Appendix A.8, and the last time each was reviewed. Minutes are better than weeks!

Context

This idea has a lot of precedent. Holacracy's GlassFrog has been storing governance as structured data since the early 2010s—roles, circles, accountabilities, domains, all queryable. The entire DAO movement—Aragon and others—took it further: the organization is the code, executed on-chain. On the more pragmatic side, Blue Yonder manages its GitHub organization structure as JSON files in a GitOps repo—teams, permissions, segments, all submitted as pull requests. Team Topologies' TeamAPI defines team interfaces as structured specs. The Policy as Code movement has tools like Open Policy Agent (OPA) that let you write access controls and compliance rules as code instead of Word documents. Zhamak Dehghani's Data Mesh even bakes "federated computational governance" into its architecture—dual human/machine-readable governance artifacts, checked into Git.

My self-promotional angle

This connects to several ideas in Hidden Patterns, but the most important is Transparency. Most organizations run on a fog of half-remembered org announcements and outdated wiki pages, leading to questions that are really just unsure statements, like... "I think Clay owns thaaat? Now?" A company manifest would make the actual operating structure legible to everyone.

But my org charts are already in Google Docs!

With transparency comes easier adherence to the Rule of Law. When governance is prose in a Google Doc, it’s not always clear whether its words are currently in force, and over whom. When it's code that's object-oriented, version-controlled, and auditable, I think it's probably easier to can hold everyone to the same standards because the standards are inspectable and tied to roles.

Unresolved issues

Rothmann is honest about the core tension: "Buildable? Yes. Viable? I don't have the answer." Organizations are messy because humans are interesting. A Kubernetes cluster doesn't have feelings about being redeployed. People do, and better file formats don’t change how we feel about a merger between two departments.

There's also the question of adoption. It's still hard to get leaders to use Tableau; getting them to express reporting relationships in a programming language is a different kind of behavior change. Maybe this changes with the magic that comes from LLMs in the command line? Maybe not.

What to watch

• Who builds it first. This feels like a space where a startup (or an ambitious internal tools team) could assemble existing pieces into something usable.
• Whether AI changes the equation. If your org structure is machine-readable, an LLM can reason about it. "Show me every role that touches customer data." "What happens to escalations if we merge these two teams?" The combination of structured org data and AI querying is powerful.
• Adoption path. Does this start with compliance-heavy industries (finance, healthcare) where the pain of audit prep is acute enough to justify the investment? Or does it grow bottom-up from engineering organizations that already live in Git?