Episode 5: Shishir Mehrotra of Coda

Come on into the room. The Room is a series that lets you get a view into the room where it happened.

I'm Claudia Laurie. And I'm Madison McIlwain, your co-hosts.

2020 brought us rapidly into what commentators are calling the future of work. A buzz term used to describe the different ways the modern white-collar employee will continue to engage with their teams. The future of work is here now, largely due to COVID-19's acceleration of a remote-first culture. Our guest today knew there needed to be a better tool for team collaboration and set out to define and build the platform of the future. Shashir Mehrotra is the founder of Coda.io, a venture-backed workflow tool recently valued at over $600 million. For those of you who haven't leveraged Coda yet, you can think of it as Google Docs on steroids. It allows for seamless integration of files, asynchronous commenting, and even a poll function for those virtual offsites we're now all too familiar with. Given the recent acquisition of Slack, an early disruptor in this category of work, for $27.7 billion to Salesforce, begs the question, what's on the horizon for tools such as Coda? With top-tier venture investors such as General Catalyst, Kleiner Perkins, Madrona Venture Group, and Greylock, This isn't Shashir's first rodeo. In fact, in the year 2000, he was graduating from MIT with a computer science degree and starting Centrada. Centrada was an early player in the utility computing storage space backed by Kleiner Perkins. For our younger listeners, you can think of it as AWS or the cloud before the cloud existed. After moving on from Centrada, Shashir jumped between roles at Seattle's storied technology giant Microsoft and the then younger, flashier Google and YouTube team in the Valley. In 2014, Shashir left YouTube to build what is now Coda. The company recently transitioned out of stealth mode in 2019 with large name brand customers such as Uber, the New York Times, and Spotify. A father, a thought leader, and of course a founder, Shashir reminded us to stay curious and ask the big questions, or as he likes to call them, Iken questions. In today's episode, we'll explore insights and themes such as prioritizing opportunities that foster personal growth, the benefits of building a company in stealth, and scaling a distributed workforce and culture well. Let's open the door.

We have so much to discuss, so we're going to dive in starting with, please walk us through your early life before MIT. Did you think you were always going to be a founder?

I was actually born in Buffalo, New York, which very few people know. We didn't live there that long because my dad was a grad student there. I ended up finishing a PhD at UVA. So I did all my sort of early childhood, a variety of university towns. So University of Virginia, and then we lived in West Lafayette, Indiana while my dad was a professor at Purdue, and then came back to Virginia and my dad was at NASA there. Actually, my mom was as well. He's still at NASA, actually out here now. And then from there, moved around a few times around there and then ended up in Boston going to MIT for college. So I had an interesting childhood. Most university towns, everywhere you look, I was one of those kind of confused kids going in college. I didn't really know exactly what I wanted to do, and I had been through every career choice there was. And, you know, if you ask me one year, I wanted to be a doctor, another year I wanted to be a lawyer. I went through all the different periods of it. And somehow right when I get to college, it started clicking into computer science. And I had this really interesting conversation where I called my dad and said, okay, I think I'm going to do computer science. And I expected him to be really excited about it. He said, if you do that, I'm not paying for college. And I said, "Really? That's kind of surprising." He has this viewpoint that's pretty strong about it. And he basically said, "I'm only paying for college if what you major in has books that are at least 50 years old." His viewpoint is that computer science changes so fast that as you go through it, you know, by the time you're through it, everything's already old. And so from his perspective, I was actually a math major. I ended up dual majoring in math and computer science. And so I would say, you know, I probably somewhere in that path, I thought I'd be a founder or a startup, but it was nothing ever stuck. That long for it. And, you know, from my parents' perspective, I was a mathematician that happened to switch.

That's so great. I love that your dad was anti-computer science. I think most parents today are pro-computer science to the kids' detriment.

Yeah. Well, to be clear, I mean, they're both— I mean, my parents, both of them are computer scientists. It wasn't an unaware, unaware viewpoint.

Oh, my goodness. Well, like many computer scientists, or should I say software engineers coming out of college and the MITs of the world in 2000, you couldn't miss the height of the dot-com boom.

I think you graduated in the year 2000, if I have that correct.

Yeah.

And right out of college, you founded Sentrada, which focused on data center management technologies. Chuckling because I happen to know the cloud didn't really exist as a concept in the year 2000. So what data were you managing?

