Header image: “Empty Meetinghouse” by Mike Goren. CC-BY.
As a member of the Religious Society of Friends (AKA Quakers), I’ve got lifelong experience with flat teams. Quaker tradition employs a flat governance structure with deep roots in our equality testimony. Quaker governance is not the same as secular consensus, but a lot of secular consensus processes are adapted from Quaker methods. I’ve been participating in and organizing consensus-based communities since I was a kid.
I love consensus. I love the way that flat teams can bring in ideas and solutions from unexpected places, and the way they encourage people to listen deeply and try their best to understand where other people are coming from. My experience with consensus-based governance is a large part of why I chose to go to a Quaker college and get a degree in conflict resolution, with a concentration in community conflict.
After college, when I started learning to code and got into the tech industry, I was excited to learn that non-hierarchical governance structures have achieved a certain level of acceptance in tech companies and organizations in and around tech, such as open source projects, advocacy groups, and hackerspaces. It felt welcoming to be around people who weren’t going to roll their eyes at the very concept of consensus, or sneer whenever someone said the word “committee.”
In the years since, however, I’ve been on multiple tech- and tech-adjacent flat teams, including “do-ocracies,” “structureless” teams that tried to run on consensus, and teams that evolved from a largely-flat structure into a more traditional hierarchical structure. I’ve moved from IC roles into technical management. And I’ve gained a lot of experience in the ways non-hierarchical structures can go horribly wrong.
Building and maintaining healthy teams is real work that takes time and effort–especially if you’re trying to organize people to get something done. Doing that work within a flat or “leaderless” team can be rewarding–but it takes significantly more emotional labor to build buy-in or consensus than it does to manage a hierarchical team.
If you decide to do away with hierarchy and traditional reporting chains in your organization, you still need to figure out how you’re going to keep your work transparent and accountable to your decision-makers–which is to say, your whole team. You have to work out how you’re going to set priorities and distribute tasks. How will you prevent unconscious bias from impacting your decision-making, and what are you going to do when someone’s behavior is harming your team or its mission? The work of managing doesn’t disappear if you decide not to have managers.
Accountability
On flat teams, a lot of this comes down to accountability. In traditional hierarchical structures, we tend to talk about someone growing in their role in terms of “taking on more responsibility.” People higher up in a hierarchical organization are responsible for more. But another way to look at that is that they’re accountable for more. One of the most common failure modes I’ve encountered with flat teams is that the team doesn’t have a working process for maintaining accountability.
In flat organizations that have de facto leaders, such as organizations whose founders manage the relationship with funders or investors, or those that run largely on the strength of the founders’ personal brand, lack of accountability can lead to deep structural toxicity. Founders who don’t want to manage will insist that they’re not the boss, even though they’re still making all the critical decisions. They’ll gladly take feedback from their team and agree on what’s not working, but they won’t take personal responsibility for addressing problems. They view team culture and decision-making as “everyone’s problem,” when in fact they, specifically, are everyone’s blocker.
In volunteer groups and hackerspaces, lack of accountability can lead to “cookie licking:” the process by which people will “claim” a particular task, but then not actually do it. The cookie licker might not have the capacity to complete the task, but hangs on anyway, feeling like they’re letting others down or flaking out. Meanwhile, other people who have the time and energy to help don’t want to offend the cookie licker by taking over, and so the task gets left undone, or poorly-done.
It is, of course, possible to put structures in place to hold individual people accountable for tasks on a flat team. But in and around tech, most ‘flat’ teams don’t have accountability structures in place. This “buck stops nowhere” issue underpins most of the other problems flat teams experience.
Transparency
Whether we’re talking about consensus or do-ocracy, transparency around decision-making is essential to maintaining a truly “flat” team. People can’t fully participate in decision-making if they’re deprived of the necessary context and institutional knowledge.
When a structureless team is struggling to accomplish its goals due to a lack of accountability or a clear decision-making process, transparency often breaks down. People will route around the group’s nebulous decision-making process in order to get things done. They’ll gather support from friends in the group, get together privately to decide on a course of action, then present it to the entire group as a done deal–supplanting the organization’s ‘flat’ structure with one in which self-appointed leaders make decisions for everyone.
Even in a team where no factions have emerged, a lack of transparency can prevent newcomers from contributing effectively. Whether it’s a “do-ocracy” where no one with the necessary institutional knowledge tells newcomers how to contribute, or a “flat” company where people are meant to “make their own jobs” and only find out if they guessed right when review season comes around, knowledge becomes a form of power that turns a “flat” team into a glass pyramid.
A functional and healthy flat team needs exceptionally good knowledge-sharing, which is an area where a lot tech organizations of all types struggle. The balance of signal to noise is difficult to master–especially when it’s nobody’s job.
Priorities
On the surface, priorities seem like one of the easiest problems for a flat team to solve. Many teams come together to create some kind of concrete mission statement–what are they there to accomplish? Even in the absence of a concrete document, people can still get generally aligned on what they’ve come together to do.
The trouble starts when that general alignment meets the realities of implementation. Without an accountable and transparent structure, it’s really easy for one person, or a small group, to derail a decision they don’t like, or attend to their priorities first.
For example, I worked on a team that was putting together a Code of Conduct for a community. The Code of Conduct team was ad hoc and structureless. One person joined because they had strong opinions that a Code of Conduct should be a “positive,” “aspirational” document rather than a clear list of unacceptable behaviors. She was still operating within our stated goal, which was “to produce a Code of Conduct for our team.” But largely due to her influence, the Code of Conduct we produced was full of non-actionable aspirational language like “assume good intent,” and its usefulness as a boundary-setting document was significantly weakened. A community leader later gave us feedback that he couldn’t even understand what the section she wrote was saying.
The truth was, she didn’t like Codes of Conduct, and she had a personal objection to “negative” rules. Her personal priority was to prevent us from creating rules that governed community behavior. Because our team had no structure and no leadership, no one was empowered to say that while we respected her input, we needed to go in a different direction to create a document that would actually contribute to a safer and more inclusive space.
In startups and organizations that have intentionally chosen structurelessness (or even structured consensus) for ideological reasons, a poorly-implemented decision-making process can lead to another common priorities conflict: stay committed to a process that’s frustrating and annoying people, or route around it to accomplish the work around which the group formed.
We can see this in open-source projects that spend more time arguing about implementation than actually implementing, because no one is empowered to say “we respect everyone’s input but we’re doing it this way.” In private companies, founders who were attracted to flat structures because they are personally conflict-avoidant and don’t want to manage will continue to insist that “we just need to pull together and do the work!” without ever getting agreement on what “the work” is and how to get it done.
Good structure can prevent this, but implementing one takes skill and upkeep that a lot of folks who reject hierarchy for ideological reasons are not equipped to provide.
Tasks
Another place where accountability and priorities can be a problem is when meeting an organization’s priorities requires people to be accountable for tasks that don’t fulfil their personal priorities. This is a problem for groups of all types–messy office kitchens across the world are monuments to this. It is in the organization’s best interest to have a clean kitchen, but no individual person is accountable to keep it clean, and so the kitchen fills up with dirty dishes and the smell of burnt microwave gunk. Water-stained signs in increasingly exasperated tones remind everyone that the organization doesn’t have a maid.
In “do-ocracies,” this frequently leads to burnout, as the same people are stepping up again and again to do the same thankless tasks. A lack of transparency can compound this problem–the newcomer who’d be happy to wash up the kitchen doesn’t know where the cleaning supplies are kept. The professional sysadmin who’d love to help troubleshoot the website’s stability issues doesn’t know how to get in touch with the current admins to volunteer.
Flat teams need a fair way to distribute thankless tasks, and to ensure that all tasks are recognized as contributions that take time and effort. Waiting for people to “take the initiative” and volunteer for these tasks inevitably leads to one of two outcomes: the tasks don’t get done and the organization suffers, or the tasks fall to the most marginalized people in the space. Women get stuck with the cleaning. People of color of all genders get stuck with all the inclusion work. And while they’re busy doing these very necessary tasks that keep the organization running smoothly, the community’s more privileged members have that time free to spend on interesting, high-value projects that raise their personal profile within the organization.
Of course, even the most hierarchical organizations can end up with filthy kitchens. But in an organization with defined roles, it’s easier to specifically assign someone to these tasks. And if those tasks are disproportionately falling to the organization’s most marginalized members, defined roles provide the transparency necessary to identify the problem and hold people accountable for fixing it.
Managing Bias
Holding people accountable for bias and discrimination is a thing that most organizations (flat or not; in tech or not) are bad at, and it’d be laughable to suggest that hierarchical organizations manage this critical issue well. In the kitchen example above, there are plenty of hierarchical organizations where that work does disproportionately fall to women, and where the managers who let that happen are not held accountable. But the lack of accountability common on flat teams exacerbates bias, and lack of transparency perpetuates it.
This leads to companies where people “create their own jobs” and then receive peer reviews that are steeped in bias, because with no job description and no clear definition of success, there’s no way to hold reviewers accountable to any standard of fairness.
It leads to “do-ocracies” where the people who are able to “just do” things are the most privileged people in the space, because they’re the ones with access to the opaque backchannels where the decisions are made.
People are often attracted to flat teams because they’re supposed to be more equitable than hierarchical ones. Without a lot of effort and care, however, flat teams will be every bit as awful at inclusion and equity as hierarchical ones–and the lack of accountability and transparency will make it much harder to identify and address these issues. Without clear roles and defined paths to leadership, it’s harder for those who are being discriminated against to show evidence of bias, and harder still to get anyone to take personal responsibility for fixing the problem. Instead, they’re just told to “build consensus” and “get buy-in,” with no acknowledgement of the ways in which systemic discrimination prevents them from doing so.
Conflicts and Difficult People
The open source community is known for its drama, but it’s hardly the only corner of the tech community where clashing personalities get in the way of getting things done. Many flat teams struggle with conflict, because they lack the structure necessary to navigate conflict constructively.
Because of this conflict-aversion, flat teams in and around tech also tend to flatten all conflict to the interpersonal: if people have a problem with each other, that’s their business and they can work it out themselves.
That may be the right approach if two people are arguing over who gets to use the laser cutter first, but it breaks down fast when a conflict arises because one person in your community is engaging in a prolonged pattern of unacceptable behavior. You can’t treat it as a simple interpersonal conflict when Rosie Racist tells a Filipina coworker that raising her voice isn’t very Asian of her, or when Matt Mansplainer posts yet another condescending explanation to a subject matter expert in your slack. It’s definitely not an interpersonal issue when your famous asshole founder sends a profanity-laden screed because a new contributor didn’t know about your 80-character-wide convention for commits. Telling people to “work this stuff out for themselves” is telling them “we don’t care if our space is more toxic than a chemical spill. Put up with it or leave.”
Healthy teams need structures in place to put boundaries around unacceptable behavior. That can be a Code of Conduct committee, a manager, or some other system, but it should be in place and ready to act before you ever need it. Ad hoc responses to unacceptable behavior tend to be slow-moving trainwrecks that can take years to address even the most blatant problems, and they leave the people most affected by unacceptable behavior feeling unsupported and unwelcome in your space.
Adding More Structure?
Many of the issues I’ve noted above are problems with lack of structure, not lack of hierarchy. Quaker process addresses most of these issues through structure.
So why don’t I recommend addressing these issues with structure instead of hierarchy in tech? As I’ve noted above, consensus-based structures take significant time, energy, and skill to maintain. Quakers invest in that work because, to us, the process is more important than the outcome. Our governance structure is part of our religious witness. We go in knowing that our decision-making process might take us somewhere we never expected, and we take the leap of faith that things will work out if we follow where it leads.
That’s hard to do if your community doesn’t prioritize the work of managing your consensus process–and prioritizing that work is really hard when it’s nobody’s job. Especially if everyone already has a job that’s related more directly to accomplishing your organization’s primary goals. And it’s worth noting that even Quakers don’t tend to use flat structures for projects with paid employees.
Quakers run a variety of organizations and enterprises, ranging from international service organizations and Quaker universities with hundreds of employees down to small neighborhood schools and regional associations of Friends meetings who hire a handful of people to manage their logistics. While these organizations usually use Quaker consensus processes to determine their overarching organizational priorities, practically all of them use traditional hierarchical governance structures to manage their day-to-day work.
We do this because we understand that our process-driven decision-making takes a lot of work. When we’re paying someone to do a job, we need them to be able to focus on the actual job–not on the additional work of managing themselves and everyone around them. Treating the hard work of maintaining a healthy and productive team as something extra that people do alongside the jobs they’re actually getting paid for and evaluated on is both unfair and ineffective.
And if Quakers–who are experts on consensus and flat governance–understand that management is hard work no matter what structure you’re using, then tech companies and tech-adjacent organizations would be wise to learn from our example. Having a flat organization with little or no structure won’t eliminate the work associated with managing a healthy and productive team, and few organizations are actually prepared to put in the logistical and emotional labor needed to maintain a healthy flat structure.
Quakers do what we do by treating the work of managing our process as the most important task we have, and prioritizing it above all else–including getting any particular thing done. For an organization that’s trying to ship a product or provide a service, that’s rarely a trade-off worth making.
Further Reading:
The Tyranny of Structurelessness
BYM’s Manual Of Procedure (The handbook to Quaker process from my local regional Quaker organization)
This article was made possible by multiple generous donors.
The Bias 