Structure of the Tyrannyless
My previous post discussed traditional organizational structure’s common pitfalls that makes us prefer a transparent, community-driven, non-hierarchical approach. Of course, I chose to ignore all of the positive things hierarchy has given us, like most of modern humanity. Instead of suggesting hierarchical organizing is terrible and should be hated, I’m simply arguing there are other methods to choose, many of which finally viable due to recent innovations.
The “Tyranny of the Structureless” paper concludes with a list of
“principles we can keep in mind that are essential to democratic structuring and are also politically effective”
In order to keep us honest about whether we’re avoiding the pitfalls that sometimes come with a non-hierarchical structure, I’ll use the remainder of this post to dig into each principle and give ProgCode’s past/present/future view.
This isn’t quite Sociocracy, Holocracy or any other non-hierarchical structures; this is simply what works best for ProgCode, our special chaos and process mix, which will continually evolve as we do. The goal is to provide a playbook of sorts for what we do to support this community, hoping that other teams may benefit from our trials and tribulations, while sharing their learnings for improvements we should consider.
Authority Delegation
According to Jo the first essential principle is that tasks are delegated to specific individuals through democratic procedures, with the argument that actions should be explicitly defined, ensuring jobs are dependably fulfilled and incentivized through the explicit commitment made. I would also add that having explicitly defined, yet flexible activities a volunteer may contribute toward will produce a greater sense of value and commitment to the effort.
One of the key challenges we vowed to address with our Winter 2017 Strategy was:
“as we gain more and more members, confusion as to how to affect change, and become a mover in the community becomes a huge question.”
A major focus from the beginning has been making it as easy as possible for people to get involved in the community, enabling them to contribute to things they’re passionate about rather than dictating arbitrary tasks.
What we’ve done: We have a functionally organized volunteer effort, broken into separate, highly interconnected Hubs: Foundations, Community, Partners, and Communications. One of our primary focuses has been building and defining repeatable processes, documented on our GitHub Wiki, while the GitHub Functions board captures all ongoing work, reviewed in an open meeting every Monday, with a recording posted to the #operations channel and notes captured here. Process, process, process.
What we’re doing: As we continue to refine processes, we’re also working on building a regular calendar which will include recurring activities assigned by person, so how to contribute is clearly understood. We’ve also just ratified and updated our change process, which encompasses our decision making process, making it as clear as possible for people to contribute to the network.
What we’re envisioning: A semi-autonomous operation driven by a highly integrated system managing end-to-end, continually improving functional processes, minimizing business inefficiencies, including waste, redundancy, poor training, inconsistent documentation, and tool inflexibility. Beginning with an idea, work flows through the company transparently so specialized teams are assigned small and achievable work. People’s individual contributions are tracked and rewarded accordingly as social capital, with mobility and autonomy encouraged as long as the team member has completed the individual function’s training.
Responsibility
This one basically means those delegated responsibility ultimately must answer to the people who put them in that position, with the group maintaining ultimate authority. It’s what, you know, our government is supposed to be. And, to be fair to our elected officials, I suppose most are responsible to the “people” who put them in power, especially during the 21st century where “people” means “not actually people, but organizations” and words literally don’t matter any longer!
What we’ve done: Not long after starting ProgCode we established a board, as that’s one of the requirements of being a non-profit in addition to what we thought we were supposed to do. In hindsight, doing this early may have inadvertently caused some hierarchical behaviors, including substantial confusion about how decisions are made. Fortunately, at the beginning of the year we rolled back the board and focused on establishing our foundation first.
What we’re doing: In an effort to ensure we transparently and democratically determine responsibility, one of the first things we built a GitHub issue change template where volunteers may suggest changes, decided through consent-based community vote during our weekly public team calls. Our ongoing effort is to ensure that all community members, as long as they stick to established community guidelines, are able to take initiative and responsibility for the change they want to see.
What we’re envisioning: With our continually evolving Organizational Structure document we now have the opportunity to develop a truly community-driven organization, with the board selected by the community and powers intentionally limited.
Authority Distribution
The next principle is distributing authority among as many people as possible, ensuring individuals learn a variety of skills while no single person can seize a monopoly of power and influence over a particular area.
What we’ve done: At the beginning we were plagued with a bunch of private channels, making communication inconsistent and getting potential volunteers involved nearly impossible. However, we quickly moved to as much collaboration as possible happening publicly in Slack and having self-selected “coordinators” for each of our functions. We’ve also made it as easy as possible for anyone interested to contribute by making it that anyone interested in volunteering is able to do so, working on the areas interesting to them.
What we’re doing: Authority is ultimately inherent within our operational processes, especially change. For any item considered an official ProgCode action it must have a GitHub issue created and gain community approval during the weekly volunteer staff call, scheduled on our Airtable call calendar and published in Slack. It’s crucial authority is defined and accessible; having only a few people understanding how to contribute doesn’t help anything.
What we’re envisioning: A fully autonomous, interconnected, continually improving network where authority is determined by community vote and weighed by individual contribution. As we mature we will bolster our operational tools into a single system that manages all work transparently. The goal is for fully distributed authority without any arbitrary, single points of failure.
Task Rotation
Jo argues an organization must have a Goldilocks-esque approach to task rotation: too little and people begin feeling ownership as their own property; too much and people do not have the opportunity to feel the satisfaction that comes with doing a good job
What we’ve done: From the beginning we’ve envisioned a functionally-driven organization where any person is able to contribute to the areas that interest them. While we’ve had shades of this, we’ve also sometimes experienced a somewhat tribal nature, with individuals guarding their focus areas with inconsistent cross-team communication.
What we’re doing: With so much going on, it’s crucial that we effectively allocate responsibilities. The foundation for doing so effectively is ensuring we have solid, documented, repeatable processes on which anybody can take action, captured in our GitHub Wiki. We also publish a daily announcement to the community, wherein any volunteer can contribute and are creating a standard editorial calendar so that anybody may propose an item for consent to have their voice heard. We make all of this available in our GitHub Action Items list so that people may stay up to speed with the latest in ProgCode
What we’re envisioning: Like several of the other areas, the more we can implement process, structure and tools to govern our task rotation while removing minimizing human error, the better we’ll be. In the future we will have a system in place where anybody can both easily see all current activities at once while also having a view for how they and others have contributed.
Rational Task Allocation
This one sounds rather similar to the former. All of these are actually quite similar. In middle-sight, this may not have been the best possible format for this piece. But, fuck it, I’m committed now. Similarities aside, I actually quite like the motivation behind this, as it abhors the “sink-or-swim” method adapted by most organizations and recommends more of an apprenticeship where people are, you know, trained skills. This is pretty much why I’m here, to make it as easy as possible for people to get involved.
What we’ve done: Onboarding! Even prior to joining ProgCode I was all about having solid onboarding practices. Not long after this October afternoon we started delivering regular onboarding calls with shitty ass PowerPoint slides. We also created a #mentoring channel, because mentoring is better than apprenticeships, and we feel everybody should champion life-long teaching and learning as a mentor and mentee.
What we’re doing: Fortunately for our more recent members, we decided to ditch the slides in favor of a more human, conversational format for our regular onboarding calls (of course, we still have a process). For people looking to get involved, we borrowed the volunteer board format from the National Voter File. And so that everyone has clear expectations for what to expect when joining ProgCode, we’ve outlined the entire onboarding process in ProgCode Wants YOU, from initial registration through onboarding buddy.
What we’re envisioning: Once again, software is better than manual, ad-hoc human process. As I touched on in the previous post, there are few things I detest more than ineffective onboarding backed by nebulous process. I’ve already covered how we’re documenting our processes through GitHub. As we get more mature and outgrow that still-mostly-manual process we’ll need a tool to manage ALL of our work transparently. I’m sure I’ll go into far greater detail sometime in the future, but the key principles are defining and making each activity explicitly known, while incorporating flexible, continuous improvement. It’ll be awesome!
Information Diffusion
Alright, Jo, you don’t need to lecture us on the importance making information accessible. And we’re right with ya for how critical it is to have information spread and generate new ideas, making it as easy as possible for people to understand what’s going on so that they may, you know, contribute to what’s going on.
What we’ve done: The Big Bang moment for the Progressive Coders Network is perhaps the Moving Forward Manifesto written by Rapi Castillo following the end of the 2016 Democratic primaries, since contributed toward and improved by dozens of people. Remember those shitty slides I shared above? This document was the inspiration for a lot of it (but don’t worry, the shittiness was all me).
What we’re doing: The manifesto was just the tip of the iceberg — we share A TON of information. Perhaps too much at times, it’s another thing we’re working to streamline for new people joining. With 222 channels and growing, the channel list is a huge help for new members to get a quick glance of what’s going on. We also make it a habit to share whatever we can publicly through the The Progressive Coder, including the Everything Starts with an Idea for people interested in making something happen but not sure how.
What we’re envisioning: Open Source Organizational Framework. That’s what I’m calling it, anyway. The idea is that this chaotic mess of information will be organized, turned into software and made more accessible for people who, say, don’t necessarily feel like reading 100,000 words. The hope is that any individual should be able to build on what we’ve done for their own effort. If we can remove common barriers to entry including capital and business expertise so that people can focus on what they’re best at, we figure the world will be a better place.
Resource Access
Phew. Finally, the last one. If you think it’s tough reading all this, just imagine writing it. I promise, my next post will take fewer than five minutes to read. The final element to avoid a tyrannical, structureless organization is ensuring that people have fair access to resources, including physical objects and intangible skills and information. Jo stresses the importance for member willingness to teach others what they’ve learned as well, which is a common value in the open-source community.
What we’ve done: Well, all that stuff up there for starters. Despite some minor transparency hiccups in the beginning, we’ve been continually working to make any and all information as transparent as possible. Heck, we’ve discussed our entire legal structure in the #legal channel, with all work happening to support it in #operations. By having everything happening so transparently and encouraging people to join, we’ve found it much easier for people to have an understanding for what’s going on and, ultimately, begin contributing.
What we’re doing: From a tooling perspective, our best friends have been Slack, Airtable and Zoom, to name a few (and you’re not too shabby yourself, Medium ;)). We’re also hard at work on our Bylaws right now and have disseminated all of our key information through the ProgCode Toolkit. On an informational side, as a group dedicated to removing money’s influence in politics, the funding conversation is a delicate topic, as you may imagine. We’re continuing to develop our funding framework and even when Civic Hall graciously offered a three-month stipend to Rapi, we ensured the agreement was handled transparently and consented by the community.
What we’re envisioning: Money will remain a necessity for the near future, though that doesn’t mean it must necessarily be evil. That said, as the world is realizing, politics is an incredibly dirty game, thanks in large part to the corrupting influence money has on it. Just last night we had another discussion on what funding types we would accept, including by amount and person. Like everything else in ProgCode, the conversation centered around ensuring we remain transparent and have community buy-in. As this conversation continues to evolve, I fully expect we’ll reach conclusions that match our culture, with transparency and flexibility embedded to drive continual evolution.
Conclusion
Undeniably, I have ridiculously optimistic expectations about ProgCode and what we’ll be able to create together. Among those expectations is the idea of an “Open Source Organizational Framework,” essentially making all the parts of how we operate transparent and available to the community and our application and organizational partners.
I consider this and the previous post the starting place to doing exactly that. My hope is that by sharing our history other organizations will learn from what we’ve been through, while also sharing their learnings along the way. The better we learn from the past, the more successfully we will drive progress into the future.
