Grassroots tech
As I’m writing this I find myself a couple thousand feet in the air somewhere between Seattle and Prague, most likely near the rocky mountains judging by my clock. The reason for this trip is to give a brief talk and lead a discussion focused on how new technology has been used recently to drive progressive efforts, highlighting especially the experiences we’ve had with the Progressive Coders Network and previously with Coders for Sanders.
I myself am not a developer, though I am someone quite passionate about the technology world and, specifically, the potential massive positive impact it can drive if done right (as well as the headache it can cause if not). I am also specifically interested in how we can most effectively empower collaboration between the world’s technologists to build our future.
We decided that for my time in Prague I would focus on how technology can help mitigate some of the biggest challenges the progressive movement continues to face, specifically looking at how we’ve used technology and where we’re headed. In addition to this talk, I decided I would also take the opportunity to record whatever thoughts appear in my head miles above earth while waiting for my next whiskey.
In order to bring some structure to these rambling thoughts, I ultimately ended up looking at the most important internal and external factors toward successful grassroots organizing, examining some of the pitfalls with how each is traditionally handled and how technology has offered an improved alternative.
Internal Organizing
Collaboration
It only makes sense that I kick things off discussing collaboration. That’s because, in everything I’ve done, from grade school soccer (or football) to working for an IT department within higher Ed or with a publicly traded technology company, the number one indicator to how successful the team and broader organization were has come down to how effectively people collaborated.
Collaboration is no less important and certainly no less logical in grassroots organizing, especially in support of progressive issues aiming to help the mass population (you know, like getting money out of politics). Yet time and again it seems collaboration can be intimidating to groups, and often when it does happen it’s marred by suspicion to your co-collaborators true intentions. Even collaboration within the same organization can also be tricky, due to both cultural and technical limitations.
On the other hand, embracing collaboration (and transparency, but more on that later) has been one of the most important success factors for these technically fueled movements in both Coders for Sanders and Progressive Coders Network. In both groups people came together organically to discuss, deliberate, and decide which applications and efforts to support. As different movements formed and gained momentum, members have been encouraged to join one another’s collaboration space, usually some combination of Slack, Trello, and shared documentation that details ways to contribute to their open source projects. Further, teams key strategies, goals and needs are publicly posted and often crowd-developed, rapidly responded to by volunteers hungry to drive positive change in this world.
Process
Of course, collaboration is nothing without my personal favorite thing: process! If you’ve met me at any point over the past decade or so, odds are you’ve heard me harp on incessantly about process. And for good reason; to me, process is the difference between productivity and chaotic disorganization and inefficient mental load. Process should define the least path of resistance for how an interested person can do what they came here to do: contribute to something bigger than themselves.
Of course, this does NOT mean that all process is made alike, or that just because you have process in place mean that you’re operating optimally. In fact, many grassroots organizations require a ton of what I’d call “non-valuable” process, suffocating their effectiveness with red tape. And I must be clear, you’re likely better off in Rapi’s world of perfect chaos than a world wrapped in process for the sake of process.
How you establish your processes is completely up to you; good process adapts to its specific environment. However, regardless of environment or tools you use, there are a few best practices that transcend borders. First, your processes must be clearly defined and specifically documented, with a system in place to proactively connect people to that information. Next, your process must add value, which means solving downstream problems people will have while requiring nothing that does not provide direct value. Ideally, process should serve as a means to collect information once and use it in many places, reducing redundancy and inefficiency. Finally, your process should be adaptable, enabling flexibility as your environment changes, which it certainly will do. So people must he clearly informed and empowered on how to update their governing process as business changes.
Transparency
Now that we have collaboration and process running, let’s bring us back to another make-or-break element: transparency. Like the other categories, transparency breeds efficiency and reduces duplicated effort. This isn’t to say that all things should be immediately transparent or that there isn’t finesse within the transparency. Rather, it simply means that, more often than not, erring on the side of transparency is probably the best bet, however make sure to be thoughtful and strategic about how you do so.
Of all the challenges I’ll cover, transparency is probably right up there amongst the things grassroots organizations (and organizations in general) are terrible at. It’s also one of the biggest strengths of the development community, primarily because many of the open source projects fueling the world would be literally impossible without complete transparency. Even more, we’ve been applying those same concepts to how we operate in all other areas of the organization, having a pragmatic and precise approach to how we operate end-to-end.
So, what makes us transparent? First, nearly every decision we make, especially around project development, is made in public in our Slack community, with channels like #community-vote and #pitch-zone shaping and driving our direction. And while we do have a few private channels to discuss day to day operations (trust me, we’re saving you, nobody wants to see Dan’s soapbox ;)), all decisions and conversations are conveyed publicly for continued conversation and scrutiny.
Projects within ProgCode are also often driven publicly end-to-end, enabling anyone in the community to help shape its direction. For a great example, just yesterday a thought-provoking conversation broke out in National Voter File, a project whose ambitious goal is to organize and democratize valuable voter information generally only available to extremely well-funded campaigns. Although National Voter File is dealing with publicly available data (minus a required fee, ranging from hundreds to tens of thousands), given how disconnected data currently is, some raised concern this project would present a risk by having it much more accessible. By discussing such fears in a public way the team was able to come away with an improved approach to managing accessibility, driving an improved outcome.
Next, we have a number of communication mechanisms including volunteer staff meetings, partner overviews, and board discussions which are open to our community, putting our members in the drivers seat. In addition to these meetings, we also have regular community updates aggregated and announced through various channels, extending out to our broader network.
Finally, we also work hard clearly explaining our strategy, goals and partners through our defined onboarding process, highlight key opportunities to contribute to the community, our network of apps, and the ProgCode core team. In addition to this, we also make this information available on demand and included in communications members immediately receive as they join our community.
Structure
The next major challenge we’ve been able to overcome is a strict, inefficient hierarchical structure, where decisions are made in secret often at odds with the will of the community. Too often we’ve seen many promising organizations crippled by the infighting and inefficiencies that can come with a strict hierarchy, usually accompanied by several of the major challenges I’ve already mentioned.
ProgCode, a non-partisan group vying for non profit status, has been adamant from the beginning about avoiding a strict hierarchical structure. While a board is required by law, we look for our community to drive the most important decisions impacting them. One of our major priorities is defining and developing repeatable processes within specific functions so that meaningful work can flow throughout our organization.
In addition to managing ongoing work, the broader goal is to govern continual operations and drive cross-team collaboration, reducing the need to rely on the whims of individuals. Long-term we will develop a self sustaining, continually improving, autonomous organization, capable of tackling the greatest problems at massive scale. Much of what we currently do through loosely integrated applications like Slack, Airtable and Trello will ultimately be replaced by brand new, open source technology currently being conceptualized and developed.
Another important point to cover within structure is ProgCode’s relationship with the amazing app creators we support, including Social Roots, Code Corps, Carpool Vote, GrassrootsPB, and many others. In addition to avoiding suffocating hierarchy within our internal operations, we want to ensure technologists feel empowered to bring what they create to our community. When they do so we want to provide them with highly valuable common services, including technical offerings like DevOps tools, collaboration opportunities with partners and other apps, and audience outreach through our community engagement team. That said, it’s important to understand that everything we offer is completely optional with adoption and usage solely in our partner’s hands, ensuring ongoing autonomy.
Onboarding
The final internally focused area, and a current personal passion of mine, is onboarding and training, most likely because onboarding is something I’ve seen as the single most glaring and detrimental gap in nearly every job I’ve ever had (unsurprisingly, the best onboarding I’ve had was while working in IT, the same place I originally established my zeal for process and structure). Highly dependent on and yet still distinct from the processes mentioned above, the difference between poor and solid onboarding and training is a another key indicator to an effort’s success or failure.
The onboarding concept is fairly obvious to me, yet somehow absent from most of my experiences (spoiler: “here’s your laptop and login info” does NOT constitute a complete onboarding process). In a nut shell, the onboarding process should provide someone brand new to the team with all of the information necessary for them to begin contributing, walking them from one step to the next in a straightforward and repeatable fashion. Some key factors to cover include organizational and functional overview, important points of contact and resources, system access and training, and specific actions to complete.
Going hand in hand with onboarding is specific training, both for skills required for contributing and organizational processes (though, ideally your processes will be structured clearly and logically, minimizing the need for specialized training). Training materials should be clearly displayed, which presently for us means critical files pinned to each Slack channel, providing an overview and other key information for the project or function. In the future we’ll explore how the apps we develop to manage our operations will directly integrate training into their experience.
External Organizing
The first group of issues focused on highly insular challenges. Things like poor collaboration, inefficient process, lack of transparency, suffocating hierarchy, and poor onboarding are critical internal factors that can drive or prohibit success, however they are just one part of the equation. The next set of factors is focused on those things external to the organization, including your audience outreach strategy, how effectively you collaborate with your community and what you offer to your stakeholders.
Outreach
To kick things off here, let’s start with audience outreach, focusing first on how it’s commonly treated. More often than not, the audience is looked at as a mass of people to get to do something. While extremely diverse, only lately have groups begun looking at the audience as different segments at least, however that still doesn’t go nearly far enough to address any audience’s unique composition.
Expanding on this challenge, many groups find themselves clinging to tactics that may have worked in the past that are at minimum outdated and at worst counter productive today. One of the most egregious errors includes relying on traditional advertising, including print, television and, yes, even digital.
For us, from the very beginning we’ve been focused much more on a highly targeted, often 1:1 engagement strategy, where promising individuals are specifically matched to efforts matching their interests. As we move forward we look to maintain the direct 1:1 contact, yet empower our community to drive its own development, enabled by the community engagement team we’ve recently kicked off.
Rather than trying to have the audience do something for us, our primary goal is building long-lasting relationships which are indefinitely mutually beneficial. When we find someone anxious about the state of the world and interested in driving positive impact, we want to find how we can help them meet their personal goals, regardless of whether they have five minutes or five hours a day to dedicate. The more effectively we all work together, the greater success and positive impact we’ll help the world realize.
Community
Feeding off the last topic is the question of how effectively, if at all, you collaborate and empower your community. More often than not, the most successful modern organizations rely heavily on having their community members help drive their vision, outreach and execution, so it’s critical to ensure you’re exciting and enabling your community accordingly.
A huge mistake groups can make when it comes to audience outreach is underestimating or even fearing audience-produced contributions. Instead of requesting a limited number of specific, self-serving asks to the audience, we look for our community to tell us how they can most successfully contribute to our effort. For example, during the Bernie campaign nearly 100 apps that helped fuel his success were created were independently created by many of the technologists who now call ProgCode home. For our team specifically, just this week one out of our community members felt empowered enough to produce, print, and provide ProgCode flyers to interested attendees at Amazon’s re:Invent simply due to his own personal passions.
To expand on this, for Progressive Coders Network, we continually state that we ARE our community and without it we’d be nothing. I mean, just look at the name. So the heart of what we do comes down to understanding what the community is most passionate about and facilitating opportunities for us to realize shared success. Instead of looking at the community as someone we can dictate things to, we look at them as people we can collaborate with to realize real change.
Another key contributor to our success is enabling the community to not only spread the message but also to contribute to those very underlying tools. As I mentioned, we have a highly fluid community driven system where members can pitch ideas they would like to see. In addition to this, we also connect our community directly with partners or even toward internal needs, ultimately driving them to ongoing team member.
Offers
Finally, the last topic: what you actually offer to your stakeholders. Realistically, everything up until this point, all the process and strategy and operational stuff, is nothing more than words without the last topic. Because what you offer your stakeholders is the product of everything discussed before and, well…it’s what you actually provide. So make sure it’s good.
We find ourselves in a unique position when it comes to offers, as the network of apps we support have no formal ties ProgCode, and, as I’ve mentioned previously, we are nothing without them. While other organizations may not be in the exact same spot, there are still important lessons to take away and apply even internally. For us, this comes down to building a service-driven culture where we can create positive relationships that empower a strong sense of ownership while leveraging what makes most sense to a particular team.
Like the rest of what I’ve written here, it’s difficult to judge quantitatively what is and isn’t a good offer, primarily because what constitutes a good offer depends on so many other factors, especially what it is your audience actually cares about. But like these items I’ve discussed, there are a couple good indicators to help ensure you’re providing the best product possible.
The first clue is whether you’re actually talking to your audience and understanding what they want. Crazy, I know, but having clear communication before, during and following development will not only ensure you build a better product, it will also make it significantly easier for you than having to guess. For us, because projects are developed directly within the same channels our community uses and our community are often the one’s driving these products, we have nearly quite literally no barriers between our audience needs and the finished product.
The next key factor is ensuring you aren’t building something that is completely self serving, devised only with your personal interests in mind. While it’s important to have solidly defined goals and a plan, not rectifying those goals with your audience goals is another huge risk. Instead, if you focus on building a product or offer that is enjoyable to use with your customers personal goals front and center, benefits will surely follow.
As a good segue, the last factor depends on building an actually enjoyable user experience. You may have every other factor in place, but if your experience is confusing and clunky to use, it’s unlikely you’ll ever receive the adoption you require or expect. Ensuring the user has a highly integrated experience with minimal barriers to entry and common integrations will be critical to take the final step and drive the user from intrigued to engaged.
Culture
With all that we’ve discussed around internal and external operational success and how to evolve from challenging, inefficient ways of operating to more fluid and collaborative means, it’s nice to wrap everything in a neat, tidy bow. For me, that bow goes by the name: culture.
Indeed, culture is the culmination of the many distinct forces driving an organization. Like those individual forces, it’s difficult to specifically pinpoint what is culture, and whether that culture is good or bad. Rather, culture is something people feel in their guts; it’s the factor that says whether you should feel empowered or afraid to suggest a non-traditional way of doing something.
Realistically, culture probably requires the least explanation of anything discussed above. Even if you can’t specifically describe your organization’s culture, I’m confident you have a feeling of whether or not it’s good.
Rather than try to describe the ideal culture, I’d rather ask you to think about how your culture feels, and if it feels anything less than ideal, I implore you to further explore the topics visited here, think about how your stakeholders might feel, and see if there are any areas you can find improvement. I’m not suggesting that what I described here will necessarily work for all groups or that it’s the optimal way of doing things. Rather, I merely hope to describe the key factors that have worked for us and encourage you to give them a try. I also recommend you come join us at ProgCode to see first-hand how we do things; we’d love to have you join us.
