Empowering creativity through mistakes
This interview is part of the second issue of Featuring, a newsletter celebrating creative entrepreneurship. Read more and sign up here.
Photo by Elizabeth Lippman.
When we first approached Jocelyn Leavitt to talk about failure, her response said it all: “I don’t like to talk about failing. I like to talk about winning.” But as the CEO and co-founder of Hopscotch, an educational app that introduces kids and adults alike to programming, Leavitt knows that mistakes are part of the learning process.
The Hawaii-born, Brooklyn-based entrepreneur does her fair share of winning. Leavitt recently made Fast Company’s list of Most Creative People in 2015 and Hopscotch has made a name for itself as the first-ever programming language designed to be written on mobile. The application has quickly become a favorite among kids, parents, and teachers, as an accessible entry point for anyone to learn how to code.
We spoke with Leavitt about learning, failing, and empowering others to do the same.
Tell me how Hopscotch got started.
My co-founder, Samantha John, and I met about four years ago through a mutual friend. At the time, we were both interested in technology and the startup community in New York City, and were hacking on a few different ideas. We worked together at the TechCrunch Disrupt Hackathon and got a lot of attention for a hack we did there before coming up with the idea for Hopscotch.
We also looked around and realized that there weren’t many female founders and even fewer female engineers. When we asked our male engineering friends (mostly upper-middle class, white, nerdy guys), how they got into programming, we heard a similar story over and over again. When they were 10, 11, or 12 years old, they fell in love with video games and wanted to learn how to program them themselves. By the time they were in their twenties, many of them had already been at it for 10 years.
We were like, “Why is there no corollary for girls?” Hopscotch became the tool that we wanted for ourselves when we were growing up.
And then you built the first-ever programming language explicitly designed to be written on a mobile device, a crazy endeavor in itself.
It’s kind of amazing to think that we did it. We asked ourselves, “Why isn’t anyone else doing this?” I think, partly, it’s hard enough to fit everything you want onto a computer screen, but to get it onto a tablet is even harder. We still don’t have it on phones, but it’s in our future.
We’re on the precipice of this huge opportunity where everybody has mobile devices. The installation base for mobile devices is an order of magnitude greater than it was the previous generation of hardware (laptops). If this is a computer that everybody has, it stands to reason that people will want to create native content on it.
Right now it’s perceived that software is this new type of media that a lot of people consume, but very few can create. We really believe there’s a huge opportunity for anybody to be able to create their own software. This is what we’re out to prove.
What are some of the things people are creating?
You can go into the Hopscotch app right now and see everything from little animations to programmatic art to games. Since kids are our primary users, they get really excited about making games. One thing we’ve heard is that it’s more fun to make a game than it is to play a game—which we love.
We really try to push is this idea of being able to see what’s out there and modify it. Any user can go into our community, play with a game, and if they think it’s too easy or too hard, change it themselves. They can change the characters, the speeds of things, anything.
Do you see trial and error as a big part of the learning process for your users?
We’ve seen girls can be a bit more tentative about not being able to do things the right way on the first attempt. Since part of the original mission is trying to get more girls on the platform, we actively try to encourage trying something to see what works. If it doesn’t work, maybe you created something else or you learned something else along the way. Sometimes, we’ll see projects that say, “I was trying to make a star, I tried to make a snowflake, but oh well,” and it will be some other design. I think that’s hugely important for any creative endeavor. You just have to start doing it and the volume of experience accumulates over time.
How do you design for that?
We try to make it really easy to publish, even if you’re not ready. Your project doesn’t have to be perfect. If you put it out into the world, someone else may build on it or another great idea may come out of it. This is a creative medium, and just like you wouldn’t call a painting wrong, you might admit that maybe what you published wasn’t exactly what you were going for, but keep trying. At the end of the day, you’re still busy engaging your brain, imagining something, and trying to build it. That’s really empowering.
What were some of the earliest lessons you learned by putting Hopscotch out into the world?
Ship quickly. I’m fortunate to have a co-founder that is very complementary to me. I like to sit there and tweak things until they’re perfect and Sam’s like, “Ship it! Ship it! Ship it!”
We released Hopscotch in April 2013 at her insistence. I was not ready to let the product go. It’s advice that you hear all the time when you’re first building a company, but it can’t be repeated enough. If you’re somebody like me who just wants to sit there and perfect it, you can’t. Just ship it and iterate.
You have to throw a lot of sh*t at the wall and realize that you’re going to make mistakes. Do fast releases in small cycles and if something is working, dig into it and if it’s not working, drop it and move on to the next thing.
Another mistake you can make is having a co-founder who has a skill set that’s too similar to yours. I think it creates a lot of tension and it makes it hard to figure out whose responsibility it is to do certain things. That’s a mistake I made before Hopscotch. I got together with a friend from grad school, but we basically had a completely overlapping skill set.
There seems to be a lot of talk in the startup world on failing harder and making mistakes, but, for a lot of people, those critical mistakes can make it really hard to move forward.
Startup founders are constantly having to project this aura of invincibility and how things are going well. That can be really hard. You have to be selling your company to everyone all the time—even if there’s nothing to sell. Talking about failure is a good and honest instinct, but I think it’s understandable why people don’t like to talk about failure as much. For me, it’s not failure, it’s just, “That didn’t work out.”
How do you then encourage your team to take the risks necessary to learn?
Set expectations ahead of time and just try it. Make it really clear that you don’t know what the outcome is going to be. Make it part of your culture. As a leader, you have to walk the balance between telling everybody about your failures and not letting them lose faith in you as a decision-maker.
I find the best way to do that is to be super transparent. Talk with everybody. Solicit opinions. Sometimes it takes a little longer, but it’s worth it because everybody feels invested and sometimes you get really good advice. I think having a transparent team and culture of communication is really, really important. Be super candid about goals and what you’re trying to achieve, then be honest when evaluating whether or not it worked.
Can you speak to any practices or things you put into place to build that type of culture at Hopscotch?
We have a Slack channel where we share goals along with investor updates and board notes. We have this tradition on Friday afternoons, when everybody sits down, has a beer, and shares their weekly goal. We look at the last week’s goals and see whether or not we’ve met them. If you haven’t met them, it’s not too big of a deal. Maybe you feel slightly embarrassed, but all of us have at one point or another not been able to meet our weekly goals.
Every time a project iteration ships, too, we get together for a couple of hours and talk about what went right and what went wrong, what people were happy about and what they’re bummed out about. We try figure out processes to improve it for next time.