Yeah, I mean, it's probably worth defining a little bit. Sentrada's original viewpoint was that the idea was to be a computing utility. And there's actually a set of companies around this time focused on this, all with the same basic observation that, you know, if you want electricity or water or so on, you can just order it up and whatever you use, you pay for and you can scale up and down. And, you know, none of us really think about them anymore, but that's not what computing felt like at that time. So there was this wave of companies focused on utility computing and all of us were probably, you know, somewhere between 6 to 10 years too early because as you pointed out, none of the basic technologies of the cloud really existed. All of us aspired to become what AWS became or what Azure and the Google App Engine became. That was the original idea. But at the time, the underlying technologies that make that possible, virtual machines, containers, all of these things that allow you to use resources and quickly move around computing and storage and so on, they didn't really exist. It's actually kind of relevant to what ended up happening to Coda. I went, so we start Centrada and we're out talking to all these different potential clients And one of the most interesting meetings, I ended up talking to a guy named Chris Coles. He was the CIO at Quest. AT&T went through multiple phases, got broken up, got put back together, so on. So Quest is basically AT&T of the Southwest. I fly down to Denver meeting Chris Coles. I asked him this question. I was like, how I would start my pitches. I would say, what percentage of your computing resources do you think you use? And actually, there's one other piece of background. Quest and a bunch of other companies were starting what was, what were early versions of what we now call data centers. And so I said, what percentage of the resources in your data centers do you use? And he said, You're asking me the wrong question. I said, really? What question should I ask? And he says, ask me how many machines I have in my data center. And I said, okay, how many machines do you have in your data center? And he said, I have no idea. And so that was the state of the art at the time. And he said, by the way, if you want to tackle this problem, I'm totally down to work on utilization and so on, but we're working with very basic problems here. We actually have no idea what's happening in our data centers. And then he said, we have this RFP out and if you're willing, we'd love to apply your software, but we're going to apply it towards solving our basic problems first. We ended up winning this RFP, which was, you know, its own interesting journey And when we showed up to transition them, the tools they were transitioning from at that time, if you called up Quest and said, all right, I need 10 machines and I need a terabyte of storage, I need this much network capacity, so on. Some guy would walk out into a data center with a bunch of notes, plug machines into racks, put in network cables, write down the MAC addresses and IP addresses that got assigned, and then email you what, how to connect to your machines. That's what the process was like. So we're onboarding them and basically we built software for data center automation, what that space ended up getting called. And the thing we migrated them from was spreadsheets and Post-it notes. That's where all the data was. You wanted to know where the machines were, you had to go and read all these, all these Post-it notes, very carefully labeled, well done, but Post-it notes all over these data centers. And that was my first time with actually the observation I ended up forming Coda, you know, years later was that the line between documents and applications was actually a lot thinner than you might think. And led to a bunch of other choices in my career from there. But yeah, that's what Zentrada did.

That's incredible to hear those early days stories of how people were thinking about data storage and their servers and how all that came together to what we know as today is empowering startups everywhere. As you pointed out, it was a touch early, although you had big names backing that early startup, uh, Kleiner Perkins to name one, which at the time was really at the top of their game, having invested in Google well prior to their IPO. What was it like fundraising at that young age right out of college, as well as amidst this crazy bubble of tech investing?

The funding story for Centrada was a lot of fun, and it's entirely different than what happened with Coda. I mean, Coda, we ended up raising our Series A was $25 million. It was done over a weekend. The Series A for Centrada was about $500,000. It took 9 months to do all sorts of tough dynamics as we navigated, as, as you mentioned, as college students figuring this out. Basically, the start of Centrada was a graduate thesis that myself and a guy named David and Radecek were doing at the MIT LCS Laboratory for Computer Science. We sort of turned it into a business plan. That business plan we had submitted to a competition at MIT Entrepreneurship Center. It was called the $50K competition. Now it's called the $100K competition, so it's inflated a bit. Got a lot of, you know, got some press and so on. You know, through that process, we'd gotten some interest from some angels, and one angel was really helping us out and had committed a bunch of money, but actually hadn't wired it. One day we get this note from Vinod Khosla. And I get this email message. And Vinod, by the way, was at Kleiner Perkins at the time. He was the senior partner there. Obviously now started Khosla Ventures. Vinod emails me and says, "I received your business plan from Asha," which is its own story. "And I'm really interested in funding the company. Will you fly out to California and meet me?" As dumb as this sounds, I had no idea who Vinod Khosla was. And so I call up this angel of ours and say, "Hey, I just got this email." I don't know if you guys have seen Vinod's emails, but he misspells every word. And so it's not actually that obvious that this is a real email. So you're figuring that out. Is this real? What's with all the misspellings? And so this angel investor says, I want you to leave your dorm room, walk down to the student center, go to the bookstore, look at the magazine rack, see the guy whose face is on all the magazines. That's Vinod Khosla, because he was basically at the top of every list at that time. And so I go, I do that. I like read a little bit about Vinod. Remember, there's no Wikipedia, there's no LinkedIn, there's no, like none of those things existed. So there's no easy way for us to know. And so I come walking back to my dorm, my quote CFO who happened to be my floor mate, I walk over to him and I'm excited. I was like, oh, it's, you know, Vinod just wrote us and here's what he said. And he says, well, that's interesting. I had news for you too. You know that angel who's been like saying he's going to invest but hasn't wired his money? We just got all his money wired into our account. What happened? It's like, it's very interesting how this little catalyst, sort of shifted how that fundraise happened. But anyway, that was how we got to one of Vinod's requirements as we started talking about the company was that we had to move out west. It was one of the things he insisted on. And so in a period of 2 weeks, we went from, you know, not sure whether this thing was ever going to start and I was just going to finish my graduate work to we're funded and moving and, you know, took everybody's stuff and put it in a U-Haul and 2 of the people on the team drove up across the country and there we were, a funded company.

