X was created in 2010 by Google founders Larry Page and Sergey Brin. The division's mandate was to solve the world's toughest problems with technology solutions which sounded like they were lifted straight from science fiction. They wanted to create moonshots: solutions that were hugely ambitious, radical, imaginative and definitely not incremental. Fifteen years down the line, there's a whole list of innovations that have rolled out of X and unlocked new approaches to audacious problems. Some, like Google Brain, have found a home in Google, while others like Waymo and Wing operate as subsidiaries of the parent company, Alphabet. Yet others like 280 Earth and Malta operate independently now.

Astro Teller, who leads X and shuns formal titles, preferring to call himself "captain of moonshots" instead, has been with X since 2010 and is responsible for creating X's unique culture that encourages moonshot thinking. A scientist, inventor and entrepreneur, Teller has taken on many new roles in his quest to make X an innovation powerhouse, including that of a "culture engineer." Teller, the grandson of the Nobel Prize-winning economist and mathematician Gérard Debreu and theoretical physicist Edward Teller, who is often known as "the father of the hydrogen bomb," appears set to carve out an impressive legacy of innovation for himself as well.

In this interview with Think:Act, he elaborates on his unique approach to innovation, what exactly makes for a moonshot, how to guide and mentor people working on hugely ambitious projects, dealing with failure, the emphasis on learning and a lot more.

Your aim is to solve the world's toughest problems, but there are just so many. How do you put a finger on something and say: "This is worth our time"?

For something to be a moonshot, it has to be at the intersection of three things. One, there has to be a huge problem in the world that we aspire to solve. Two, there has to be some kind of science fiction-sounding product or service that may be very unlikely, but we all agree ahead of time that if we could build that thing, it would meaningfully resolve that huge problem. And three, there has to be some kind of breakthrough technology that gives us some way to get started, that there's a chance at least that we could actually build that science fiction-sounding product or service. 

Some moonshots aren't technology-oriented in nature: They might be marketing-oriented, for example. That's not what we do. We're a technology organization, so that's a way that we filter.

We're really committed to working only at the intersection of purpose and profit, so there are lots of things that are really good for the world, but can't turn into enduring businesses – we don't go after them. We believe the things that lose money tend to get smaller over time and things that make money get bigger over time. So if we want to do something really good for the world, it needs to be able to make some profit. We also want to make sure that it's really good for the world. We want to be able to say that there was little we could have done that would have been a better way for us to spend our time and energy to help humanity than to do this thing. That's also a way that we put constraints on how we spend our time.

Where do you draw the line between "ambitious" and "ridiculous"? Are there any limits at X?

We have different sayings to try to help people work through this process. One I particularly like is: "We're trying to exercise the non-stupid suspension of disbelief." So, if you work at X and you bring up something and it's not crazy enough, that's actually one of the main ways we would filter something is to say: "Hey, what you just proposed sounds pretty reasonable, so we're definitely not doing it because that's not our job. Someone else will do that." But if you propose something and it sounds unreasonable, like there is no way to get started – "hey, let's make a time machine" – okay, tell me how we would get started with it and if you say "I don't know," that's not a testable hypothesis. 

We want to maximize the reward-risk ratio so if you propose the teleporter and somebody else proposes a pill that cures cancer, I'm happy to talk about both. So you'd each try to make arguments for why it would be so great for humanity to solve those two problems, and then: "What are the risks?" The risks would be regulatory, cost, time ... maybe unintended consequences. We could unpack all kinds of risks in each of them and then decide: "We can't do everything, so let's stack rank these.'" Which has the better reward-risk ratio and maybe in the early days we try both. But if I'm running the cancer pill project and you're running the teleporter project, I need to get some evidence over the next three to six months that helps us understand either that my idea was crazier than it sounded and it's just not a good idea – or it's not so crazy after all. And you try to do the same thing with the teleporter. After six months, we'll see the evidence about which of them we should stop doing and which of them we should spend more money on.

