Tyranny of the Structureless
Transparent, collaborative, democratically driven organization whose primary goal is to getting money out of politics: sounds pretty lovely, right? I absolutely think so. In fact, that’s the exact reason I’ve spent hundreds of my very few free hours over the past eight months volunteering with this group. Over that time we’ve had some ups and downs, as we’ve grown from just a few dozen volunteers to over 1,000 in our Slack group, with programmers and non-programmers collaborating on a ton of amazing projects with prominent activist organizations to remove money’s influence in politics.
As we’ve grown so too has the operational team supporting this incredible community, moving valiantly down the path toward this non-hierarchical vision that is simple to write and laborious to realize. It makes sense why most organizations defer to the easy route of having top-down management in place; it’s not the most efficient, but it’s a tried and true method used for thousands of years. It got us the pyramids, so how bad can it be?
The thing about us ProgCoders is we’re quite the stubborn bunch, adamant that through structure, process and tools we can realize a global organization with millions of volunteers collaborating on intricate details feeding an autonomous, continually improving network. We refuse to accept that hierarchy is the only possible way forward, though are fully cognizant of the massive risks you run with a decentralized organization, especially with the potential for shadow governance led by a hivemind clique and other lovely issues cover in the Tyranny of the Structureless paper.
As we continue down this path we’re now tackling fundamental and challenging questions. Things like: how do we make decisions? How do we manage change? What is the difference between community and staff? How do we measure and reward social capital? How do we weigh decisions based on contributions rather than some arbitrary pyramid filled with single points of failure? And how do we do all of this while remaining nimble and responsive? Most importantly, how do we avoid the pitfalls outlined by Jo Freeman in the paper linked above.
Rather than attempting to answer these exact questions here, I’m going to use this space to highlight some of the most fundamental challenges that I’ve experienced throughout my life and career, specifically in more traditional, hierarchical environments. My hope is that these learnings will help inform whichever structure we ultimately develop, ideally taking the best and dropping the worst of those that have come before us. We’re all standing on the backs of giants, so it would behoove us to learn from their lessons.
The first thing to understand is how exactly organizations actually develop, which I believe Tuckman’s forming-storming-norming-performing theory proposed back in 1963 still does a elegant and concise job of explaining. Succinctly, this theory describes end-to-end team development, going from initial alignment, working through challenges, establishing cultural norms, and ultimately performing. It’s important to note that performing can take on many functionality levels, not all of which are productive. Being aware of this development and the challenges we face may mitigate some of this risk, however.
As new groups come together they first enter the forming phase, wherein they begin feeling one-another out, generally docilely, albeit guardedly. As the team evolves it enters the storming phase, wherein threatening behavior like domineering forces identified in storming come to a head. As these issues surface, norms are formed, establishing a more regular and predictable cadence for how things are done, especially with unwritten rules. Finally, we enter the performing stage, when the team begins operating on a regular and predictable cadence, ideally as a single, collaborative, high-functioning unit.
These organizational development phases aren’t simply discrete activities which happen once and are done. Rather, these forces are continually happening on a macro, micro, peer, and internal level within an organization. As I’d guess most have experienced, the CEO saying “here’s our culture now” doesn’t make it magically so. There may be some groups who truly embrace the vision while others are adamantly fighting against it, and others who are ignorant one way or another. Further, as change happens on a interpersonal level, perhaps caused by your co-workers or boss, there is a similar evolution that we grapple with internally as we accept or reject the change.
As we structure our team it is important to be mindful and respectful of these distinct phases, as even the best culture, process and tools in the world won’t suddenly make them any less of a reality.
Process for the sake of process
Process is a good segue, as it defines how work gets done for teams entering the performing phase. It’s important to note that, whether process is explicitly well defined or completely nebulous, it ultimately governs everything that we do. Process can come in many distinct shapes and forms, ranging from completely undefined and chaotic to suffocatingly specific and choking.
In my experience, the worst thing that an organization can do is have process explicitly for the sake of process. There are many possible reasons for this; perhaps people desire inordinate control or they are combatting challenges the only way they know how: with more rules.
As we continue to evolve, process should be the defining force that specifies how functional work happens, making it as easy as possible for new community members to contribute, laddering up to larger, visible goals. At the same time, process should nether stifle creativity nor be rigid and unmalleable. It’s critical we strike a delicate balance and create truly valuable processes.
If you’ve ever received an email that says “Hey, how do I do BLAH” or “Where do I find WAH,” then, congratulations, you’ve been the victim of what I like to call meta-work. As the name implies, meta-work is work about work, yet not actually getting anything done. Building off the above, meta-work is typically created due to inefficient process, either too much and too little.
There are many people I’ve met that have lived their lives primarily producing meta-work for other people, while entire industries exist to manage this. Meta-work is usually a pretty good indicator that the organization doesn’t have the right onboarding, functional training and tools available to effectively operate. Of course, it’s important to note that adding additional tools into the mix without having a holistic strategy will generally create even more meta-work, not less.
For our operational structure to become scalable to thousands and millions of people contributing to the mission, it’s critical that we have lightweight, productive tools that manage all work end-to-end, including operations and our change process. People should never need to ask where to find something to get started; that should be inherent within the system. By avoiding all this worthless redundancy and frustration, teams are enabled to focus on making one-another as happy and productive as possible.
Whisper down the pyramid
Meta-work is often due to what I consider the “whisper down the pyramid,” driven by traditional hierarchy’s inefficiencies. The person at the top may have the best possible intentions and strategy for the company, however the challenge is that even being one degree removed from the originating information means you’re now the victim of the telephone game we used to play back in grade school.
Even worse, as I’m sure most have experienced, two people can hear the exact same information and interpret it in completely different ways, leading to wildly different results and, more likely than not, copious time wasted.
As we move forward it’s important to strengthen the transparent culture we’ve been building, while being cognizant about how to effectively disseminate information continually. Discussed previously, the most important thing is to have specific, well-defined and short term processes that feed into broader functional work, ensuring minimal room for error or miscommunication, while enabling inexperienced volunteers to get involved.
Single point of failure
The major issue with whisper down the pyramid are the multitude of single points of failure hoisting it up, more typically known as middle management. While not all management is terrible, and most are likely trying to best they can, there are some critical flaws. Thinking about it, how effectively would technology work without built-in redundancy, defined process and continual performance checks along the way?
As we develop our change process, it’s important to have a wide subset of people able to factor into decision making. Of course, this doesn’t mean that every single person deserves the same say in all items. Rather, we should first look at which groups or functions the change decision impacts and who the key contributors are, then have that group responsible for decision making based on their relative contributions.
Speedbumps, not skypscrapers
Building on this point, another major challenge with most organizations is that decision making and compensation are based on more of a skyscraper approach, wherein the people at the top receive an overwhelming benefit and those left at the bottom have to fight over the scraps. And for these purposes I’m not even speaking about the CEOs making $30 million, but rather the actual owners, the Rockefeller and Rothschild ancestors, who still own the majority of society.
This isn’t to suggest that everybody deserves exactly the same amoun. Rather, I’m recommending we look at a more fair and even distribution of wealth and power based on people’s contributions and effort invested over time. This will create a more equitable and balanced system, encouraging people to continually contribute while also exploring new solutions.
Rather than the single point of failure system mentioned above, an important factor we’ve been considering is how to measure and reward social capital. Briefly, social capital should be a measurement of the good, productive contributions you’ve made to an organization or community. Unfortunately, more often than not, most systems are based on perception instead of reality, with those best at playing politics, kissing the most ass and being the loudest getting unfairly rewarded, punishing those that make incredible contributions yet aren’t as good at self-promotion.
As we develop our tools based on process and structure, we should ensure that social capital is inherently measured in the system, determining a person’s weight in decision making and compensation based on their actual rather than perceived contribution. Social capital should ultimately be an objective measure for how much somebody has contributed to the community, not a popularity contest.
Herzberg two-factor theory
One more oldie but goodie from the 60's is Herzberg’s two-factor theory, succinctly describing the factors in an organization that can either lead to a satisfied or dissatisfied employee.
Motivating factors include things like a challenging work environment, recognizing achievement, personal responsibility, opportunity to do something meaningful, decision making involvement, and organizational sense of importance. On the other hand, hygiene factors include things like organizational status, job security, salary, benefits, work conditions, pay, insurance, and vacations.
The idea is that the existence of motivating factors will lead to a satisfied and productive team, whereas the lack of hygiene factors creates a dissatisfied and demotivated team. It’s important to note that simply having hygiene factors like good pay will not lead to a productive environment, as these are factors an employee feels as if they’ve already earned and therefore expect, so pay is not treated as inherently rewarding.
In establishing our team and member benefits, it’s critical that we are mindful of what types of things enable satisfaction, while which others destroy it. Being aware of these will ensure that we are building our processes and tools to create the best possible culture.
Another fairly well known idea is the prisoner’s dilemma, which rewards collaboration and punishes disloyalty. The idea is that two prisoners independently held for the same crime can either remain silent or betray the other person. When both remain silent they each receive a one-year penalty; when they each betray the other they each receive a three-year penalty; and when one betrays while the other remains silent the betrayer is set free while the silent party receives a two-year penalty.
This is an interesting game theory thought exercise, as the best possible scenario is for all parties to remain silent, yet more often than not they will betray one-another. This is something that professors will act out in Econ 101 classes with extra credit as the reward, generally ending in at least one person in the class betraying. The fascinating thing is that, even in classes with hundreds of students, if this game is run multiple times it will generally lead to the entire class not betraying one another and thereby receiving the collectively most positive outcome.
I love this thought exercise because it aptly conveys how many organizations are run essentially as giant games of the prisoner’s dilemma. This generally leads to betrayal and in-fighting, even though it’s in the best interest for an organization or team to work together. As we structure our team it’s important that we’re mindful of this and put in place rewards to encourage mutually-beneficial behavior, while making collaboration and trust an inherent part of our culture.
Ideas as seeds
One thing I think about is how ideas are essentially seeds. A tiny thing can have the potential to become a massive tree, ultimately breeding an entire forest, yet most seeds are crushed before they even have an opportunity at life. ProgCode is very much a seed, still early in its germination phase, with amazing potential and countless challenges awaiting.
The question of whether ProgCode will ever become a verdant forest depends on how effectively we work together to nurture and care for it. In addition to things outlined here, it’s important to remember that ideas are best when many people are able to collaborate and work on them together, cultivating them into something unimaginable. What this means is that for people coming in with ideas it’s key that to understand when you need to give it space and allow for the skills of other experienced gardeners to help it prosper, otherwise you may risk choking their life away.
For ProgCode, we should look at the amazing potential these seeds being planted all around us have and help create the framework of support for them to thrive. This requires a delicate balance of knowing when to give the seed more nutrients and water as well as when to leave it alone to grow and adapt on its own.
Finally, as a great way to summarize everything here, I’d like to introduce Maslow’s hierarchy of needs, as it helps provide a great description for what drives us as people and the challenges we face. Maslow’s hierarchy looks at all the needs we have, beginning with psychological and progressing to self-actualization. The idea is that people may become more complete versions of themselves as they realize these base level needs.
On the bottom level are things like air, water and food, necessary for basic survival. As these needs are met people move onto finding safety through shelter, then onto romance, compassion and well-being with one another. The final two stages are esteem, showing the needs to be respected, and self-actualization as the realization for what a person is intended to become. Beyond this, Maslow later conceptualized the idea of self-transcendence, looking for how we may help others around us.
For everything we do, we should be cognizant of these needs and how widely humans continue to vary on this scale. While we are fortunate to have the opportunity to work toward self-transcendence, it’s important we understand that many of those we are trying to help still struggle to reach the first stage. As we do the work we do we should remain mindful of where people land on this scale, how their behaviors may accordingly adjust and how we can help push one-another through the rungs.
Now that we understand some of the key factors working against a typical organization, in the next post I’ll lay out what we’re doing to defend against them. The goal is to share all of our practices and experiences so that others may learn and benefit from them.