That is incredible. And one of those kind of fairy tale stories in venture capital where you come out of undergraduate and you start your career out west. After Centrada, you then became a director of product management and then also found yourself at Google and 6 months later YouTube. Can you tell us a little bit more about those early career moves in product after Centrada?

So Centrada became basically a big consulting company. One of the things, our first client actually, Quest Communications, when I was telling you about, was a $12 million client. And one thing people don't tell you is if you're a 20-person startup up and your first client pays you $12 million, they didn't buy your product, they bought your company. And basically whatever they wanted us to do, we did. And I had an apartment in Denver. I'd be down there. I sat in staff meetings with the Quest team. Actually, when 9/11 happened, you know, a year after that, I was stuck in Denver for months. The nature of what the company was becoming. So I got a little bored, decided I wanted to do something different, went to Vinod and said, I'd like to talk about moving on. And he tried to convince me otherwise, convinced me to stay on the board. I ended up staying on the board for a long time, but then he urged me to go Join another Kleiner company. And I said, okay, which one? And he said, well, we've got this really interesting one. It's these two Stanford guys are starting a search engine called Google. You may have heard of it. Why don't you go talk to Larry and Sergey? And so I went down and talked to Larry and Sergey. You know, they ended up making me an offer to be the first product manager at Google, which I only tell that part of the story because I ended up turning them down, which my wife likes to call my billion-dollar mistake. And I instead joined Microsoft. And the reason I joined Microsoft is I had this old boss who was starting a new team, and I had interned at Microsoft in college. Microsoft was kind of like what Google is today. That's what Microsoft was like when I was in college. It was like where everybody interned and everybody like, it was kind of a de facto place to work. This old boss of mine was starting a team whose goal was to turn Office into a front end for business applications. And I just thought that idea was genius. You know, I'd just gotten through my Centrada experience and watching us migrate people from, you know, spreadsheets and Post-it notes into, into packaged applications. And this person, Mike, actually interestingly now works as an engineer at Coda. Mike was convincing me this line's artificial and people use Office and Docs to run all these processes. Maybe you should come work on that. And so that's how I got pulled up to Microsoft. That's a great journey. I ended up spending 6 years there. I worked on Office, then on Windows, then on SQL Server, and then got my itch to do the next thing. This was mostly driven from personal circumstances. When I moved up to Seattle, I convinced my then fiancée, my cloud sweetheart, I convinced her to move to Seattle 2. She's a physician, so she did her residency at the Children's Hospital in Seattle. It's one of the best places to study as a pediatrician. So that actually ended up working pretty well. She was done with her training. We were talking about where we wanted to settle down, and we decided we wanted to settle down in the Bay Area. So I told the Microsoft folks that I'd be wanting to move down to the Bay Area. And at the time, Microsoft didn't really have anything in the Bay Area, so there's no easy way to do that as part of the company. And I was quite certain I was going to start a company at that point. Google had, you know, since I had said no to them, they had kept asking every year for me to come look at a job at Google. And it's a much longer story that I'm happy to get into if you guys like. But the guy running product at the time, Jonathan Rosenberg, was pretty insistent. I spent a day at Google talking to a number of different people, ended up in that process. You know, at the end of the day, I was sitting in Jonathan's office and I'd met all the different Google executives and he said, what do you think? And I said, well, like, really exciting company, but seems like a big company to me. I don't really want to move from one big company to another big company. And then he made the statement that ended up kind of sticking with me. He said, "Oh, you're misunderstanding. You know, you talk to other people building Chrome and Android and all these new things, but really Google at its heart is an ads company and all the ads money is spent on these stupid television ads and nobody even watches these stupid television ads." And actually Jonathan's a lot more crass than me, so he used a bunch of vulgarity that I'm not using. I knew nothing about advertising, so that statement was actually quite surprising to me. I didn't really expect that. And I ended up getting on a plane, writing a paper that was called— this was also 2 weeks after the Super Bowl in 2008. I had observed that, you know, we had our friends over for the Super Bowl, and I observed that during the Super Bowl, not only did everybody watch the game, anytime an ad came on, people would ask me to rewind it and watch the ads again. And so I wrote this paper that said, how come television doesn't feel like the Super Bowl every day? Like, that one day a year, the ads are good, everybody's quite willing to watch them. What's different? What— and what's different about the incentive model? So I ended back in Seattle after this plane ride, and I write Jonathan, and I said, "Hey, I don't know anything about advertising. I'm sure you're already working on this, but I had this set of ideas. Maybe you'd find them interesting. I'm going to go start my company, but I'd really love if you fix television. Maybe you can do something about this." And he wrote me back right away, and pretty early morning person, and said, "Actually, we don't have anybody working on that." I since learned why, but no, we don't have anybody working on that. And if you'd like to, I have a team of 10 engineers that's not exactly sure what they're going to work on. Why don't you come take on that team and you can do a startup inside Google? So that's That's how I ended up going from Microsoft to Google. Yeah, we can talk more about the Coda story as well, but that journey, I ended up spending 6 years at Google. Most of that time I actually was working on the YouTube team. I ended up, this project basically got merged into the YouTube team. You know, YouTube at the time was kind of broadly considered to be Google's first mistake. You know, Google had paid $1.6 billion for this company, but it was burning lots and lots of money every year and had big billion-dollar lawsuits and grainy videos and dogs and cats doing kind of odd things, and nobody really understood it. And so it was a little bit of a non-traditional move, but YouTube, you know, that, that team of, you know, pirates that ended up joining YouTube at the time, I think really came together and built something really fun and interesting. And so I spent 6 years doing that. In 2014, I got another itch, uh, had an idea, a spark, and ended up starting Coda.