If I'm working on something that has some reward and some risk, and you can find something that has twice the risk, but four times the reward, intellectually, we can agree your idea has twice the expected utility of my idea. We should throw away my idea and work on yours. That's easy to say when you say it abstractly, but I'm willing to bet you've never actually been to an organization that does anything like that. We are not perfect but, at least aspirationally, that's what we do. It's the quality of the lottery ticket that we're judging.

Big, highly ambitious projects take time. How much runway time would you allow a project before you see the first signs of success? 

If you were working on the teleporter at X, I don't mind if it takes a decade to get it working. What I mind is waiting a decade to find out if it's working. So I'm going to ask every three months to show us what you've learned and what that teaches us about the quality of the risk-reward ratio. It may take a decade, maybe 20 years, we have no idea. I'm much more interested in the learning per dollar. If you're learning faster, more efficiently, more holistically than some other project is, great – let's keep going.

We try to be patiently impatient. We want to work on things that might take 10 years, but we want to be impatient every day about the learning. There is nobody at X who thinks that they have 10 years to work on something. I always say do not have a "live to fight another day" kind of mentality because that's what leads most things in the world to end up being ladders to the moon rather than a rocket ship. If I say "show me progress by tomorrow that you're closer to the moon," you will build a ladder and say the ladder is a little higher, but you're never actually going to get to the moon that way. So the right behavior is to talk about what getting to the moon over the next 10-20 years metaphorically looks like. Let's talk about what you've learned and how that's really de-risking getting to the moon. It's okay if you're not at the moon yet, but we should be impatient about that learning.

What mechanisms allow this learning to percolate into the organization so that it doesn't just stay with the person handling that project?

That's actually a pretty central thing that we do. We keep a history of all the things that don't work out, to varying degrees. When something doesn't work out, we do a postmortem and keep it in a big document called "Tales from the Crypt." This has all the things that have died at X: more than a thousand things in it at this point. We also have a celebration at Halloween when we bring things out of the crypt and talk through what we tried, why we tried it, why it didn't work, what we learned from that. So there are ways that we can culturally make it part of how we have fun.

We describe this process by another term: moonshot compost. If you've tried something and it didn't work, many of the people on your project will still be at X along with the patents, the code and some of the partnerships they made. We may reuse the learnings in the postmortem or in other ways – it all goes back into this sort of primordial soup at X, the dirt. The fact that we now have an amazing connectivity solution is because of all the ways that we failed before and the learnings we had. Helping people to understand moonshot compost helps them feel better when a project is killed: It wasn't all a waste. It also teaches them to look in the dirt instead of trying to reinvent from scratch.

How do you shape and maintain the culture at X?

This is very much work in progress. It's the main thing I do. I think of myself as a culture engineer and I would argue many CEOs should be culture engineers to some extent. You have to find ways to send hundreds of signals, some of them very subtle and unconscious, some funny, cultural moments like this "Tales from the Crypt" party that we do, some clear and organized, like written documents that people can read. If you go to the lobbies of most companies, they have glass cases with the stuff that they've made in them. They show almost exclusively the finished product – the shiniest, prettiest version of what they made. What's in our glass cases is the first ugliest junkiest version of some of the things that went on to be great and some of the things that did not work.

We do that to remind ourselves that what we're celebrating is the learning, not the outcome. If you work at X, I seriously want you to work on things that have a one-in-a-hundred chance of working out. If you believe you're going to be rewarded only for a positive outcome, you're going to be miserable because you have a 99% chance of failing. So you have to believe consciously and unconsciously in your head and your gut that it's not stupid for you to do what we're asking you to do. If we show the bright shiny object in the glass case, some part of you, at least unconsciously, will know we're not serious about the process and we are proud of the outcome. So we have to wire that into promotions, into how we compensate people, how we organize teams. Everything has to send signals to people.

A lot of organizations hire brilliant people with great promise, but some don't fit ultimately. Do you hire people for skill or for culture?

