The following is an adaptation of a talk that I gave at the Lesbians Who Tech Summit in San Francisco last week.
Play is a consistent theme in innovation. Today I want to share with you how I have used play to solve problems in unique ways throughout my career, and how playing, collaborating and being willing to break things has helped me invent new ideas to solve really hard problems at X.
When I was growing up, my mother, a Freudian psychoanalyst, would often reference Donald Winnicott’s theories about the creative process. Winnicott was a British psychoanalyst and he wrote that play is the basis for all creativity: that being in a state of play creates a state of trust and relaxation, a “non-purposive” state where the need to make sense is absent, so that free association can happen. Winnicott also said that all disciplines, not just the arts, but science and engineering too, can be understood as highly developed forms of playing. This philosophy has resonated with me throughout my life and career.
Since the age of two, I have loved playing and building. I started with building blocks and Duplos, then I graduated to Legos, which I played with with for hours on end, building giant, elaborate scenarios like castles and space ships. One of my earliest creative memories revolves around a cooking experiment around the summer of 1988. I was about four years old, and had been left alone in the kitchen for a few hours. With all the enthusiasm and excitement you’d expect of a preschooler, I grabbed every ingredient in the pantry and mixed it into a bowl. As you can imagine, the result tasted GROSS, but it was my first time “cooking”. It was so gratifying to be given that unstructured space to play, and to make things with whatever I could get my hands on.
Playing and building with Duplos at the age of 2, and with a robotic snake I made more than 25 years later
Today, not much has changed. I still love playing and problem solving, but now it’s with hardware, such as sensors and motors. Since I started coding and making analog circuits, I have become addicted to playing with new sensors and microcontrollers, and to making new creations, from small walking robots, to BEAM solar powered robots.
A BEAM robot I made in 2010 that performs “phototropism,” aka waddling towards the light
This love for working with code and building mechatronic systems grew in parallel with my passion for solving big problems that have a positive environmental impact. From 2008 to 2010 I was a wildland firefighter in Oregon, and through this work I saw the potential for technology to help in disaster relief situations. In the offseasons I taught myself how to code and how to make little robots with sensors and actuators that could go out and explore the environment.
One of my ongoing projects has been a series of swimming snake robots, called Sneel. These snakes mix their organic form with a high tech function: they carry sensors so they can send data about the quality of the water they’re swimming in back to shore so you can test things like oxygen levels or toxicity.
Sneel: Swimming, sensing snake robots that can send water quality information back to shore
These swimming, sensing snake robots were influenced by some of the thinking behind the company I helped start and grow from 2011, called Protei. Protei brought together global communities of makers and creators passionate about environmental activism to make a fleet of open source, shape-shifting robotic sailing vessels. These robotic sailboats move like snakes on the water, to carry sensors to explore and help preserve the ocean.
While working with the Protei team, I facilitated hackathons and workshops around the world, teaching people collaboratively to build and test DIY robotic boats to collect ocean data. Some of the collaborations I worked on included mapping radioactivity off the coast of Fukushima in Japan with global citizen science project Safecast, and mapping plastic trash in the middle of the Pacific Ocean.
Protei’s open source shape-shifting robotic sailing vessels
At the heart of these projects were communities that were open and collaborative. As my X teammate Obi Felten has pointed out, the myth of the lonely inventor is indeed a myth. In my experience, collaboration is just as important as play in fostering invention and creativity. Working with people, hands-on, to build creative solutions has been a huge source of my learning and inspiration.
This is why I’m passionate about open source hardware, which emphasizes sharing to foster innovation. For a few years I was President of the Open Source Hardware Association, an organization that promotes and educates people about the value and applications of open source hardware, and during my time we ran workshops on open-source hardware best practices, and begun working on the open source hardware certification.
The Protei team in Rotterdam in 2011
It might sound unusual that building snake-robots, fighting wildfires and working in collaborative building environments could lead to working at X, but it meant that the Rapid Evaluation team was actually a great fit for me.
The Rapid Evaluation team is made up of a small group of people whose job it is to constantly come up with new ideas, in order to prototype and evaluate future “moonshots” for X. It might seem counterintuitive that a company working on serious global problems would embrace a culture of play and creativity, but it’s essential: we bake experimentation into the culture. We give people with the capacity to be radically creative the freedom to play, hoping that they will discover new technology breakthroughs along the way.
The team is diverse, and we all work a bit differently, but my “recipe” for rapid evaluation is roughly as follows: research, prototype, break stuff, test, evaluate, break stuff again. A lot of what I do is early stage research and we call these “investigations”. Sometimes these investigations entail working with experts in the field, reading scientific papers on things as diverse as new forms of wireless communication or water desalination, playing with new sensors or hardware technology, or going into the field to work with scientists or communities to see how others solve problems. For example, last year I went with a few of my teammates to East Africa to explore conservation and education issues, human/animal conflicts, and how technology solutions might have positive impact.
Visiting the Bridge Bridge International School in Naro Maru, Kenya
Prototyping and evaluating stuff in the lab is a key part of the investigation process, and while it looks different every time, one of my first steps is often to hack off the shelf parts and put them back together in new ways. I often will break something apart to see what it looks like on the inside. Once I understand how it works, I typically put it back together in different ways to make low fidelity prototypes (it’s amazing what you can do with hot glue and tape).
This process is very playful and hands on, and I do a lot of the work in the Design Kitchen, X’s prototyping and fabrication shop. The Design Kitchen is basically a playground for creativity and hardware design. When I’m in there I’m reminded of the feeling I had as a little kid in my parent’s kitchen, cooking for the first time with access to all the ingredients I needed to whip up some wild concoctions.
Some of the Design Kitchen tools
Not only do I build a lot, but I’m also known on my team for breaking the most things. This happens because I’m always trying new things, quickly trying new ways of fabricating, embracing things I know little about, and learning a lot in the process.
A few years ago, during the early stages of Project Wing, we were investigating new ways to deliver lightweight packages, cheaply, with gliders. This meant I had to learn how to fly fixed wing hobby airplanes quickly. This also meant that I crashed a lot of fixed wing hobby airplanes quickly ;)
As you can see from this early stage Wing prototype duct tape is an essential fabrication material
Failing fast, the approach that X embraces, does not necessarily mean breaking things, but it does mean that the Rapid Evaluation team likes to do whatever we can to make an early stage investigation fail. This is because the more resources, people, money, time and love you put into a project, the higher the cost of failure is and the less likely you are to take big risks over time. By running at the hardest parts of the problem first, or frontloading the risk through a lot of low cost early stage testing, we ultimately save a lot of time and money.
One example of a project I worked on that we killed, was an investigation into automated vertical farming. One in nine people on the planet suffer from undernourishment, so there is clearly a demand for radical new approaches to food production. Vertical farming uses 10 times less water and 100 times less land than conventional agriculture, and you can grow food close to where it’s consumed, so you don’t have to transport it long distances.
Our automated lettuce garden investigation
To investigate vertical farming’s potential, I set up an automated garden and grew a lot of tasty lettuce. This is another example of being playful and hands on, and I learned a lot in the process. For example, I learned how to automate lettuce harvesting and create more efficient lighting. Ultimately we ended up killing this investigation because we realized that it wasn’t going to have sufficient impact. This was for two reasons: first, we couldn’t grow staple crops like rice or grains in this way, and second, the energy cost per unit square was too high to make this a viable solution to get food to the parts of the world that need it most.
It may sound hard to kill projects that you put a lot of time and effort into, but I’ve really embraced the attitude of NOT dwelling on the failures. Instead I use the LEARNINGS and apply them in new and creative ways to solve the next big problem that arises. And I always remind myself that giving myself the time and space to play, and experiment, will prepare me for the next big challenge that comes my way.