Thank you so much for walking us through that journey. And you were at YouTube in 2009, where it was really its period of hypergrowth. You mentioned once that because of this experience, you wanted to take a bit of a different approach with starting Coda, which at the time was under the name Krypton. And you guys were in stealth for 3 years. Do I have that correct?

Yeah, almost 4.

What was the rationale for that?

You know, I was at Google, you know, having a lot of fun, but the— so again, sort of getting my itch to do something different. But starting a company was kind of the last thing on my mind. I was approached by Alex, who ended up being my co-founder at Coda, And Alex and I have known each other since college. He went to MIT with me, and actually we've worked on every other job together. He was part of the founding team at Zentrada. You know, he worked on some of the different products at Microsoft. He worked at YouTube for a bit. We're very close, but he was starting a company that thankfully wasn't going very well. He had come and asked for my help in figuring out where to direct it, what they should do next. And so we ended up doing a bunch of brainstorming sessions about the direction of, of Alex's startup. And at one point, one of us wrote the sentence on the board, you know, what if anyone could make a doc as powerful as an app? What's become our sort of mantra for Coda. Anyone who's used Coda probably recognizes that in the product. It's as simple as a doc, but as powerful as an app. And so we started talking about it and still was not obvious to me that I should start a company. But gradually this idea grew and grew on me and I just found myself not being able to think about anything else. I decided to jump in and start with Alex. Took some pushing from some investors, from some friends, so on. And that's kind of how the round came together. And so we find ourselves in the situation where actually one of the things we had said is we had a list of people we would ask to join the company and we would only start if they all said yes. It was like one of our tests for, you know, is this idea actually any good? And thankfully they all said yes. Actually, all of them still work at the company now. So the 6 of us start the company and we do our first meeting where we did some like kind of fun exercises. Like each of them, I or Alex had worked with in one way or the other, but not this group had never worked together. As a group before. And so we did some, you know, fun exercise, everybody telling a little bit about their history and so on. And then we had a series of questions about cultural statements we wanted to make and how are we going to run the company. And so we started making different ones. And, you know, we may talk about later is we decided that we run the team as a distributed team, which was not at the time not an obvious thing to do. It's become more in vogue now. But one of the hardest questions we asked was, should we run the company in stealth or in the public eye? Lots of debate about it, and we decided to run it in stealth. There are a few different reasons. I think the big reason was, you know, my view was that it would allow us to focus on the product instead of on being distracted by what the rest of the world thought. You know, it was a relatively prominent group of people, prominent investors, so on. And if we had started talking about the company then, that's probably all that people would have talked about because there was no product to talk about yet. And my view was we should talk about the company publicly when the product can be at the center instead of, you know, the company or the people behind the company being at the center. And I think it'll be a lead to a better community and so on, which is very important for the product we were building. The other reason it was important was we knew it would take a while, and the thing we were building was not easy to build. We had sort of mapped out all the different parts of what we needed to build and knew that it would take a few years. I think we were, you know, maybe off by 6 months or so, but we were pretty close to what we thought it would take to build it. And that's a long time to try to maintain expectations. And so debate about doing it in stealth. And then the other side, we had a list of why do you do— why do you announce companies? And there's sort of 3 reasons, my view of why you announce companies. You do it because you're trying to attract employees, because you're trying to attract customers, or you're trying to attract investors. And we found ourselves in the situation where we didn't actually need any of those. You know, the group of people we had was mostly sufficient. We kept hiring, but pretty slowly, especially in those early days. We had plenty of money. The code or product is one where finding customers is not hard at all because everybody's a potential customer. You could walk anywhere and find a new customer. So we decided we'd start in stealth. Just to be clear about it, it doesn't mean that just because we were in stealth doesn't mean that we were without customer feedback. In fact, we onboarded our first customer 4 months later. You know, through the years, we always had a base of customers that were using the, using the product and giving feedback. I think building products in a vacuum is a very bad idea. I think, but I don't think building products in the public eye or in a vacuum, actually, you can do one without the other, actually in both directions. And we learned a lot. The first alpha customer that we onboarded, well, actually first we did ourselves. So we built up what was then, as you mentioned, original name for Coda was Krypton. So we built up the product to a certain level and then transitioned a bunch of our own workflows and systems onto it, and we're pretty proud of it and seemed pretty capable. And I called up a friend of mine who was running a startup that had about the same number of people. He had 6 people in this company. I said, hey, this is working for us, will you use it too? And, you know, thankfully agreed and said, uh, yeah, be happy to use it. And so we had this dashboard set up, and we had one customer, and they had 6 users. So this dashboard only, you know, the y-axis only went to 0 to 6. Like, that's, that's all the users we could have. And so we'd watch it every day and, and see how usage was going. And for a few weeks, it went pretty well. And then one day this went to zero. The next day we waited a day. The next day it stayed at zero. And so I call up my friend's name, Noam, and I said, Noam, what happened? Like, did you guys go on vacation? Are you doing an offsite? Like, why is it at zero? And he says, well, you know, I wasn't really sure how to tell you this, so I've been avoiding calling you, but we had a team meeting and the team told me that if I make them keep using Krypton, they're all going to quit. I have good news too. And I was like, well, it's hard to follow that up with good news, but okay, let's hear it. And he says, well, they're all totally aligned on the vision of what you're trying to do. But they— each of them has this list of gripes of the things that they think the product should do. And if you get through this list, we'll be happy to try again. And he handed me this list of 30 things to go, to go fix. It's kind of devastating for the team. You know, we lost 100% of our user base in one day and, you know, kind of back to the drawing board on a bunch of things. That period was really important. I think, like, looking backwards, I think if we had to do that in the public eye, we probably wouldn't have survived it. It takes a while to get to the right point. So I think for our product, I think we made the right choice. There's a lot of products for which that's not practical. Are not advisable. I always, I get asked this question a lot by other startups, and in most cases I would tell you, you know, ship often, ship early, be as public as you can, make as much noise as you can. But just our unique situation of where the company is coming from and the type of product we were trying to build lent itself to this mode of development.