I'm sure somewhere in the process someone checks for IQ or capabilities, but that is not what we're hiring for. We rate everyone whom we talk to on fearlessness, teamwork, humility and growth mindset – it is our way of checking that they are going to enjoy the process. Being able to take these moonshots needs very high audacity, which is related to fearlessness, but equally high humility. If I'm asking you to take these one-in-a-hundred shots, first, you have to be able to find these one-in-a-hundred shots and be comfortable taking them. And we need to mentor them, hold them responsible for running the process. But fundamentally, if they have a fixed attitude – "I know how to do this stuff"– they're going to be miserable at X.

Is psychological safety also a component of this?

Let me get on a soapbox for a second. Psychological safety does not mean that nothing bad will ever happen to you under any conditions. It's a commitment from the organization, from the context that you're in, that what you say will never be held against you as long as you say it respectfully. Then you can speak your mind. Because we want to have a free-flowing place of ideas where my ideas and your ideas can clash together and the sparks that fly off of them are really where the value is. If you're an electrochemist and you work at X and the project that you're on ends, I can't promise you another job at X – it depends whether we need an electro-chemist somewhere else. But that can't be a reason for you to not practice intellectual honesty about whether or not the thing you're working on works. Psychological safety isn't: "I have a guaranteed job." Psychological safety is: "I'm going to be seen for who I am. I'm going to be respected for who I am and for my ideas."

How do teams come together? How do you make sure that they work together without any friction and it's seamless and collaborative? 

Building and maintaining a high-functioning team is a hard skill to learn. That's the work of being a leader – and not just me, but for lots of people at X who are trying to build teams. Yes, there's a lot of fluidity at X, but if I was running the teleporter team at X, I would say, "Welcome to the team! Here's our local subculture and how it makes sense within X's broader culture. We want your ideas including your thoughts about our culture to influence it, but you also have to be part of the team because this isn't about what I think, or what I want – or what you think, or what you want. It's about what we as a team can accomplish. If at some point you stop enjoying being on the team, feel free to look around X and join another team. If at some point we get too big and you want to go back to the early part of the process, please don't stay on my team." That's what I would say if I was running one of the sub-teams.

How much of your time goes into managing teams as opposed to being part of these moonshots?

I wish I got to spend more time on the moonshots themselves. I help with aspects: technology, storytelling, partners ... but that's probably 20% of my time. I'm doing a lot pan-X to help the organization function and to implement strategic issues in ways that will then set the foundation that makes it so that the leaders of individual projects can thrive. I spend most of my time being a mentor, quite a bit still on being a leader and a decent amount being a manager. Management is about having a clear set of things that have to get done, distributing those among people, holding people accountable for getting their individual pieces done and then making sure that they get sewn back together.

X is an unconventional fast-moving setup that is connected to and sometimes feeds into a larger corporate setup. When these experiments do make it back to the larger corporate setup, how do you manage the assimilation?

Google is a very large company that has a lot of surface area. X's job is not to improve Google, so X is culturally and operationally separate from Google – and that works partly because we're mostly not feeding back into Google. Our job is to find new problem areas, new challenges with the world for Alphabet to be working on and hopefully solutions for those problems. So the cultural and operational separation that we keep helps us to show up in the ways that we do. It allows Google to focus on the things that it does. That works for both sides, and then of course, sometimes something that we make here, like Google Brain many years ago, went to Google and has been very good for Google. More recently, in the field of auto-coding, Codey at Google came from X. So those are examples of things that we did at X that found really good homes at Google, but for the most part, we create other bets like Waymo or Wing. They are within Alphabet, but they are not inside Google. In fact, increasingly we are putting them outside Alphabet altogether.

Sometimes things that we do go back to Google but that is not our goal. Alphabet would be very satisfied if we never sent something back to Google ever again. Our job is to work very hard on very unlikely things that have some chance of being really good for the world and becoming enduring businesses over time. We're continuing to fine-tune how we graduate things and set them up as businesses, so that they're just outside the Alphabet membrane, so Alphabet can still have a very close relationship with them, but by not technically being part of Alphabet anymore, they can move much faster and much more independently.