How We Crowdsource Innovation
Three years ago, rLoop started with a thread on /r/SpaceX. Approximately 40 people responded to the thread and filled out a collaborative Google Sheet with their name, area of expertise, and number of hours they could commit weekly. Today we have one of the most advanced Hyperloop prototype pods ever built, and over 1,300 people from more than 50 countries have signed up to join the community.
The entire process was organic, with the community learning first how to facilitate virtual collaboration on complex and interdependent work, and subsequently how to translate that into a real world, functioning prototype.
How did we do it?
The first major component is the platform. At rLoop, we were running before we learned to walk and were subject to an aggressive schedule from SpaceX. We tested a few methods for communication before finding our home on Slack. We used it to drive discussions into appropriate channels, as well as to delineate teams and sub-teams. Bots were created to help recall information and capture knowledge, and eventually we added Talla for AI support. The platform, ultimately, was used to manage the pools of talent, resources, and work within the community.
The complexity of the problem we were solving and the fluid nature of the community required decomposition of the work. In computer science, decomposition is breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain. We called them ‘microtasks’ — bite size tasks that anyone, regardless of their prior knowledge or experience within the community, could claim and contribute towards. It was important for us to provide an easy way for new members to contribute without having to read through thousands of pages of technical reports and prior design decisions. This also fostered an early sense of accomplishment and a desire to continue contributing.
Organization within the community was necessary to facilitate microtask design, assign the tasks to relevant teams, and communicate interdependecies among all teams. We broke down the teams based on specialties (i.e. #eng-systems, #eng-mechanical, #eng-software, #eng-avionics, etc.) and then sub-teams as necessary (i.e. #eng-mechanical-brakes, #eng-software-ai, #eng-avionics-battery, etc.). Natural hierarchies within teams emerged, largely based on social reputation but also on availability — we were all volunteering our time, which required subtracting that time from our families, our social lives, or our personal hobbies. Not everyone can consistently offer several hours a day to collaborate with strangers from the internet.
As tasks were broken down, they could be assigned to relevant teams and organized into workflows. We required tools with advanced functionality to allow real time collaboration of complex work. Autodesk provided several solutions, including Fusion360 for real time collaborative CAD. ANSYS provided simulation tools, and GitHub was used for software development. Google Docs was used for collaborative document creation, spreadsheets, and presentations, while Hangouts was the primary means for team video-conferencing. We used JIRA for task management, workflows, and some project management, and Confluence to capture knowledge — both tools from Atlassian. (Tom’s Word of Caution: it’s not only about the tools, but how you use them, and we had to use them right to survive — that’s part of what made rLoop special!)
Quality control was required throughout to ensure the output of the work was of high quality and integratable with its dependencies. This was largely done collaboratively, with peers reviewing work and providing constructive and actionable feedback. In many cases peer review was provided during the work process, allowing us to identify and mitigate issues early. In some cases, standards for work were set in advance, though this was somewhat burdensome and not particularly effective on its own. There were some instances that required a dispute resolution mechanism (though nowhere near as frequently as we expected). In such cases an unbiased assessment of the issue was discussed openly and, if necessary, an anonymous vote could be held.
Manufacturing was an entirely different challenge for our virtual team, but a lot of the processes we had already developed for virtual collaboration were applicable. We established a testing and integration lab in proximity to the final destination of the prototype. We leveraged community expertise and access to specialized equipment to have components (and in some cases, entire subsystems) manufactured remotely, and then shipped to the integration lab. We pushed the limits of the collaborative tools available to us in order to connect our on-site manufacturing team with the virtual and distributed design team. And we asked external experts to review and advise throughout.
This framework resulted in a community of geographically distributed individuals to collaborate and create some very complex engineering solutions.
And the first time we saw that vehicle fly was magical.
After our success at the SpaceX Competition, the community continued to work on the rPod, and had the opportunity to demonstrate it’s hover capabilities publicly at Autodesk University 2017.
This mechanism to drive knowledge, expertise, and resources into large scale engineering projects is what we are continuing to refine at rLoop. I’m planning to write more about the details of how we grew our community, how we facilitate global collaboration on complex projects with interdependent work, and our thoughts on the future and possibilities of reimagining how people work together. If this is of interest to you, I encourage you to follow me here on Medium as well as on Twitter. You can learn more about rLoop at the website and our subreddit (of course).
Special thanks to Tom Lambot, my co-conspirator, for always helping to flesh out the intricacies of the work we have dedicated ourselves towards.