It sounds like you've been really, I would say, strategic about these different milestones and experiences as you're building your company from day one, mentioning how you got into a room and talked about how you want to build culture. Do you want to build in stealth mode or not? And we've touched on podcast the idea that scaling quickly is often at odds with creating a great culture. I think Coda, since going public, has— or not public, sorry, but has been out of stealth one day— really does appear to defy that. You have these fun company traditions that you've spoken about publicly, such as your Dories, and now you have almost 100 employees. How have you been able to adapt the culture as you've scaled?

It's built into our culture to— and it's sort of built into the company as well. I mean, see, what our product does, you know, it allows anyone to make as powerful as an app. But what the product really does is it allows people to turn their ideas and rituals into actionable practices. The one you mentioned, Dory, is a particularly interesting one. The story behind that one was it was originally created as we started adapting to being a distributed team. For people that haven't heard the term before, Dory is a name— actually, the name was given at Google. It's a, it's a question and answer tool, and it's named after the fish from Finding Nemo, who asks all the questions. And the basic idea is very simple. You add questions to this table, you can upvote them, you know, upvote them or downvote them, and then you go through them in order. And at Google, this was created for a meeting called TGIF, which is the kind of famous meeting Larry and Sergey would run every Friday that they would open up to the whole company and answer anybody's questions. And because there were tens of thousands of employees, you needed a system like this. For us, what that really represented was a little bit different. It was a way to indoctrinate a value that we wanted, right? And so as we're scaling and we're becoming this distributed team, we need some way for people to be able to interject and say, I have a question. And so, you know, this was a very natural thing to do. It's pretty easy to build in Coda. If you hit /upvote, you'll find a whole bunch of— actually, not only one type of Dory, but there's actually a whole bunch of voting templates in Coda. But the reason we were doing it was, you know, we have one of our values is that great ideas can come from anywhere. The thing it did was it, it sort of democratized our group and allowed for where, you know, I'm sure everybody's been in a meeting where, where you sit down and, you know, the loudest person eats up all the oxygen, or the highest-ranking person, or whatever it might be, and then you miss everybody's ideas. And so what does Dory do? It allows everybody to contribute. It also happens to make our meetings a lot more effective and organize our discussion, makes it so that when you leave the meeting you say, we didn't talk about everything, but we talked about everything with at least 3 upvotes. As an interesting side note, I find that when people write down their questions, people's questions get better, which is also interesting. But all of those things where if you pull the tool back out of it and just think about those behaviors and say, do you want a company that is a place where anybody's ideas can be contributed, anybody's voice can count? Do you want a place where the things you do are ordered and purposeful or where they're haphazard? If you start writing all those things down, you'll end up building tools that match them. And so I think that's a big part of our culture. I think there's a book that I highly recommend to people. Actually, if I had 5 books to recommend, this book would take 2 slots on the list. It's a book called Switch. It's written by the Heath brothers, Chip and Dan Heath, and they also wrote Made to Stick, Moments, and Decisive. Also really good books, but Switch is the one I would recommend at the top. And they use this analogy. The subtitle of the book is How to Cause Change When Change is Hard. The analogy in the book is a rider on an elephant on a path, and when you're causing change, you're either directing the rider, you're motivating the elephant, or you're shaping the Directing the Rider is you tell people what to do. Motivating the Elephant is you kind of give them energy, but you have no idea which way they're going to go. And Shaping the Path is you just set up guardrails so they can do nothing but this one thing. I think that that type of thinking and both the Code of Product and the Code of Culture go right together. You know, when you sit down and you try to solve problems or opportunities for how your team is working and you start thinking about, okay, where should we be directing people? Where should we be motivating people? Where should we be shaping the path, you'll naturally end up building things like, like Dory's that do a little element of each of those actually. And so that's been a big piece of how we've built and kept our culture and traditions.

