Our distributed company is a garden
How we changed (and continue to change) the way we work
Ever heard of a company that runs itself?
In this essay, we’ll talk about how decentralizing a company is like gardening, how we’re doing there, and where we’re excited to grow.
The Crystal Lattice
You know a bit about the Crystal Lattice: our effort to distribute authority at Sanctuary Computer.
Here’s Hugh in Our open source 2020 Profit & Loss:
To provide a better place to work, this philosophy treats project teams and internal processes like nodes in a distributed system: each operates with suggested operating procedures; while at the same time giving individuals within each node more autonomy, ownership, and freedom to operate how they prefer, learning and growing in the process.
There are some simple mechanisms for those nodes to escalate issues when support is needed and report back to the team at large, but for the most part, The Crystal Lattice is designed to decentralize how we do things, without adding traditional organizational bloat like layers of middle management and HR departments 🤢.
Every organization has an operating system: assumptions, rules, and practices that guide the way they work. And most organizations have a legacy operating system: the organizational equivalent of MS-DOS. Their rules slow down teams. Their assumptions were formed twenty years ago. And their practices aren’t actually aligned with the copy on their “Our Values” page.
We can’t be a distributed organization with a legacy OS. If we did, we’d perpetuate the very assumptions about work that we disagree with:
People avoid responsibility and need constant direction.
Projects need to be supervised at every step.
Disagreements are immediately shut down.
Increasing shareholder value is the sole purpose of a company.
And when shit hits the fan, we blame others and don’t look at ourselves.
To become a distributed organization, we have to update our organizational OS. Hence, the Crystal Lattice.
Maximize Cohesion, Minimize Coupling
As technologists, we’re intrigued by how distributed systems work. What’s rad is that we can apply our knowledge of distributed systems to designing a distributed company.
One principle of a good distributed system: maximize cohesion, minimize coupling.
From Prioritize cohesion, then uncouple:
In software engineering, coupling is the extent to which modules are dependent on each other.
In org design, coupling is the extent to which roles, teams, and processes are dependent on each other.
Software engineering contrasts coupling with cohesion: the extent to which the elements inside a module belong together.
In org design, cohesion is the extent to which our roles, teams, and processes serve the org’s purpose.
In a distributed system, we typically want to minimize coupling. In a distributed company, we also want to minimize coupling (dependencies).
In software, low coupling is often (but not always) a sign of a well-structured system. In org design, low coupling is often (but not always) a sign of a well-structured organization.
So we maximize cohesion. And minimize coupling.
To maximize cohesion, we design roles, teams, and processes that each does one thing well, rather than many things not-so-well. This takes a page from The Basics of Unix Philosophy:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
To minimize coupling, we design each role, team, and process so that it can run autonomously. More from Unix Philosophy:
To make programs composable, make them independent. A program on one end of a text stream should care as little as possible about the program on the other end. It should be made easy to replace one end with a completely different implementation without disturbing the other.
We’re still (un)learning!
Distributed systems and distributed organizations aren’t 100% analogous. People aren’t programs. We’re complex, emotional, and unpredictable. And when thirty-two people work towards the same goal, we create a complexity soup.
We’re not a perfectly cohesive org. “So how does Sanctuary, XXIX, and Hydraulics form one company?” And we still have dependencies (coupling). We still have moments of making unilateral decisions, seeking senior input when feeling unsure, and being uncomfortable with our own autonomy.
Being in a new OS is hard! I believe in radiating intent over asking for permission. But oftentimes I still catch myself asking for permission!
Adam Grant, an organizational psychologist, says that we lose a part of ourselves when we get rid of old beliefs. From Think Again:
...we often prefer the ease of hanging on to old views over the difficulty of grappling with new ones. Yet there are also deeper forces behind our resistance to rethinking. Questioning ourselves makes the world more unpredictable. It requires us to admit that the facts may have changed, that what was once right may now be wrong. Reconsidering something we believe deeply can threaten our identities, making it feel as if we’re losing a part of ourselves.
We’re still learning. But boy, are we evolving.
Distributed organizing as gardening
We try to approach organizational change like gardening, rather than running a factory.
This is a huge difference from the way leaders usually run their companies. Inexperienced leaders are chessmasters: predicting and directing every move. Their organizations are optimized for execution, rather than learning. And as Venkatesh Rao puts it, leaders try to make their organizations legible: serving the leader’s needs over the collective’s needs.
It takes a while for a leader to shift from chessmaster to gardener. From The Overlap #22:
Organizations aren’t machines we can control. Organizations are gardens that we tend to, care for, and bring into being.
In Images of Organization, Gareth Morgan shares two different metaphors:
Organization as Organism: Organizations are containers for humans and practices to live, breathe, and evolve. And organizations themselves live, breathe, and evolve.
Organization as System of Change and Flux: Organizations are like whirlpools. Or eddies in a flowing stream. Never static, always dynamic. They can be stable and rigid. They can also be unpredictable, random, and chaotic. And will always fluctuate between rigid and random.
Sanctuary is a garden. A garden that contains organisms. A garden that is changing and fluctuating. Our practices evolve in continual alignment towards our principles. Our way of working is always changing, always evolving.
Three ways we tend to our organization’s growth
Now, I’d like to share three tangible things we do to tend to our org. We’ve written about each practice in other posts, so I won’t go too in-depth.
1/ Any team member can propose a change to the way we work.
Any member of the org can propose an experiment: a small, testable change that can give us data on whether it’s a valuable change or not. This is very different from how individual contributors raise concerns and management fixes them. People have the autonomy (and responsibility, if you ask me!) to propose and see through a solution when they see an opportunity for change.
Read more about it in “Evolving through experiments” in Hugh’s 2020 P&L post.
2/ Consent-based decision-making.
For experiments that might cause irreversible harm, we use Integrative Decision-Making (IDM) to make them safe to try. Rather than designing the perfect experiment, we design for safe, so that we minimize its risk and learn from it as quickly as possible. Our studio producer and budding strategist Iz wrote about IDM in Our New Parental Leave Policy.
3/ Democratizing information.
We prefer pushing information over pulling it.
Here’s from our “How We Communicate” doc in Notion:
I used to struggle with “push over pull.” I used to advise teams to “pull” instead of “push.” Most large organizations suffer from too much information being pushed and not knowing exactly where to pull.
But Sanctuary’s problem space was a bit different from a large company’s. We used to expect team contributors to pull information from team leads. This resulted in team leads being the only source of information. We needed more meetings to create shared context. Our org design’s coupling was high.
When we transitioned into being a remote company when the pandemic broke out, we noticed that information silos were even more apparent. Making guidance explicit is even more important in remote work.
So, we use “push over pull” to encourage sharing and documenting context.
Here’s what I learned: It’s less about “pull over push” vs “push over pull.” It’s more about the positive change created as a result of the principle. By pushing over pulling, we’re eliminating information silos and communicating proactively. Who cares whether “push” or “pull” is better?
Where we can grow
In the spirit of transparency, here are three areas we want to grow in.
1/ Clarifying the roles & responsibilities of everyone on the team.
In a highly autonomous team, you still need to know a) who does what and b) who has the final say on what. Autonomy does not mean everyone does everything. Autonomy means everyone is free to contribute towards the team’s purpose.
Our project teams have tried two ways of clarifying roles and responsibilities. One practice XXIX does are RACI matrices. RACI aligns a team on who is:
Responsible: owns the final decision.
Accountable: moves the project forward.
Consulted: shares input when asked. But doesn’t have the final call.
Informed: needs to know the high-level status of the project.
At Manhattan Hydraulics, we clarify who does what at the studio level.
We use role chartering, a practice many Sociocratic teams use. We define our roles (nodes). Each role has few components:
Purpose (remember, design each node to do one thing well)
Accountabilities
Decision Rights (if needed)
For example, Brendon holds our Staffing Tzar role. Sanctuary and XXIX know who to go to understand when members at Hydraulics are available and interested in new work coming in.
2/ Creating more defaults so that teams have the tools to get work done.
The Rails Doctrine believes in Convention over Configuration: giving developers a way of writing code. So that their attention is freed up to tackle nontrivial problems.
I prefer the word defaults over convention. Convention feels a bit too constraining. Defaults imply that there is room for you to deviate from the convention, when necessary.
One default that we’re creating is a “tech lead toolkit” — all the tools, tips, and practices a new Tech Lead can use when they start their first Tech lead role on a client project.
Another default we’ve introduced: User Manual To Mes in our project team kickoffs. These help teams kickoff projects with an understanding of each other’s quirks, preferences, and ways of giving and receiving feedback.
3/ Revising our Individual Contributor & Leadership Skills in our Skill Tree.
Our Individual Contributor and Leadership tracks on the Skills Tree can use some work. They reflect behaviors from the old way of working that assume people need to be managed, controlled, and directed.
We intend to revise those skills so that they reflect what good leadership looks like in a distributed organization. Things like:
Noticing a problem/opportunity and proposing an experiment to solve it
Knowing how to offer and give helpful feedback
Knowing how to receive feedback
Active listening
Helping others get clear on where they want to grow
Coaching (rather than managing) others toward their goals
Makers make for great leaders
An old colleague of mine once said:
Leadership’s job isn’t oversight. It isn’t requirements building. It isn’t even really product direction. It’s creating the tools for making good decisions at every level.
There’s an assumption that once designers and developers become managers, they find it difficult. They’re an expert at making, but a beginner at leading.
I think Sanctuary, Hydraulics, and XXIX are proving this assumption wrong. As designers and developers, we create tools for a living. That includes tools for helping other teams make great decisions. Tools to help their coworkers ask and offer feedback. Tools to help their peers get clear on where they want to grow.
We obsess over making tools that improve the way we work. When we see an opportunity to improve, we upgrade our tools. Or build a new tool, toss the old one, and thank it for serving its purpose (Marie Kondo style).
To lead in a distributed org is to design and redesign tools that help you and your colleagues do your most fulfilling work.
How fascinating of a challenge is that?
Thank you Hugh Francis for feedback on previous versions of this essay!