Productivity software startup Coda was founded to empower anyone to make a document as powerful as an app, no engineering required. More than 25,000 teams around the world now use Coda to build, track and share a wide range of projects and workflow systems, and the company just closed an $80 million Series C round. Now that many businesses have no choice but to be distributed, Coda has seen accelerating adoption as a central collaboration hub within companies.
The concept of Coda grew from ideas formed by CEO and co-founder Shishir Mehrotra over the course of his career (which includes leadership roles at YouTube and Microsoft), with a mission of enabling what he calls the Maker Generation: allowing a much wider pool of people to create and build a broader array of products regardless of their skill set. In his words, “Coda will do to software what online video (at YouTube) did to cable, just as cable did to broadcast.”
In the latest Greymatter podcast, Greylock general partner Sarah Guo and Shishir discuss how Coda has operated partially distributed and software-first since its inception, which Mehrotra says inspired the company to design structured meeting protocols and build (Coda-based) tools to ensure productivity and inclusivity no matter where team members are. The harder part, he says, is recreating the traditionally unstructured – but critically important – time people spend together as a company in informal and historically in-person environments. They talk about the background to Shishir’s Guide to Distributed Teams, and how his philosophy on distributed team leadership is still evolving.
They also discuss why Shishir believes “the world runs on docs, not apps,” why the core metaphors for productivity systems are stagnant, solving the “tragedy of the commons in enterprise software,” the most commonly pressed three buttons in SaaS, why you want structured participation in your board meetings, lessons learned from the in-office (and not) cultures of Microsoft and Google, and his predictions for the future of productivity. This episode is part of Greylock’s #WorkFromAnywhere podcast series hosted by Sarah and David Thacker.
Listen to the episode here.
Podcast Transcript
Sarah Guo: Shishir, thanks for doing this.
Shishir Mehrotra: Great to be here.
Sarah: Let’s start by rolling back a bit. Can you tell us about yourself and the founding story of how you and Alex came up with the idea for Coda?
Shishir: I started Coda in 2014. Before that, I spent about six years at Google, where I was responsible for the YouTube products. Before that, I spent about six years at Microsoft and worked on Office Windows and SQL server. Before that, I started a company called Centrata.
I think if you ask people close to the company, they’ll say Coda is an idea I’ve been working on in some form or the other for almost two decades. It was informed by a lot of early projects at Centrata and Microsoft, as well as throughout my experience at Google. But the actual moment of conviction happened in 2014, when I’d been at YouTube for a while. I was almost ready to do my next thing, but starting a company was actually not very high on my list. What happened is this: My friend Alex (DeNeui, who ended up being my co-founder) and I went to college together and then went on to work on multiple different products and companies together, and by then he was off starting another company. Thankfully, it wasn’t going that well. So he’s asked me to brainstorm ideas with him for where he could take his startup, and that ended up being the foundation for Coda. At one point in the middle of one of those brainstorms, one of us wrote this line up on the whiteboard that said, “What if anyone could make a doc as powerful as an app?”
That line basically became a bit of a rallying cry for us. For me personally, it just stuck in my head in a way that I just couldn’t let it go. I often tell people that when you are starting a company, you have to ask yourself two questions: One, is it an idea that you can’t imagine not working on? And two, do you have a person you can’t imagine not working with? I used to tell people that when I was at YouTube, and I was usually telling them that as a way to discourage them [from leaving]. People usually didn’t meet one of the two criteria, so it didn’t happen. So it was a good way to keep people at Google.
But all of a sudden I found myself in the state where both things were true: Alex and I are an obvious pair with very complimentary skills. I consider him to be one of the best engineers I know. And I just couldn’t stop thinking about this idea. II would wake up drawing. Everybody I could talk with about it, I wanted to talk about it with. I got sucked in. One thing I tell people is that founding a company is as much of a curse as it is a blessing, because at some point you just wake up and say, “I have to do this.”
Sarah: I’ve now heard you say that phrase, “Imagine a doc as powerful as an app” maybe a hundred times over the last year. Can you unwrap that a little bit in terms of what you mean?
Shishir: Haha, yeah, that’s a good question. I like to say that good and great businesses tend to start with very simple theses. For example, with YouTube, it was, “Online video will do to cable what cable did to broadcast: We’ll go from three channels to 300 channels to 3 million channels.” And when we first used to talk about that, it was not really obvious to people that that would come true. But it did.
So, similarly, our statement for Coda (that anyone could make a doc as powerful as an app) is today (for some set of people) totally obvious. But for others, it’s a big head-scratcher. Like you said, “What does that mean?” And it really comes out of a couple observations of the world.
The first is that I think the world runs on docs, not apps, and is the easiest way to test. Go look at how any team operates – how any business operates – and ask them what tools they’re using. They’ll rattle off all these different tools: “We use this for inventory, and this for task management, and this for CRM, etc.” And then you sit and watch them all day long and the things they actually spend more of their time in are documents, spreadsheets, presentations, and some set of communication tools. And so in my mind, the line between these two things has been fairly blurry. For example, I got to Google right when Google Docs was coming out. So we basically ran YouTube on Google Docs and Google Sheets and for us that line between docs and apps was very artificial. But we used to do a few other little things when we wanted to plan things differently than the rest of Google did. We did ok, but our process was different so we couldn’t use all of their tools and we had to do our own. For instance, we did compensation differently (I have a model for what I call Level Independent Compensation, and that was very helpful for us). We did it all in big spreadsheets. My favorite example is in the early days of YouTube, where if you hit “Flag” on a YouTube video, it would create a row in a spreadsheet on an Ops person’s desk. So my view was there was this line where docs and productivity tools were on one side, and applications were on the other. I think that’s a false dichotomy.
My second observation is that all these tools we use – documents, spreadsheets, presentations, etc – are all kind of cemented in metaphors from the 1970s. We’re basically looking at versions of WordStar Harvard graphics and VisiCalc that have just been sort of copied and pasted through from green screens to DOS, to Windows, to Mac OS, to Chrome and the web and to mobile phones. But the core metaphors are all exactly the same. It’s like we’ve stuck these two things together and said ‘Okay, so people use docs in these entirely different ways in which they were created, but those tools haven’t changed in 40 or 50 years.’ Everything else in software from that time period is completely different –operating systems are unrecognizable from what they were like in the seventies, databases are totally different, things like search engines and social networks didn’t even exist. So when you look at that you think, ‘Why is it that the modalities have totally changed but the platforms haven’t?’ And so that started that framing of the idea of, if we built a new doc where we intentionally erase that line between the tools, anybody can make a doc as powerful as an app. It would encourage people to cross that boundary and not have an artificial separation between them.
Sarah: When you think about the explosion of SaaS applications that every business is using today (and the fact that they’re still popping out to docs and sheets for core parts of their business), what do you tell users and teams about when they should use Coda and when they should use, specific applications?
Shishir: Yeah, good question. I think there’s a lot of differences. People pick differently all the time. You can encode and rebuild many different applications. In Coda, we’ve built this thing we call Packs, which is a pretty interesting, native way for Coda docs to reach out to other applications. We have about 25,000 teams using Coda all over the world, and we see people using our platform both ways. Many of them run entirely on Coda and they do everything with it; it’s their CRM system, their bug-tracker, task manager, note taker, Wiki, everything ends up in Coda. On the other side, we have lots of teams that pick up Coda, start there, and then they connect to the JIRA Pack, or the GitHub Pack. They use it as a coordination, front- end tool for working with those other applications as well. I think that will continue. I expect that ebb and flow will be important. Oftentimes, there’s a few reasons why people choose to do it in Coda versus in other places, the most obvious being that it’s already deployed. For example, say everybody’s already up and running on Salesforce, and you want something that integrates with it rather than replaces it. In other cases, those are applications that have key workflow capabilities that you want to be able to reach out to. For example, we’re big customers of Intercom as our tool for messaging and communication. There are a set of things that Intercom does that are just best in class and really critical and so we’re happy to integrate them and use them in addition to Coda. The types of things you can do in Coda will go pretty far, and we try to have the best of both. Use Coda when it’s possible, but we have also really embraced the idea that when you use other tools, you should feel like Coda is a great add-on.
Sarah: Yeah, I remember thinking even at the Series A presentation for Coda (original name Krypton) that this was going to be such a durable need, even as people found more and more of these best in breed applications like an Intercom. I thought this because you saw this behavior happen all the time where people needed to connect functionality, or break out of an application somehow, and all of these horizontal data analysis systems and workflows and communication just never ended up in each of these applications. I remember thinking at the time, “They can solve this tragedy of the commons that happens in SaaS and that is only going to get worse.” It’s really cool to see this happen for more and more teams.
Shishir: Right, here’s a fun observation. I had a fairly experienced founder tell me this about enterprise apps: If you look at the most commonly pressed buttons in any SaaS app, they are “OK”, “Cancel”, and “Export to Excel.” And so in my mind, the idea for Coda is I would like to be this substrate that treats all such things as equivalent building blocks. That’s why Coda Packs look and feel like very, very native experiences in Coda, so you don’t get this feeling of it being in Coda versus not in Coda. It’s a big difference. And that allows people to think of Coda as something that doesn’t have to replace all those things, it just makes all of them better.
Sarah: Coda as a product and as a team has grown quite a bit over the last couple of years. You didn’t start as a fully distributed team. You obviously are now, but in ways that are more durable than just those related to the pandemic. Can you talk a little bit about what the state of the company, is both in terms of the usage you’re seeing, and what your own team looks like?
Shishir: Yeah, so we’ve been a non-headquarters organization for a long time (I like to say we were even before it was cool). Obviously the recent world events have caused teams to stretch that definition even further. I think the way we are distributed now is distributed in a way that I don’t think is normal. There’s a big difference between working in a way that you don’t usually see your teammate and then working in a way where you’re not ever allowed to see your teammates. When we actually started the company, Alex and I had a long debate about our philosophies on centralized companies versus distributed ones. And part of why we opened our office in Seattle so quickly was the viewpoint that companies that start distributed often end up building better companies. (I published a Fisher’s guide to distributed teams that you can find in our gallery that talks a little bit about this history).
A lot of this was formed from my experience at Google. It was in contrast to Microsoft, which was about the most centralized company you could imagine (especially back when I was there. If you weren’t in Redmond, you did not exist. Then I got to Google and it was kind of the opposite. On my YouTube team, we had eight engineering offices around the world, and I had about 25 sales marketing offices around the world, so I got used to it very fast. And then at one point Larry took over as CEO of Google, and he had a change of heart. He came around to all the teams, he made a bunch of changes, he moved us to business units and so on. But the big thing was he came to every team and said he’d like everybody to centralize more. We built this big model of how spread out every team was (in particular, how spread out the product development teams were, how YouTube was in eight places, Chrome was in like 21 places, Maps was in 20-some places. We were all spread out all over the world. And Larry asked us all if we would reduce down to three spots each, and everybody sort of screamed about it. So he came to each of us and asked us; he tried to convince us one-on-one. My first question to him was, “I don’t get it – is this a problem or an opportunity? Larry was the biggest advocate [for being spread out] for years. He said if you could put three engineers in a place, then you can create an office. So for all of us, this looked like a lot of cognitive dissonance. We wondered what was changing.
So we went through this whole process and it actually ended up being kind of a reaffirmation for how we were operating. Google shut down exactly one office – the Atlanta office. It was such a big outcry, we didn’t shut down any others. And basically everything went back to the way it was. And in that process, we all sort of re-justified why we did it. We just got asked, ‘Why do you want to keep these offices?’ And the obvious reason why was because you can hire better. There are more people who want to live everywhere else. We’ve learned that not everybody wants to live in the San Francisco Bay area. I like living here, I find it to be the right match for our family, but for many people it’s not the right match.
But the bigger thing I gave in my writeup for justifying having all these offices was that I thought we ran better as a distributed company than as a centralized plan. And I think the behaviors you implement end up becoming better, even when you’re all together. And I think that was the heart of why we chose for Coda to be distributed.
I think this process today [by which everyone has become distributed] – while terrible for the world in many ways, from a business perspective – is such that people like to say we’re jumping 10 years into the future. I think that’s a really good thing because not only does it equalize the world when you can live anywhere and you can hire from anywhere, it removes a lot of blockages to being able to participate in the startup ecosystem. And I also think it leads to better teams.
Sarah: Let’s talk about what’s happened over the last seven months or so. It’s been crazy for Coda and for everybody, but let’s start with a bright point. I remember from the last board meeting you guys celebrated [because] you’re actually shipping a lot faster than you were last year. What is your hypothesis (or supporting data) as to why that is happening?
Shishir: We’re definitely shipping faster than before and there are a lot of reasons for that. I don’t think it’s just because the company’s growing. We shipped Coda Windows last February, and then as we got more and more feedback from users we knew what to do next and built on it. So that flywheel, that loop of feedback to product launches happened. Once that starts, then it’s sort of hard to stop.
From my perspective, things are moving faster because of other things too. [Back in March] I had to write an email on a Sunday night saying, “Please, everybody, don’t come into work on Monday.” And that was when none of us actually had any idea how long that would be for. Someone wrote back asking me, “I’m going to take a vacation in three weeks – can I still do that?” And I gently wrote to her and said, “Look, I don’t think I need to answer this question for you. I think the world’s going to answer this question for you. But from my perspective, I have no issues.” Then we shifted into that [distributed] process very quickly.
Some of our existing policies very clearly leaned into this. I mentioned this idea where, when you design your company to be distributed, many of your best practices end up being great best practices even when you’re not distributed. One of my favorite examples is how we run meetings. Probably the most iconic tool is this thing we call Dory. For your listeners who aren’t familiar, it’s a tool we actually used at Google. It was built for their famous ‘TGIF’ meeting where every Friday Larry and Sergei would get up in front of the entire company and answer questions from anyone in the company. And there were like 10,000 people in the company. So we used Dory, which is a Q&A voting tool where anyone can put in questions, then you can vote questions up and down, and then they are answered in order of votes. So it was built for scale at Coda, and we rebuilt it into the product (if you go into the product and hit “/Dory” you’ll get one of these.
What it does in meetings is it totally changes the dynamics. I’m sure everyone has been in a meeting where somebody dominates the meeting, right? It’s the loudest person, or the most senior person or whatever the dynamic may be, and everyone else is fighting to get a word in edgewise. In Coda meetings, we tend to go through a writeup or a presentation and everybody silently adds their questions and then votes them up and down, then you go through them in order.
There are a few things that come out of this: Number one, you equalize your group. All of a sudden, you don’t have to be the loudest person. You don’t have to be the most senior person. Your questions get ranked right alongside everybody else’s. So you get this interesting equalization and democratization of feedback.
The second thing you get is you get a ranked discussion. Out of a group of people, you walk out of the meeting and you say, “We didn’t get to answer everything, but we answered everything with at least three votes. So we feel pretty good.” You feel the sense of accomplishment as you come out of things.
The third thing you get is much better questions. If people think about it and they write it down, they end up writing a lot of different pieces and it’s just better.
Another existing technique we do is what is called Pulse Checks, or Sentiment Trackers. It’s a very similar idea to Dory. Each person gets a row to respond to questions like, ‘Should we ship this feature? Should we do this launch? Should we go after this opportunity? Should we change our price?’ Whatever it might be. And we hide everybody’s row. You give and get silent feedback, and then you come back out of it. The main thing we get out of this is that we remove groupthink. Usually you would do something like going around a room and saying, “Do you think we should do this?” And the first person says, “Yes,” the second person would say, “Hell, yes,” so the third person kind of has no choice but to say “Yes.” They don’t get that opportunity to give real feedback.
So these two tools are the ones that we use really often. They were originally developed because it seemed like an important thing to do when, basically every meeting, we had some people on video conference. But then we found this interesting thing where even when we were all in the same room, and even when there were only three people in the meeting, we still used Dory and Pulse. It made the most sense. You’ve seen how we do this in board meetings as well. So I think those tools actually scaled up really well, and, I would say if I were to divide up how the company operated, our official forums actually got even better because it became much more obvious why we do it this way using these tools. As I said, I sent my email that Sunday night and basically every meeting ran exactly the same that week. There was no change. There’s no change in processes. Everything just kept going and because we were already used to it.
The other highlight is in our community. Coda is one of those products where you get surprised every day. It’s the fun of working on a platform. I’ve gotten to work on some really fun ones. YouTube had a similar dynamic where you’d walk in every day to work there would be instances where you couldn’t believe that somebody did this cool thing, and sometimes it’d be heartwarming. It would be like, ‘Oh my gosh, this is so amazing.’ And sometimes it would be terrifying. So far we haven’t had any terrifying experiences at Coda, but you do get surprised a lot.
When the pandemic started, we obviously had some customers who went through real hardship. We got the emails saying, “Hey, I’m going out of business. What do I do about my subscription?” And we work with customers to work through that. But on the flip side, we also saw people that really saw opportunity. There were teams that were getting reconstructed and saying, “Hey, we’ve never worked distributed before. What do we do?” And so we published a remote tool kit that people could use and do things like what we do with meetings.
At the same time, we saw new use cases. We have this Coda publishing feature where you can publish docs and they kind of look and feel like websites. So we had all these people publish guides, they published trackers; they published all these different ways to get connected. One bucket of things that was interesting was people published alumni directories. There are a lot of people who all of a sudden had to change jobs. Some companies are shrinking, some companies are growing, there is just a massive shift in employment. And so a bunch of alumni guides got created. And watching them use Coda to solve problems was really heartwarming.
Sarah: Yeah, one of my many favorite things about Coda is that there’s actually a super diverse user base because docs are a lot more accessible than many, many of the new software products we see in Silicon Valley. I think one of the amazing things and one of the few positive things about the pandemic has been seeing a lot of businesses that are very real-world oriented figure out how to get digital very quickly. I think there’s been this perspective that there are some sectors and some people who really know how to use software, technology, Slack and what have you, and then there is everybody else who isn’t going to really use software – they won’t go digital. But it’s not true. If you look at the incentives that people have, they’re going to keep running their business unless they see dramatic benefit to not doing so. And right now people are seeing a dramatic need for Coda and other tools that they can really get digital with.
Also, I would like to say Coda board meetings are certainly the most structured, participatory meetings I’ve ever experienced. I’m a big fan.
Shishir: Actually, board meetings are one of my favorite examples of meetings that I think can be made so much better. I sit on a bunch of boards myself, and I can find that I go to a board meeting and, like you, I prepare. (For your listeners who don’t know, Sarah is always the most prepared). I’ll come in with my list of observations, and there’s this interesting dynamic in most of the more casual boards that I sit on where I’ll show up and it’s almost like playing jump rope. I’ve got my list of observations and I have to wait for the right slide to come up. And I have to ask this question that I don’t really want an answer to, but I have a point I want to make, so then I get on my soapbox and talk about my point and then I get back down (God forbid that I happen to jump in on a slide that I actually don’t really care that much about). But the rest of the time I have to sit quietly for everything and it’s just a terrible way to go through a meeting.
Board meetings are particularly tough because the whole point is it is made up of people who come in with different perspectives and who don’t work together all the time. They’re experiencing things in different ways, so people are naturally more guarded. People are a little bit more careful. So to have a lot of the dynamics of diversity of thought and getting the best ideas and so on, you have to work to give people that opportunity to do it. I’m thankful for having a board that humors our crazy ideas and has worked with us on them.
Sarah: One point on that: I think that there has been resistance (from lots of people) to the idea of designing meetings. I have to do it in a really organic way just to structure slides and whatever else they use when they make presentations. What advice would you have for leaders who are trying to get their own teams or their boards to participate more in meetings?
Shishir: Yeah, I think there is a key thing here. We have a phrase we use at Coda about how we think of meetings as being in one of four stages: Wallow, Frame, Propose, Close. There is a symbol for it that looks like a little diamond. The idea is that meetings have this arc (picture the shape as open on one side closed on the other side). Sometimes meetings are about opening to new ideas, they’re about expression, they’re about encouraging people to bring new things in. And sometimes they’re about closing down, they’re about, “All right, we’ve got three options. We need to make a choice. We need to commit.” So an observation I would have is just be clear on what state you’re in. Are you in the Wallow stage, where you need new ideas? Are you at the Frame stage, where you think you know these questions you need to answer, but you don’t need to actually answer them yet? Are you all going to commit to answer those questions because we believe they are going to give us the right answer? You might be at the Propose stage, where you have a set of options and you really need to decide which one you are going to go after. Or you can be at the Close stage, where you’ve made your decision and now you need commitment and you need everybody enrolled. You need people to do these specific things.
Much of the feedback I get on structured versus unstructured meetings is really of people misunderstanding which stage you’re at. So we actually have a set of different tools we use for each one. For example, in the Wallow phase the most important thing is a “Yes, and” culture. You want to design things where everybody’s ideas are present. The last thing you want to do is vote on everybody’s ideas. What you really want to do is like give a model where people can express their ideas and then everybody adds to them. So you design a meeting that way in order to do it. The same goes for the Close stage – except the last thing you want is new ideas because we’re done with this. What I need is for you to sign here, we’re all gonna do our part to make this thing successful.
The principle is to design your meetings like you design your apps. When you design your app, you think about your incentives. You think about your game mechanics. You think about, “I have a new onboarding flow and I need notifications at this level.” The thing you’re trying to do is expose to everybody that everybody’s ideas are closer than you think. I don’t think it’s really about structured-versus-unstructured meetings. It’s about incentives. Even what feels unstructured is actually generally quite structured. For example, we’re going to do a brainstorm meeting, but there’s some way that it’s happening.
Diversity is a thing we talk a lot about. And I often find that people talk about it in the context of hiring, but they don’t often talk about it in the places where we experience it all day long. So then we kind of throw up our hands at that problem. I think it’s good to work it into each one of your systems and think about, what do you think you’re correcting for? What biases do you think your team has or doesn’t have? What things are you trying to encourage? Everything’s structured. Even lack of structure is structured.
Sarah: That’s super helpful because it should be visible to everybody that some structure in the conversations you’re having already exists. It might only be emergent, but there’s going to be behaviors you want and don’t, and if you can actually figure out what the incentives are that you want and the behaviors you want, then people are going to be more on board with this idea of designing meetings.
Shishir: Yeah, I agree.
Sarah: Ok, let’s talk about the lowlights of this time – what’s been hard?
Shishir: There’s a couple things. A lot of the hard things have been on the customer side. I mentioned how everybody who serves small businesses at all saw customers go through hardship and that’s just hard to see. You don’t feel good about it. You feel helpless. Some cases you can help and Coda can be a helpful tool, but in some cases, you know, there’s just not that much you can do and that’s unfortunate and sad.
On the team side, on an individual level, some people had really tough times, including people who had people in their families get sick, or just dealing with the hardship of having a family of five stuffed into the house with no school. That can be really hard on people. So that’s been tough. I don’t think there’s magical answers to any of those things.
At a company level, there is something that is probably the hardest about all of this. Think about how you divide up the processes of a company into a set of things that are fairly structured like meetings and things, where we’ve got to do these important things together. And from there, this kind of fabric of the company and this trust level develops. We haven’t all been in the same office for most of the time as a company, so that part we were used to, but we were all in some office, and we were all in some place where you could interact with each other. And more importantly, we have a set of processes where we get together as everybody four times a year. We do it structured around hackathons – we actually just did one last week. I view hackathons a little bit as an excuse for getting together. I love our hackathons; it’s a great part of Coda’s culture. Hackathons never worked for me at YouTube – we never got it to be a productive part of the process – but here, probably like 80% of the best ideas in the product have come out of hackathons. So it’s very effective for us while also being a little bit of an excuse to just get everybody in the same space. We fly everybody in, usually twice a year here and twice a year in Seattle. The reason we do that is because it is an immense trust-building exercise. Those little interactions like having a beer with somebody or sharing lunch with somebody, all of those things build trust that lasts for a long time. You can go weeks without seeing the person, and then once you see them in-person you are reminded,” Oh, that’s another human with similar incentives to me, but with different experiences and a different set of qualities to bring to the table.” And I think losing that is really tough.
I was thinking about when we go back what’s going to stay the same and what’s going to be different. Some of the things, like the way our core official forums work. have all gotten much better, and I think we will lean heavily into those things that we’ve refined. I think there used to be a time where we used to say, “You know, we need to get the company together because we have this important decision to make.” And now we definitely don’t want to do that. Getting everybody together to have this or that decision to make is kind of backwards, because we have good tools for that. I think we’re going to shift to where the time we spend together will be spent much more in trust-building and bond-building than it will be on official work. We sort of did it a little bit before, but I don’t think I appreciated how much that allowed the rest of the processes to work. We’ve now run two hackathons distributed, and obviously we’re going to do more that way because we know there’s no alternative. But I think we’re doing a pretty good job with them.
Sarah: Let’s dig into that a little bit more. I remember [the phrase] that “ Human connection (or in real life) matters.” That was one of your four principles of the distributed team. Go check out this doc, listeners. But let’s get real for a minute in that you can’t have that right now. You can’t have that for who knows how long. I really admire leadership. You’re in a battle with – all things considered – a relatively small team for the next application of productivity platforms. That’s a very big ambition and it’s scary because you’re competing with other well-funded startups and some of the biggest and most, most competent incumbents out there. But you have commanded enormous loyalty and enthusiasm from people for a number of years already. Like how do you think about maintaining that sense of connection both as a leader without this opportunity for in-real life [interactions]?
Shishir: I mean, it’s hard. I’d say other things I feel very confident about, and there are ones that I’m not sure, or am somewhat nervous about. We’re trying a lot of things, and I’m not sure any of them are great yet. Some of the things we’re trying (and I’m sure every company is doing a version of these things) where we have a set of things that are just trying to recreate those physical forms of interaction. We do virtual lunch on Mondays, and everybody picks different rooms and you jump in – no real set topics to discuss. So sometimes people pick a game to play, or they pick a real topic they talk about and just try to recreate the lunch environment. We do a similar happy hour type thing. We also try really hard to build a set of fun into the experience. I think that goes an enormously long way; just having a culture where people know that you can sort of relax a bit and express yourself in different ways. We did one for the hackathon. The theme was Overcooked. We had two people run this hackathon, Kelsey and Thomas, who really like the game called Overcooked, so they basically leaned all the way into it: They mailed us all aprons that have Coda logos on it, we all took this group picture, everybody changed their names on our various communication tools (Slack, and so on) to have a name that has something to do with the food. And just like little things like that were really helpful. It’s a prompt for just trying to create that trust: How do we make sure we just remember who each other is and still celebrate the little things that make us all human?
Sarah: Yeah. I think a lot of teams are recognizing that this is now something that is missing. The first thing I feel like everybody went to when going to a more distributed work – and which was the correct thing to go to first – was “We need structure, we need asynchronous communication. We need to figure out how we can make decisions remotely.” But I think as we get deeper into this, people are feeling more deeply that gap of a sense of connection to our teams and being important to other people’s productivity.
Let’s switch gears a little bit to a tactical topic.You just raised a really large round of financing for Coda. You clearly did it during a period whenyou couldn’t go hang out with people in person. Talk a little bit about that, or any learnings for entrepreneurs.
Shishir: I would say it was somewhat unexpected. We’ve had a really good 18 months getting the product to scale really fast since we launched last year. But I was not expecting to raise money now. We didn’t really need it, and my view was what everybody told us: In the middle of a pandemic, don’t expect to raise money. But we got preemptive interest from a few different folks who had been following us for a while. We ran a very quick one-week process and it turned out more people were interested than we thought. I was really excited to get Mamoon to lead the round. Mamoon from Kleiner’s leading and I view him as one of the best B2B SaaS investors out there. He’s been at the top of my list for awhile and I was really excited to get him involved.
And of course from the company’s perspective, it allows us to forward invest in terms of the process itself. In some sense, being all-remote actually accelerated the process. We haven’t had to raise money for Coda often. But I’ve watched it with companies and the process can be exhausting. It’s meeting after meeting ,and go meet somebody here, then the Monday partner meetings and you’re going back and forth between Menlo Park and San Francisco. At best, you can fit in three different meetings. And then all of a sudden, you could do 10 meetings a day and there were four diligence processes happening at the same time. Back to our previous point on structured-versus-unstructured meetings – you can do all that stuff much faster and get everybody together. Most of the partnership meetings were better attended than they would’ve been in the past. Everybody’s there because they have nowhere else to be, and they’re all present for it. The part that I think was much harder was that trust-building part. People say this a lot about raising money: build those relationships when you’re not raising money. For better or worse, that was very important to us. If you have a lot of trust, you understand each other better. With others, if you’re starting to build that relationship and you’re doing that over Zoom with very directed interactions, it’s hard to do. It’s going to speed up the process, which I think it’s a good thing, but it’s going to lean even heavier on relationships that you might have cemented beforehand and will really change those into becoming more important.
I remember when it started and I had a set of investors telling me, “We can’t possibly invest without taking the founder to dinner.” Obviously that’s changing. That can’t be a requirement anymore. But from the founder’s perspective as well, the people that invest in your company are gonna be with you for a decade. To do that without someone whom you feel like you know is really hard. And I would just tell everybody, get to know people when you’re not raising money. It’s 10 times more important now than it was before.
Sarah: Yep. I’ve made two investments in this period of time. One with founders that I had already known and worked with (and that was like quite easy actually, because you’re just looking for more data, more understanding of the right opportunity). And another was a decision that I felt extremely high conviction on, but it still felt like taking a new kind of risk. This founder is going to laugh cause he’s eventually going to hear it. But there is some sense of another human whom you haven’t spent in-real-life time with: “Is this guy an axe murderer? Is he actually a high integrity person?” Hundreds of references say so, but you never know.
Shishir: Right. It’s probably worth mentioning the diversity of our round. Mamoon led, and we had five other firms that participated and a big list of angels. The diversity of that group was much higher because of this distributed nature. We have firms participating from Boston, Seattle. We have angels from all over the world. I think that’s a big positive.
There is still that feeling like I don’t quite know who this person is. My favorite is knowing whether they’re an expert or not – I don’t know, so you do a better job of referencing. I don’t know that looking someone in the eye actually tells you that. One of my favorite examples is you meet someone that you’ve only met on Zoom. It’s always an interesting experience when you get into a real room with them for the first time in-person and it’s like, “Oh! my mental image of you is completely shot. Little things like are unimportant in the investment decision (or at least should be), but still, seeing someone in person means that piece of thinking you don’t really know the person goes away. I think it’s probably positive that like you replace that with reference checks. You probably did three times as many reference checks as you would have done otherwise. And that’s great. I think that’s probably a better signal than then something like, Oh, I happened to have dinner with this person three times and so I feel like I know them. I don’t think it’s necessarily a bad thing, but for founders and for investors as well, I think it’s just much harder.
Sarah: And for any listener, I am actually six feet tall and you can’t tell
Shishir: Yeah, you are the perfect example of this. I’d be very curious. You should get the people that you just address in Zoom to guess how tall you are and nobody’s going to come close.
Sarah: Okay. So the fun part here: You have been thinking deeply about collaboration for a couple of decades. This last half year has obviously probably triggered new beliefs about it. What is the most contrarian belief you have about collaboration?
Shishir: I get asked a lot about how we think that product productivity tools are changing fast, because they’ve been mostly the same for 40 or 50 years. You know, what makes you think that they’re going to change? Some people hear that statement that things haven’t changed in 50 years and they think, “Oh, that’s an opportunity [for innovation.]” I mean, not that many things last that long.
I think there are two things that are going to lead to a dramatic shift in how many party tools we see and how much innovation we see in this space. I think we are already seeing one: for the first time in a long time, the primary innovative innovators in the space are not platform companies. If you look back at the Office franchise and Docs, Excel got created because Microsoft needed to make sure there was a great version of Excel on their operating systems and Apple created the iWorks suite because it was a hedge against Office working on Mac iOS. And Google created Google Docs because they wanted to make sure that they had the browser that was the predominant platform. Each of those companies’ incentives to actually innovate in the core product was much lower than ensuring the success of their platform. And I’m not saying that in a positive or negative way; it’s just an observation that we’ve just had multiple generations of that. And I think that dam got broken, and now we’re seeing people come in without that incentive, and that leads to a different class of innovation.
The second one related to that, but it’s maybe more subtle, is what I call the death of the file format. You know, if you go back and look at the iWorks suite, I think what Apple did with Pages, Keynote and Numbers was that they actually tried. They shifted the model and it didn’t really work. I think each of those products is quite good, but none of them really took off. And I think the reason is fairly simple. If you go build something in Keynote and then try to send it to someone, you need to make sure that they have Keynote and they need to make sure they have a Mac.And so the chances of that spreading is much, much lower. And I think the big thing that’s changed here. When Google Docs came out, we all got, well, first everybody was super skeptical. Then we all got impressed by collaboration and said, “Oh my gosh, this is magical that we can all type in the same place.” But the other thing that happened with Google Docs is that it got rid of our formats. Now, if I send you a Google sheet and say, “Can you look at this?” I don’t need to know that you’ve got this thing installed. You can just use it.
The story gets told about Beta versus VHS a lot. Some of your listeners are gonna have no idea what I’m talking about, but it was very hard for Beta to take off because they only had that one format and too many people had VHS recorders and players. I think the same thing happened with software file formats and it kind of made us all stuck. Now, as everything moves to the cloud, I think we’re going to see a very different pace of innovation
Sarah: Yeah. I remember in the memo for Krypton, now Coda, we didn’t have nearly as clever a tagline for it as “Death of the File Format”, but it was basically the idea that web collaboration was the thing that was going to enable people to break away from the office suite, and you were no longer hostage to using something that everybody else could open.
Shishir: Yeah. Actually I have another one for you. This might be even more contrarian. So I got to YouTube in 2008, and the first time I had to give a speech about the company was a couple months later. I used this line (the one I told you earlier that “With online video, we’ll do to cable what cable did to broadcast. And we’re going to go from three channels to 300 channels to 3 million channels.” And at the time we, I basically got laughed out of the room. Nobody knew what I was talking about. The YouTube competition at the time was MySpace and Flickr. People looked at me and said, “You really think your cat videos can compete with Disney and ESPN? Like what, what, what crazy world are you living in?” And obviously now it’s a decade later and that statement has clearly come out to be true.
I think the thing that everybody missed about it is the existence of what I call the Maker Generation. They missed human ingenuity. They missed the idea that humans are natural makers. And I get asked a lot about what people should think about me going from YouTube to Coda, because for a lot of people, that feels totally different. It’s going from media to software, and it’s B2B versus B2C.
I don’t view it that way. I actually view it as I’m working on an extension of the same mission, and that what’s actually happening with Coda and tools like this is that we’re embracing the same maker generation. I think tools like Coda will do to software what YouTube did to video, and we’re going to see a completely different class of people turn into makers. And the interesting thing is they’re not going to think of it the same way. Just like YouTube creators. In those days [when it was started] people thought you had to live in LA and go to USC film school to be a great video creator, and they were dismissive of all the people that didn’t meet those criteria. And then gradually that group of people just got bigger and bigger and bigger. I think similarly with Coda, you no longer have to have an engineering degree to reinvent how your planning system works at your company or how your fitness program works for your family, or whatever you might want to want to imagine. And those people are not going to think of themselves as developers, because they think they’re just building docs.
Sarah: That is aggressive of you to share. I love it.
Okay. Last section is quick takes. We’re all stuck at home. What’s a rec you have – book, movie tweet, video, podcast?
Shishir: Okay. Podcast: I recommend Hardcore History. Anybody who doesn’t know Dan Carlin – listen to his podcast. It’s amazing. I think he’s one of the best storytellers I’ve ever heard.
A book that I’ll stretch into a doc. There’s a doc written by Des Traynor called Des Productivity Guide. It’s on Coda. And it starts with a tweet that I think is really awesome: “Thinking about productivity is tools. Your email is what others think you should work, on your to do list is what you think you should work on. And your calendar is usually what you actually work on. How much of the overlap is your world?” You can go read the rest of it yourself. It was transformational to how I think about my time and how I think about focus.
Sarah: Okay. Shout out: One way someone on your team has stepped up during the last half year.
Shishir: An engineer named Krunal built this doc called “The More You Know” which I think is a really fun example. Everybody puts in these facts and every day it just Slacks out a fact. And some of them are like little tidbits about people in the company. Some of them are historical things. I added a whole bunch of facts about Legos – I’m super into Legos. It’s just a really fun and easy way to connect.
Sarah: Awesome. Okay. And then Discovery: Weirdest thing you’ve learned about you, your family, Alex or the team during the last half year?
Shishir: Okay. My family is the easiest one. The impact of TikTok on this family is hard to overstate. We’re all on it all the time, my younger daughter in particular. She cannot walk into a room without doing a back dance, and it’s just become part of her personality. And they suckered me and my wife into doing a bunch of them too – you can go find them if you like. I just think it’s so interesting because I have a bunch of industry conversations where everybody’s talking about TikTok as this really interesting, you know, geopolitical battle, and at home, I’m just watching this new format – new formats don’t happen very often – and I really love it. I think it’s participatory, it’s positive, it’s encouraging, it’s challenging. I think it’s great. So that’s been really fun.
Sarah: Awesome. I don’t know if you remember this, but we were Series A investors in Music.ly, which became TikTok. So just imagine the Greylock partner conversation around the product when it was like, mostly girls doing funny dances. Well, it still is girls doing funny dances. Can you imagine us trying to explain ‘why?’
Shishir: Oh my gosh. Yeah, I cannot imagine investing in this product back then. That must have been really hard.
Sarah: I’m definitely going to show a TikTok video to share at the next board meeting.
Shishir: All right, sounds good!
Sarah: Okay. That’s a wrap. Shishir, thanks for coming on.
Shishir: Thanks Sarah. Thanks for having me. It was a lot of fun.