Yeah, it's so interesting because from day one you've made this a priority and it's been implicit both in the product and the structure with the distributed workforce team. And you have Coda, which enables distributed work. And this of course has been a year where distributed work is has just been the only kind of work, quite frankly. How do you think Coda and other companies are going to be able to adapt when people are returning to the office, having learned to leverage these other tools?

In 2011, '12, Larry took over at Google, new CEO, and he made a bunch of changes when he took over. He reorganized us into business units, made a bunch of cultural changes, but one of the things he really wanted to do that he was unable to do was he tried to make the company less distributed. Went and asked each of us, those 8 divisions at Google, and he asked each of us to consolidate down our locations to 3 locations, of which at least one of them was California. One of them was in the Bay Area. And as context, YouTube, I had 8 offices all over the world. The Maps team had like 22. The Chrome team had like 25. I mean, we were all over the place. Much of that was ironically driven by when Larry was first CEO, he had a rule that said, if you can find 3 engineers in any location, you can open an office there. There. And so we had sort of sprouted these things all over the place. So we're going through this discussion, but he sort of changed his mind and said, like, I think we've gone too far. We should consolidate back down and have things together. This process got all the executives together, had lots of discussions about it. We ended up closing one office, the Atlanta office, and there was such an outcry that we kind of stopped and none of the rest of it happened. But in that process, we all got kind of interrogated on on how do we really feel about distributed teams? Like, it's kind of been— it was kind of just handed to us, right? I was at Microsoft. Microsoft was very centralized. If you didn't live in Redmond, you didn't exist. And then at Google, it was kind of the opposite, like, what's good, what's not good? And it's really interesting that for a period of a few months, every one of our one-on-ones with Larry, you know, sort of centered on this question. I remember he asked me at one point— I think he asked everybody— and he said, you know, if you could just snap your fingers and you could take— at the time YouTube was about 2,000 people— if you could take 2,000 people and just have them all be in San Bruno, which is where the YouTube headquarters was, you could just have them all be in San Bruno California, you know, wouldn't you just do that? And I had to think really hard about my answer and I ended up saying no. And I said, you know, there's a couple reasons. You know, there's, there's a very practical reasons. You know, there's no way our infrastructure can support it. Like we, you know, our buildings were bursting at the seams, so on. You know, there's the, the fact that not everybody wants to live in Northern California. There's a lot of people in the world that are great and don't want to live here. But actually the one that was most important to me was I felt like when we leaned into being distributed, we ended up being a better company in general, a better team in general. And I had all these examples of that, of where, you know, we developed these processes that were because we were distributed, but actually we did them just the same even when we were all, all in one place. My view is the best companies discover the behaviors that, that are caused by being distributed are actually really good behaviors and lean into them and they allow them to shape the company. I mean, for us, the thing we just talked about, Dory, is a great, really great example of that, where a thing that was built for how do I ask a question when I'm on a video conference ends up being We end up using a DORY even when we're, you know, all in one room, it's only 3 of us. We'll still use a DORY. It's a much more effective way to understand what everybody wants to talk about and where we should head with our agenda. And I've just seen as we've gone through this period where, you know, obviously that everybody is— the type of distributed we're all in right now is not normal distributed. There's things to be learned, but there's also things that are— not having to see your coworkers is one thing, you know, not being allowed to see your coworkers is a very different thing. But we're all learning these behaviors. I think a lot of accelerated a decade of learning about distributed— how distributed teams operate. My hope is that companies are realizing these are things that actually work well distributed, and probably here's a list of things that don't, and everybody's anxious to go turn back to those. You know, my view of it is actually we're going to see a little bit of a reversal of what people thought being centralized was for. I mean, I think people thought it was you need to be centralized for the important meetings. Like, we all need to get together for the board meeting and the important staff meeting and everything else you can dial in for, but you gotta be here for the important one. Actually turns out those are the easiest to run in a distributed way. Those are all the things where easy to form structure, it's easy to form rhythms, and actually the timeliness of them is much more important. And so the fact that you can kind of instantly call one of those meetings no matter where everybody is, is actually really, really important. More important than having everybody in the same room. And on the flip side, the things that we thought were unimportant, The offsite, the get-to-know-you events, those are the things that actually are really hard to replicate in a distributed world. And so I suspect we're going to find kind of the opposite. Like we'll say, you know, stay home for the important stuff and come into work for the less important stuff, which I think will be an interesting change for a lot of companies. I think it's probably a positive as we all adjust to this.

