Learn
This is a talk I gave at the International Women’s Day Women Techmakers conference on March 5, 2016. I’m posting the transcript with slight edits for context and clarity.
I work at X, formerly known as Google[x]. We are the team behind self-driving cars, self-flying delivery vehicles, smart glasses, smart contact lenses, energy kites and balloon-powered Internet. We work on solving large problems in the world with technology.
Project Loon is experimental technology for balloon-powered Internet access.
But my talk isn’t about X. My talk is about how to kill good things — a good idea, a project or even your current job — to make room for truly great ones.
We don’t like killing our own projects because it’s hard — really hard!
Two things stand in our way: Fear and inertia. To overcome these, you have to tackle them head on.
Newton’s first law of motion states: An object at rest stays at rest and an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force. The bigger the mass and the faster the object is moving, the more force you need to apply to stop or divert it.
Once we’re on a path, it’s much easier to just keep going. But the longer we keep going with a project, the higher is the opportunity cost if we kill it eventually.
At X, we therefore try to kill as many projects as possible as early as possible.
Our process starts with a small team called Rapid Evaluation, or Rapid Eval for short. They are polymath scientists and prototypers who create and rapidly evaluate new project ideas. The majority of their ideas never see the light of day. That’s the goal. We want to move quickly from idea to prototype, and fail fast if it doesn’t work. Only 3% of Rapid Eval ideas make it into the second stage and become a Foundry project.
Foundry is my group; we are a team of product managers, engineers and strategists. Our goal is to reduce technology risk, but also find product/market fit and come up with a business plan. Within a year, we either de-risk the project to a point where we are ready to grow it — or we kill it.
Only half the Foundry projects are expected to survive. This is one of the reasons we don’t hire a General Manager for a project until it graduates from Foundry; they are often the last person who wants to kill their own project!
We know that there is professional opportunity cost to X for every project: The longer we have a team working on a project that no longer makes sense, the more resources we waste.
But the personal opportunity cost for the team members is also high. When you wake up in the morning, are you excited about going into work? Or do you secretly think, I’d rather be playing with my kids, or be sailing across the Pacific in a small boat? If that balance tips, it’s time to change something.
Killing our own project is scary. We are afraid of losing the respect of our peers, a promotion, or even our job. We are afraid of the unknown; what happens next.
I had a big crash early on in my career, which redefined my relationship with that fear.
In the late 1990s, I was working for a high-flying strategy consulting firm. I did a lot of Internet strategy projects, for example: Should we sell insurance online?
In 1999, when all my friends went to business school, I joined a startup instead. It was called eToys.com. You can guess what we were doing, we sold toys online.
I was a product manager on the UK website, and then the first person to start eToys in Germany. I set up the company, I hired the team, I worked on the website. In the summer of 2000, a week before our German launch, our board back in California pulled the plug on us. eToys was losing too much money too fast, and expanding to Germany was not a priority.
I had to fire everyone I had just hired and sold on the Internet dream, including people who had left 20 year careers in retail with a good pension scheme. It was really, really horrible.
And it didn’t save eToys; we went bust anyway. In the Europe, we saw the writing on the wall. We let all our staff go a few months later, one week before Christmas. That was horrible, too. But everyone got paid, and we closed the company down in an orderly fashion. In the US, eToys kept going until the creditors showed up at the office and started impounding the furniture.
What eToys taught me is that no matter how bad things get, when your company is going bust and you have to fire your friends, it’s still better to face that reality earlier and move on. I’m still friends with many people from eToys, who went on to do bigger and better things.
Having this experience so early in my career made me fearless.
Well, actually it didn’t — I still often feel scared. (I felt scared just now walking on stage to do this talk! That’s why I am holding on to my phone with my notes.) But I have trained myself to be brave and face the fear, over and over again.
When you decide to kill your project or your company, you need a lot of bravery. But it’s not like we have the opportunity to do this every day.
So how can we practice bravery?
Turns out that there are plenty of opportunities to practice bravery during the lifecycle of a project, or indeed your career.
We have all done this in our first job. Do you remember that scary first day of showing up at the office, and having no idea what is going on?
I did such a jump into the unknown three years ago when I came to X, leaving behind a great role as Director of Consumer Marketing for Google in Europe. I left a team I loved, where I knew everybody. I left a credible career in marketing; I was number four on the list of UK top marketers, right after the CMO of P&G. I uprooted my family from the UK, my home for over 20 years.
I was excited to begin a new challenge, but also scared about joining a team that was all scientists and engineers as a non-scientist, non-engineer. Neither they, nor I, knew what exactly I would do, and whether I would be useful.
So how did I get over that fear? I gave myself a safety net. I agreed with Astro Teller, my new boss at X, that I would come for six months to try it out. I convinced Yonca Brunini, my old boss in Europe, to treat it like a maternity leave: I would be back in six months, just like after having a baby!
After three months, I called her and told her I would not be back. I was staying at X for good.
I attribute some of my success in leading teams to my willingness to ask lots of stupid questions.
In my job I have to learn about a new area all the time. I am often the person in the room that knows least about a topic; my team knows far more than I do. So I ask lots of questions. Often it turns out that others in the room also didn’t know how something works, or what that acronym stands for. And I found that the experts are incredibly patient and love to explain things — if you ask them.
Although I’m not an engineer myself, I lead engineering teams. At first, I found this intimidating. How can I add value if I can’t be their tech lead?
It turns out that it’s very valuable to check assumptions that are held by everyone. Widely held assumptions often mask decisions that haven’t actually been made, and can lead to confusion because everyone assumes something slightly different. Other times my questions point to something we haven’t thought about at all yet.
Turns out that stupid questions can in fact be difficult or helpful questions.
Google has always had a ‘launch early and iterate’ principle. Gmail was famously in beta for five years. When we first launched Chrome, many websites didn’t render properly in it.
At X we work on hardware, which takes longer than software to get to production. But we still bring our prototypes in contact with the real world early, long before they are finished products in the conventional sense.
Our self-driving car prototypes have driven hundreds of millions of miles on real roads, testing our hardware and software. With Google Glass, we launched an Explorer program that allowed us to get an early version of the device into the hands of a lot of different people. From surgeons to chefs to oil engineers to fashion models to parents, these brave explorers gave us feedback on use cases as well as the device itself. The feedback was invaluable, and ultimately led the Glass team to focus on business use cases rather than consumer.
A self-driving car testing on the road in Austin, Texas.
It’s always better to get that feedback earlier rather than later. This doesn’t just apply to products: It might be a half-baked idea you share with your team, or paper wireframes you test on friends and family.
What matters is that you don’t keep polishing things until you are 100% comfortable before you share them, because by then it’s too late!
It can be scary if you are the only person in the room who has a different point of view.
Our first use case for Wing, our drone project, was to deliver defibrillators to people after a heart attack. Every minute counts, so we hoped to save lives by delivering the defibrillator faster than an ambulance could get there.
This assumption turned out to be wrong. Matt, one of our user experience researchers, put people in the lab with a dummy, told them this was a person who just had a heart attack, and handed them a defibrillator.
His research showed that it can take several minutes to figure out how to use the thing. And if you do it wrong, it doesn’t work at all.
The team was in love with the idea of saving lives by delivering defibrillators. Some of them had joined the project because of it.
Matt had to keep showing the data and his conclusion over and over again. He got help from Laura, one of my team members, to finally convince the team to let go of the idea. We still think that delivering stuff with flying things makes sense, but we won’t be delivering defibrillators.
Finally, let’s get back to killing your own project.
I already mentioned that 97% of Rapid Eval ideas get killed. Earlier this month we closed down a Foundry project, after the team came to the conclusion that it no longer made sense to pursue it. They wrote a detailed post-mortem explaining why, and presented it at the X All Hands meeting. Later this year, we hope to publish the findings in a peer-reviewed journal.
The important part is this: I didn’t kill these projects, nor did Rich DeVaul who runs Rapid Eval. The teams did it themselves. Xers are encouraged to kill their projects as soon as the evidence is on the table — and they’re rewarded for it.
In Rapid Eval, they get a sticker to add to their laptop as a badge of honor.
People get applause from their peers.
They get a spot bonus from their manager (I just gave one to the Foundry team that closed down their project).
They get promoted because of it, not despite it.
They get exciting new jobs — as soon as a project closes down, people get snapped up by other X projects.
In other words, we remove the fear and make it safe for people to kill their project.
In Radid Eval, these crumpled paper stickers are a badge of honour. Each one stands for an investigation that was killed.
Some of you might be thinking, that’s all very nice if you work at X, but my organisation is nothing like this.
If you are a founder or a team manager, it’s your job to remove as much inertia and fear as you can for your team. If you work in a team where the culture is not supportive of this kind of behaviour, you have two options: Change the culture, or move on.
In between eToys and Google, I spent 5 years working in brick and mortar retailers, starting and growing ecommerce businesses. I often felt like an alien that had landed on another planet. In my last job in retail, the culture in my ecommerce team ended up being quite different from the rest of the company. A physical manifestation of this was that we painted the walls of our drab office pink and turquoise as a fun team event. The rumour that the crazy ecommerce team was painting their walls spread quickly throughout the building, people kept sticking their head in the door to check it was true.
But the wider organisation remained unchanged. In the end I wasn’t patient enough, nor savvy enough about corporate politics to succeed in that environment long-term, and I left for Google. When I walked into Google, it wasn’t just the primary colours of the logo and the bouncy balls that reminded me of eToys and made me feel at home.
So far I’ve talked mostly about why it’s so important to teach ourselves to be brave, and how to practice bravery in our own work and lives.
Arguably it is even more important to teach bravery to the next generation — especially our girls.
Reshma Saujani, the founder of Girls Who Code, did a great TED talk a few weeks ago. She talked about how boys are taught to climb to the top of trees and fall down and scratch their knees trying, while girls are taught to be pretty and perfect. She talked about how boys are happy to share unfinished and imperfect work, while girls would rather show a blank screen than their failed attempts to solve a coding problem.
My daughter is 2 years old, and I’m proud to say she’s a fearless climber. I first discovered this last summer when I was chatting to to a friend in the playground and not paying attention. Another parent came up to me, tapped me on the shoulder and said very disapprovingly: “Is that your child on the top there?” I turned around to see her on top of the big kid climbing frame. I was scared, and very proud!
This is a picture of my daughter at the climbing gym last week.
Climb until you run out of wall.
She was about 2 meters off the ground when she ran out of wall. I hope she will always keep climbing on, all her life.
You are all working to build incredible things. I hope I’ve inspired you to bravely kill a lot of things along the way.
Postscript: Yes, we are hiring. http://www.x.company/join/