My Passion Project for several years has been helping RailsBridge evolve and grow into an organization in which anyone with passion can jump in and make then entire org better.
We're guided by various models of "starfish organizations", inspired by the book The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations, by Ori Brafman and Rod A. Beckstrom, an series of case studies of how different organizations have responded to attack or a changing environment. They conclude that organizations that can function without a "queen bee" become resilient, flexible and more creative.
This is the story of RailsBridge (and me) wrestling with the ideas, made them our own, and changing our ways.
To lay out the options, There are hierarchical organizations that rely on leaders for their direction and their vision. By contrast, there are "open", "flat", or "leaderless" organizations in which the people who are doing the work on the ground determine the direction of the organization.
(To look forward a bit, there are also a few great examples of organizations experimenting with combinations of these two extremes. Companies that strike a balance attribute the org structure with the unusual ability to be profitable and focused, while also being flexible, innovative.)
Digging in a bit, Spiders, standing for hierarchical orgs, have a web, and information from the web travels up to the spider, who makes a decision and executes that idea, as a single unit.
An alternative way to think about hierarchical orgs is a the popular conception of a queen bee and worker bees. (Queen bees don't actually tell worker bees what to do. Biologists, hold your fire.) It's an assumption of this model that the leader has knowledge and vision for the org that the worker bees lack. To be clear, the worker bees can still be quite skilled; they bring craft and specialized knowledge.
But in this model, we've limited the number of decision makers, the number of people who are grappling with org-wide issues. That's going to make it harder for the org to evolve and change, especially if the input that the queen bee is getting aren't diverse.
Taking a look at the worker bees in this model, they have specialized knowledge, but their role doesn't allow them to influence the entire organization in one direction or another. The upside is that a worker bee can focus on the thing they need to get done, without distractions. The cost is that if a lowly worker bee has amazing ideas for improving the org, that bee probably can't effect the change her ideas merit.
Alternatively, starfish don't have a centralized nervous system. (They sort of do, but it's primitive.) So starfish don't collect lots of information, consider it, and act on it. That's mostly a downside, but there's a hidden benefit: they handle hostile circumstances better than most organisms.
This was illustrated particularly dramatically when the coast of Australia had a booming starfish population, that was killing the already dwindling coral population. In response, divers set out to kill the starfish one by one, but cutting them in half with a knife. Unfortunately for the coral, starfish are regenerative, and if you cut them in half, in a few months there are two fully functional starfish. In essence, the divers helped the starfish reproduce.
In the starfish model, there are no queen bees, only worker bees. That's not to say there are no leaders at all, though. Starfish organizations definitely rely on particular individuals for inspiration, and to help organize them and make them more effective. But this type of leader is different than having a queen bee. Any of these worker bees have the ability to convince other bees, so a good idea, even if it's the idea of a lowly worker bee, has the power to change the organization.
At RailsBridge, we started out as a spider organization, with two leaders, Sarah Allen and Sarah Mei. Unfortunately, these two leaders were full time engineers with families and lives. Adding on top of that all the work RailsBridge required was like cutting a spider in half; it wasn't a sustainable amount of work.
And we were also fragile. If something came up at work for one person, a workshop could fall apart. And then an important thing happened. Sarah Allen got together the regular volunteers, and she pitched us on starfish. "We need to grow our organization and make it more resilient."
If you're doing something that no one is doing, find a starfish that can share the work with you.
In my case, I was meta-organizing for San Francisco, so a few times a month I was getting coffee, lunch or drinks with people who wanted to organize a workshop. And on one particular time, I arrived a bit early, and happened to find a friend I hadn't seen in a while. So I sat down at her table and we chatted. At the same time, the person I was supposed to meet was wandering all over the bar looking for me. It was not my best moment."
The woman I was supposed to meet finally walked up and asked if I was Rachel, adding, "I thought that might be you when I came in, but I'm surprised you would pick a table this small." I immediately knew this was someone who thought about problems differently than I do. She's to the point and ready to get things done. Fast forward a month, and she was my starfish. She was the person who could help me evolve what I was doing.
Lillie is organized, and I'm very good at "skating on chaos". Most of the early workshops were pure chaos, so that was a great skill set. But if we want the workshops to be less chaotic, maybe we should start doing things differently.
Lillie and I started sharing the responsibility of organizing organizers. We started planning out how we were working. We started documenting how to organize a workshop. We started keeping spreadsheets so we didn't lean on venues or donors too often.
This was all win. Workshops will still happen if I get hit by a bus, so we're became a more resilient org. But more importantly, Lillie's skill set complimented mine, and our org evolved and became way better.
So I starfished myself. Other people starfishes themselves, and we're making Ruby workshops in the bay area happen. Better than ever. But we realized we're just getting started with this starfish thing.
We don't just want to get more women into the Rails community in the Bay Area. We're actually way more ambitious than that. We want want to make programming accessible to people all over the world. And we want to be a jumping off point for anyone who has a similar goal. All our curriculum is open sourced.
Community is hard to scale.
But that ambition means we have some more scaling problems. To illustrate, there are lots of ways to teach programming. If someone writes a book or makes a podcast or a video, that product can effect many, many people (say, n people) without any added effort. For the programmers reading this, books, videos and podcasts are constant time, O(1).
By contrast, every time we want to hold a RailsBridge workshop, we need to find money, we need to find volunteers, we need to find organizers, we need to find a venue, and we need to find a way of reaching out to potential participants. In other words, workshops are O(n), where n is the number of workshops; we have to work for every workshop.
Fortunately, we have lots of examples of examples of how we can organize ourselves to meet these competing goals. On one hand we want to reduce unnecessarily repeating work between workshops, and on the other hand, we want to be an organization where people who care can jump in and make things better. One hand pulls us toward more hierarchy, the other towards less. So we need to strike a creative balance.
My first case study of how we could organize ourselves is Starbucks. Starbucks has a castle where queen bees live. They've centralized knowledge about how long it should take to make each drink, where their beans should be sourced from, and they know what every barista needs to do in order for Starbucks to deliver a consistent experience to over 20,000 locations worldwide.
The baristas we meet at Starbucks have domain knowledge and craft. They have the actual muscle memory to make our coffee. And they use their experience to deliver a massive amounts of coffee every day, and do so amazingly consistently.
The thing I conclude is that this model scales amazingly. As long as people want this product, in this way, this organization style is going to be incredibly efficient in delivering that product.
And the queen bees in this picture are essential to the efficiency and effectiveness of this organization. They're not just making the time charts, they're making the signs in the window and making sure there's a steady, and enormous, supply of beans.
In this model, the baristas are so focused on their single tasks, that if the queen bees suddenly disappeared, the organization will fall apart. And our amazingly massive and consistent experience that we get anywhere in the world falls apart with it.
Stealing what I can for RailsBridge, I really love how well Starbucks scales. If there are ways to repeat what they've done to make it easy to create so many stores, we should do that. I'm weary of a centralized set of leaders that everyone relies on, though. That's how we end up with a fragile organization. If there's a way we can use technology in place of leaders to make it easier for more people to hold a workshop, I'm on board.
The next case study is Wikipedia. The way wikipedia gets people to contribute is by having a vision of spreading knowledge that's exciting and engaging, and that people want to be a part of. (Sounds like RailsBridge!)
There's no central leader, directing people to write more articles about this thing or that thing. People contribute where they feel like they can. Every person's contributions can help a huge number of people. If I update the article on Philosophy of Color, which is pretty one-sided thus far, I can help all 4 people, in the entire world who are interested in the subject. It's like every person can be a little tributary that feeds a huge river. RailsBridge should be like THAT!
This also points to the next great virtue of Wikipedia. People who have never interacted, and may never meet, can collaborate on making this article better. (This may seem trivial or obvious to people who have worked on open source projects for years, but I mention it because I want to keep it on the list of something that should be easy to do within RailsBridge.)
My next case study, Alcoholics Anonymous. This case is interesting because in some ways it's the exact opposite of Wikipedia. It's essential to the mission of AA that nformation not flow between clusters. And the larger organization is extremely lightweight. AA publishes two books, and members can buy them inexpensively. And that's all there is to AA. They proclaim their mission and their method and they step back.
As opposed to wikipedia, where people contributed to a river, in AA, each person is part of a silo. They don't need permission to start a meeting; all they really need is folding chairs. The independence of each group is fantastic, and definitely something worth borrowing.
So we have a few examples of orgs that have been successful using super distinct organizational models. It's also possible to combine different aspects of these.
People were not prepared to understand how the internet works: In 1995, NetCom, an ISP, hired a new CEO to help them fundraise. Over dinner, a potential investor hounds this poor CEO, demanding to know,
Who is the president of the internet!?
It's impossible for him to understand that such a large organization that worked so reliably, didn't have a hierarchal structure. And this investor needed to know who was at the top of that structure. Out of frustration, needing to move the conversation along, the CEO eventually gives up and declares "I am the president of the internet! (This is my single favorite story from The Starfish and the Spider.)
Let's look at how it actually works. The internet is a collection of small networks called Autonomous Systems, that can peer with one another to allow another network's traffic onto their network. Networks use the Border Gateway Protocol to send traffic to each other, and each Autonomous can set rules for when traffic from other networks can access their networks.
This is amazing because each Autonomous System is hierarchical or not; it can operate however it wants because it's autonomous. The companies controlling them have a really strong profit motive, and for a while it seemed they were pretty monopolistically minded. Because of the Border Gateway Protocol, we can set rules for how they interact.There's a lot to borrow from all of these examples. I want to steal how well organized Starbucks is. If you come to Starbuck and say "I want to be a barista here" they will say "Welcome to the team, here's how to make a cappuccino." Similarly, if you walk up to me and say "I want to help with RailsBridge. I can host | organize | volunteer at | babysit at | bring lunch for | write curriculum for | start in my town" I want to have something to point you to documentation that makes that as easy as possible for you, and lets you make the best possible contribution.
From wikipedia, I love how the things we do can make things better for everyone. The primary way I see being able to use this in RailsBridge right now is that lots of people catch bugs in our installation instructions or curriculum and send us patches. The more of our workshop documentation that we can make available like this, the more empowered each individual will be to easily make great contributions to everyone. (Incidentally, if you'd like to contribute, checkout the RailsBridge section for lots of links to help!)
And from Alcoholics Anonymous I want to borrow the independence and self-sufficiency of every cluster. Even though we have curricula that everyone can use, when someone wants to have the first workshop in their town they'll still have to be somewhat independent from the groups in San Francisco, New York, Boston, Cape Town, Edinburgh, Colima, etc.
They'll need to fine their own local venue, their own baby-sitter, their own way of recruiting students and their own way of recruiting volunteers. Despite all the generosity and mentorship of people around the world, each cluster needs to be somewhat independent.
And most importantly, from the internet I want to borrow the ability for independent groups to communicate. In our case, I want groups to be able to operate differently, and share back and forth what's working best, and what didn't work well.
So those are the things we're playing around with right now. Everything is an experiment. I'll leave Post Scripts as all our experiments get results. <3