I think it is interesting to hear and like just kind of observe how every company has handled it. I know Claudia has been struggling with this at Uber, which because it's so large and you just haven't been able to connect, especially with your fellow APMs at all. You're a thought leader for product management philosophies, distributed workforces, the future of bundling. And we've heard that you've coined this one term, Eiken Question. Do I have that right?

Yeah.

Okay. Claudia had to teach me how to say it. Our listeners who are less familiar with your philosophy here, it's really a way to frame big problems. Where did that come from and how should people use it to help answer tough questions?

Yeah. Eiken Question. So it's a made-up word. So that's, it's totally reasonable to not know how to pronounce it. It's a riff on idea from, from math, from linear algebra. In multidimensional spaces, eigenvalues and eigenvectors represent the most descriptive vector of a multidimensional space. It gets used a lot in machine learning, and sometimes it's called principal component analysis as another term for it. All of that background really doesn't matter. The math is not that important. We're just kind of stealing the term. You know, what it really amounts to is an eigenquestion is the one that, if you have a list of 10 questions, the eigenquestion is the one that when answered, answers answers not only itself, but all the other 9 questions as well. So that's the basic idea. I'll give an example that might help with understanding it. My favorite example of this happened very early on in my, in my YouTube days, sort of 2009-ish. There was this big question around what we call the link out question. The question was pretty simple. The people would come to YouTube, they would search for things, and sometimes they'd get good results and sometimes they wouldn't. And one of the queries that was trending at the time was Modern Family. Modern Family was a really popular TV show at the time, but we didn't have Modern Family on YouTube. We had a bunch of grainy clips. They weren't particularly good. ABC.com had all of the episodes, all the clips, they had really good quality stuff. And so there was this question, when people search for Modern Family on YouTube, should we link out to ABC.com and just send people to what they probably want to find? And very heavily debated question. Uh, you know, the product engineering team was pretty convicted, like, we should clearly link out. This is— we had just been bought by Google. YouTube was the world's second biggest search engine. We had lots of very similar philosophies. Google's philosophy was give people the right answer no matter where it is. And so we should just link out to wherever it should be. It's like kind of the right thing to do was the main, main argument. The business development team and the content team and the marketing teams, they all thought this was really dumb, that if you link out to these other properties, nobody's ever going to put their content on, on YouTube. This debate was like raging months and months and months, you know, should we link out, should we not link out? And it basically had formed factions factions that you might describe as the good faction and the evil faction. And it was a really hard choice to make. So we had this offsite where a few of us got together to talk through the big choices facing the business. And this was one of the topics. And I was assigned to frame this topic. And we said, "Hey, we got to make a call. One way or the other, we just got to decide. We got to tell the team. We got to move on." So we got in this conference room at the Half Moon Bay and had this discussion about it. I went through a framing that was a little bit different than how we had framed it before. And so I'd been thinking about it while I was prepping the night night before that, and I was thinking a lot about a very different question that was being asked by the Google Shopping team. And at the same time as we were having our YouTube debates, the Google Shopping team was having its own identity crisis. So Google Shopping came out, it was originally called Frugal, people might remember that. It was up against Amazon and it was getting its butt kicked by Amazon. Nobody really understood why, because everybody looked at it and said, why would a user ever use Amazon when you could use Google Shopping? Because when you search on Google Shopping, we had indexed all of Amazon. So you come there, you get everything you get on Amazon, and and the rest of the internet, why would you ever go to Amazon? And what we were watching happen was that's not how users thought. Users said, they would say things like, "Well, I go to Amazon because the experience is a lot clearer. It's always the same. And I understand where the reviews are. I understand how the shipping works. I understand how returns work. I know how the pricing works." Sort of no surprises anywhere. But the way we had started talking about this is people were going to Amazon because they were choosing a more consistent experience over a more comprehensive experience. And so when we started the discussion at this offsite for YouTube, I started with this question, which do we value more, consistency over comprehensiveness? And now all of a sudden, that's a totally reasonable debate. Do you think the shopping market seems to be evolving towards consistency over comprehensiveness? That's not obvious. Reasonable people could have looked at that and said, I think comprehensive is going to win, but that's not what was winning, at least not at the time. So which one is the video market going to be? Is it going to be consistent over comprehensive or the other way Long, long debate, but all of a sudden this was no longer good versus evil. You could make really good arguments on both sides, and we decided we were going to focus on consistency over comprehensiveness. So we made our decision, we're not going to link out. We also, as we're making a decision, decided like 10 other decisions. We had all these, all these people at the time, uh, you could embed your video player on, on YouTube, and we decided, well, that's an inconsistent experience, so we're going to stop doing that. You couldn't do that anymore. Uh, probably the most famous decision was was when the iPhone first came out, there was no App Store. So the Apple team built all the apps, including the first YouTube app. And this was now, you know, 6 years later, and they still were building the YouTube app on, on the iPhone. We went down, you know, I drove down to Cupertino, and I went and told the Apple executive team, uh, hey, we need to take back, uh, building iOS app for YouTube. And because, you know, they've been building it, they're doing an okay job, but they couldn't keep up with us. And what had happened was, you know, about 50% of the YouTube catalog didn't play back on the iPhone, which seemed crazy. The Apple exec team all looked at me like I was nuts. They're like, "You're going to give up default distribution on the biggest operating system on the planet because of what? Because you want control over these different things?" And I said, "Yeah. I mean, so one of our values is consistency over comprehensiveness." I think a good example of an eigenquestion where the actual question we had to answer wasn't, do we link out or not? It was consistent versus comprehensive. And once we made that decision, 9 other things fell into place. And so the lesson out of this is we'll often ask ourselves— there's actually a distinct part of the Coda process when we're looking at problems where we call it wallow, frame, propose, close. And there's this distinct phase where the wallow is where you sort of understand all the different considerations and so on. Propose is obviously you have a set of options you want to decide. It's this distinct phase where, where we frame, and the goal of that phase is try to identify the eigenquestion, which is the question where if we answer, we will end up answering all the other questions. And then let's focus all our energy on figuring out the answer to that question. It's been a very useful tool for us.

2020 has been an unusual year, to say the least. With work from home, I, as I mentioned, have been relying on Coda to communicate with my team more than ever. Um, we know that you are a husband and a father to two girls. Tell us more about navigating work, family, and the crazy year this has been. And what are you looking forward to?

Yeah, so for context, I have two wonderful daughters. They're 12 and 14, 6th grade and 9th grade. They're great. I think I could not have asked for sweeter and more accomplished kids. You know, I think pandemic has been tough on everybody in lots of different ways. I think there are some silver linings. I think one of the ones for us is, you know, we get a lot more family time. And in particular, like one of the things I don't know that I would have expected is this little unexpected treasure is our ability to eat lunch together as a family. I would often count things based on how many nights a week we had dinner together. And nowadays it's, you know, 7 for 7 most weeks, I think is amazing. But we also end up having lunch together. 3 or 4 times a week, which I think is, which is surprising how different it feels to interact with each other in the middle of our days. And like the level of energy is different and everybody's full of excitement and any of the stories are all fresh and we're about to go back to do something. And so I think that's been really good. And, you know, I'm a little sad that the younger one's about to go back to school and the older one will probably go back next semester. You know, I think that'll be a little bit sad. In the meantime, we do a lot of stuff together as a group. One of the things they do that I get to be a big part of is they're both into LEGO robotics.

Robotics.

They participate in this thing called FIRST LEGO League. This is their 5th season doing it. Uh, last 4 seasons they've made it to the World Championships twice, although last year it was canceled for obvious reasons. And so we're like deep in the middle of competitive robotics season now. We're 4 weeks away from the qualifiers. That's a lot of fun. And I think it's just an opportunity to— I'm the coach for the team, and it's just an opportunity to get to, you know, learn and work alongside them, which I think is really important. It's also a chance for me to remember what it's like to be kid and, you know, what, what those— what it feels like at that phase. That's been a lot of fun as well. I'm really looking forward to, to seeing how the season evolves.

That's so special that you get to share kind of these loves of yours in your work life and in your career, what you've learned, and get to share that with your daughters.

Who is a woman in your life that has had a profound impact on your career?

Professional context, I think if I didn't talk about my mom or my wife, then they would both— I would not be doing the right service. And I think both have had profound impacts on me in all, all sorts of different ways. Since you asked to move past that. In a professional context, the person that most comes to mind is Susan Wojcicki. Susan was interestingly my first boss at Google, and she was the one who sort of brought me into the company and helped me navigate it and learn how the company operated, how Larry and Sergey worked, and, and how to chart a course of getting things done there. And then when Eric asked— Eric Schmidt was running the company at the time— he asked for someone to go help out the YouTube team Susan's the one that nominated me to go help and then convinced me to go do it. Because I, you know, my initial reaction was, that's a big job. Well, A, it's a big job and I don't know anything about advertising, that was obviously going to be necessary. And B, at the time it wasn't really that obvious that it was going to go anywhere. And Susan helped convince me to do it. And then after that, we ended up sort of working in partnership for a number of years because we depended heavily on— she was running the ads team and running the YouTube team and kind of built up that that industry together. And then when I left, as a sort of interesting twist of fate, she ended up coming over to lead YouTube. And so I think in multiple different ways, ended up having a lot of impact on me as a coach, as a leader, as a partner, and I think a great executive. Thanks for the great questions. Lots of fun areas to explore.

Thank you for listening to this episode of The Room. If you enjoyed our conversation, please like and subscribe. Stay tuned for next week's inspiring guest, airing Tuesdays at 7 AM Pacific. See you soon.

All opinions expressed by Claudia and Madison and podcast guests are solely their own opinions and do not reflect the opinion of The Five AC. This podcast is for informational purposes only and should not be relied upon as a basis for investment decisions.

[MUSIC] [MUSIC]