A Better Way to Spend Your Calendar Time with Woven and Tim Campos

Tim Campos: The only solution is to understand the details of how calendars are built, and that’s when I first got the idea that maybe there’s a better way here. Because as I got into the details of this, I was horrified to learn that the calendaring views that you see, particularly in Microsoft Outlook, are basically just a collection of e-mails.

Joe Casabona: This week I had the pleasure of speaking to Tim Campos, former CIO of Facebook and founder of Woven, a calendar that accounts for your life and your free time. We talk about his experience at Facebook and how it led him to the idea of creating Woven, stats on how people spend their time and schedule meetings, and more. If you want some incredible insights into how people manage their time, this episode is for you. But first, let’s go to a word from our sponsors.

Break: This episode is brought to you by our friends at Ahoy! The easiest way to increase customer engagement on your WordPress site. Install Ahoy! Create a message box, configure a way to display it, and start seeing conversions come in. You can create messages for cart abandonment, up-sales and cross-sells, custom support, and so much more. Ahoy! Has flexible conditions that let you choose exactly where and when you want your message to be displayed. I’ve recently installed it on my own WooCommerce site, and I’ve already seen increased engagement. I know this because of Ahoy! and it’s powerful analytics and reporting. You will see ROI within days of installing Ahoy! If not sooner. That’s even more true for listeners of How I Built It. You can get an exclusive 20% discount on any plan. Visit UseAhoy.com/HowIBuiltIt and use the code HOWIBUILTIT at checkout. Use those today and increase your engagement in sales on your WordPress site. Thanks to Ahoy! for their support of this show.

Joe: Hey, everybody. Welcome to another episode of How I Built It, the podcast that asks, “How did you build that?” Today my guest is Tim Campos, and he is the founder and CEO of Woven. He is also a software engineer and former CIO of Facebook. Tim, thanks for joining me today.

Tim: It’s great to be here. Thanks for having me.

Joe: Not a problem. I’m excited to talk to you. It sounds like you’ve got a wide range of experience and I’m excited to dive into that. But first, let’s start off with who you are and what you currently do.

Tim: Awesome. As you mentioned, I’m the founder and CEO of a company named Woven. Woven is an intelligent calendar that we built in an effort to reimagine what calendars can do, to basically help all of us spend time on what matters most. We do that by changing how the calendar is built. Most calendars, all calendars are built on top of e-mail, and Woven is built in a very different way, which allows us to take calendar events and interconnect them with the things that we spend time on, whether that’s documents, or issues, or absolutely other people. Our long term vision is to help people spend time on what matters most to them.

Joe: That’s fantastic. I feel like calendars and e-mails are apps and nuts that people have been trying to crack since the nexus of time. I’m always interested to hear about how things are reimagined, because even today, managing calendars is difficult, even with all these other tools to help us convert time zones and get people on the same page. So it’s interesting to see products like that out in the wild.

Tim: Yeah, Let’s start with e-mail real quick, and what’s wrong with e-mail. In many respects, what’s wrong with e-mail is the premise from the beginning. It is the electronic memoranda, and it came of age at a time when computers were used to automate paper-based processes. With time, is you have a whole generation of people who grew up with technology, the memoranda is not the right way to communicate with each other. That’s why we have text messaging. It’s why we have Facebook. It’s why we have WhatsApp. It’s why we have Slack and other technologies that you couldn’t do on paper. E-mail has largely been reimagined by moving off of it and using other technologies. Calendars are a little bit different because they pertain to this issue of time. We all have time, we all have the same amount of time. There’s only 24 hours in a day, and it doesn’t matter who you are and what you do, you and I have the exact same amount of time today. But what the calendar suffers from is based on how it’s built. First off, it’s a feature of a suite, so it doesn’t get a lot of love from companies like Microsoft and Google. Just by existing, Woven helps with that, because this is all we think about, we’re just 100% focused on making the calendar better. Second, there is a lot of things about calendars that are just wrong. Most of us have a little bit of our time on Google. Most people put their personal calendars in Google Calendar, and some people have their professional lives in Google as well. Google has lots of different calendars. For every single calendar, there is another 24 hours in your day, except there isn’t. If I have three calendars, that doesn’t mean there are 72 hours for me today. It means I have 72 hours of time I have to administer. That creates a lot of work for people. Woven understands that, even though I might have a work calendar and a personal calendar, there’s only one of me. So I can only be in one place at one time. So it brings all of that stuff together, to help me make sure that if I’m busy because I have a doctor’s appointment, then I’m not available to take an appointment at work or vice versa. If I have a dinner appointment professionally, then I’m not going to be home that night to spend time with my family. Those are just some of the things that we do. The other things that I think make calendars very difficult is they’re very isolated. If you and I want to meet together, I want to meet with you, you want to meet with me, how do we solve that problem? We end up sending e-mails to each other, like “How about next Thursday? That doesn’t work, how about Friday? How about the following week?” It goes back and forth and back and forth because the calendars don’t talk to each other. If they could talk to each other, you could press a button and say, “When’s the next time that we’re both free, for a dinner meeting?” Which is not going to be tomorrow at 3:00 in the morning, it’s going to be sometime between 6:00 and 9:00 PM on a weeknight, or maybe on a weekend night, depending on our relationship. Again, we’ve taught Woven how to be intelligent around those things to help people out. Those are just some of the things that we do to make the calendar more intelligent. There’s a lot more that make this product a very rich product.

Joe: Yeah, I love that. I mean, the fact that calendars are isolated. I hate doing that “What’s good for you” dance and that’s why I use Calendly for this “I don’t know what time zone you’re in and we didn’t have to talk about that. I just sent you a link, and you picked an appropriate time, based on what I’ve made available. If everybody I know did that, it would be amazing. I have people who are like, “I’m not going to use it.”

Tim: Now imagine Calendly, tightly integrated with your calendar, so that you can see all of the different scheduling links that you’ve sent out to people and if those people were using that exact same product, that instead of them having to go through an awkward user interface to select the time that works, that their calendars just told them “Here are the slots that are going to work for Joe and I.” That’s Woven, that’s basically how the product works.

Joe: Nice. That’s fantastic. Because I mean, when somebody sends me a Calendly link, I still have to look at my calendar.

Tim: Yeah.

Joe: That’s great. Very cool. I’ve looked at the website, but I haven’t downloaded Woven. I’m definitely going to download it after we talk here if it’s available.

Tim: Awesome. Yeah, there is an open beta for Google Calendar users.

Joe: Awesome. I like all of those words. So that’s what you currently do now, but you’ve also been a software engineer, and you were CIO of Facebook. Let’s start with software engineering. Did you do software engineering at Facebook, or was that somewhere else?

Tim: I started my career as a software engineer at a company called Sybase and did software engineering at Sybase, Silicon Graphics, an internet startup. At that Internet startup, this was back in the early days of software as a service. In that kind of world, the concept of IT, or what it takes to deliver this software and software engineering are much more fused. That’s what got me into IT. I spent the next– After [Portaris], some six and a half years as the CIO of a company called [Kelly 10 Core]. At Facebook, I got to bring it all back together, because my job at Facebook started off being a very traditional IT job, but I brought engineering into the organization because we were building a lot of the software that helped make Facebook employees more productive. Everything from the visitor management system that employees would interface with as they walked in the door, to the recruiting systems, CRM systems that we built for sales, internal productivity systems for employees to be able to schedule meetings with each other and to collaborate with each other. We did a lot of custom-built software, and some of this software made its way into Facebook’s products, things like audience insights, for example. Some of this software became the inspiration for technologies like Envoy. We were quite flattered to see companies make real businesses off of some of the things that we pioneered and created. Some of this stuff continues to be very unique and proprietary to Facebook, but it was all a key part of how we made the workforce more productive. We literally engineered our way there, and while I was at Facebook, we doubled the productivity of the workforce.

Joe: Wow. That’s incredible. To get an idea of the scale of the stuff you were doing, you were at Facebook in the earlier part of this decade. So about how many employees?

Tim: Facebook was relatively small, about 1400 people, just about to cross a billion dollars in revenue. Then when I left, we had not only 20,000 employees, but another 15,000 or so contractors on top of that. A workforce of close to 35,000 people, running on a 40 billion dollar run rate. The company had grown up and become quite the behemoth. My job was to basically help the company achieve that growth without having to scale linearly. If we could make it so that a salesperson could sell more, or a recruiter could help recruit more, or HR person could support more employees, or facilities could support what they do with less people. We could grow the impact of the company without having to grow the workforce at the same rate. That’s how we were able to double the productivity of the workforce.

Joe: Wow. That’s incredible. I’m sure doing all of this, probably gave you a lot of ideas for Woven. Let’s talk about that now. How did your experience as CIO of Facebook give you this insight into how you felt Woven should work? Is it just you or did you have a co-founder, too? What’s the origin story of Woven?

Tim: Sure. I have a co-founder, who was also at Facebook, while I was there. The story starts almost two weeks into my tenure at Facebook, where one of the first problems that I was faced was, the company was having a lot of trouble keeping the calendaring system functioning properly. Literally two weeks in, I was called to Zuck’s desk, by his EA. I was excited to have this conversation with Zuck. Only to find, when I got there, that it was just me and not only his EA but several of the others who were yelling at me about all the problems that they were having with the calendaring system. Events that would disappear, conference rooms that would get double booked, things that were both embarrassing for them and real productivity drains, for not only them but the people that they supported. To solve this, you have to put yourself back in the time, and this is 2010. Facebook was running Exchange at the time. It had a workforce that had a lot of Apple devices. That was not a very healthy combination. It was also not a combination that we were going to change. The only solution is to understand the details of how calendars are built, and that’s when I first got the idea that maybe there’s a better way here. Because as I got into the details of this, I was horrified to learn that the calendaring views that you see, particularly in Microsoft Outlook, are basically just a collection of e-mails. Special e-mails, but a calendar invite is just a specially formatted e-mail. Microsoft Outlook would collect all these things and then present them to you in what we see as a calendar. One of the worst parts about that is if somebody makes a change to a counter-event and doesn’t tell you about it. Then you don’t know about it. If they don’t send you the e-mail, then you don’t know. Whether you are a person or a conference room, this is the source of just a tremendous amount of pain. So we were able to work through this stuff, but it also gave birth to some ideas of maybe there’s a better way to manage this kind of information. Already for Facebook, there was a lot of demand for tools that would be better if they knew when employees were busy, or when resources were busy. When we moved to Menlo Park, we have these really beautiful giant touchscreen displays that show you where people sit and also where the different conference rooms are, and they’re wayfinders, they help you find your way within the campus. Part of what they were designed to do is to help you find a free conference room if you’re trying to do a one on one with somebody and we needed to get that information out of the calendar. Is a conference room free, or busy? It turns out that wasn’t easy, at the time, to get that data. So we built what was a wrapper around Exchange, very similar to what Woven is to Gmail and Office 365, to support that. That same wrapper gave us the ability to do a bunch of other sophisticated things. For example, Facebook does a lot of interviews, a lot of software engineering interviews. A software engineering interview is at least four people, the candidate, obviously and of course you’re going to have to have conference rooms for all this. At the time, in fact, still to this day, Facebook does well over 100,000 software engineering interviews a year. That’s a lot of things to coordinate, more than can be done by people. So we built systems that would take the availability of candidates, availability of panelists, availability of conference rooms and mash all that stuff and come up with what the ideal scheduling plan would be for a candidate, to help a scheduler get things done quickly and more efficiently. We found more and more different opportunities to solve problems using calendar data. That’s what ultimately gave birth to the idea that “Maybe we should go do this for other people and not just for Facebook.” That’s when my co-founder and I left the company to create what Woven is.

Joe: You left around 2016, is that right?

Tim: Yes. We left at the end of 2016, right after the election, no relation. Choice of departure, although it turned out to be a good one.

Joe: Yeah. I was going to say, good timing.

Tim: Immediately started focusing on fundraising for the company. Created Woven right away and closed our seed financing a few months later and hired our first employee. That was May of 2017.

Break: This episode is brought to you by Pantheon. Starting a new project? Looking for a better hosting platform? Pantheon is an integrated set of tools to build, launch, and run websites. Get high-performance hosting for your WordPress sites, plus a comprehensive toolkit to supercharge your team and help you launch faster. On Pantheon, you get expert support from real developers, best in class security, and the most innovative technology to host and manage your websites. You can sign up a new site in minutes with a free account, and you only pay when it goes live. That is my second favorite feature to Pantheon, only to the easy ability to create dev staging and live servers and push to GitHub. It’s very easy to set those things up on Pantheon, so you can head over to Pantheon.io today. Again, set up a free account and pay only when it goes live. Thanks so much to Pantheon for their support of this episode and this season of How I Built It.

Joe: So you had all this insight, you built something that you knew would scale, because I mean, 35,000 people and a workforce and rooms and stuff like that. Let’s get into the nitty-gritty, the title question. How did you build this first version of Woven? You mentioned that Facebook was using Exchange at the time. This is built more for Google Calendar and soon, Office 365. So we could we get as technical as you want. We can tell about the programming language, or we could talk about the high– We built a wrapper on Google Calendar, and this is how we’re doing this.

Tim: So there’s a lot of Woven that was inspired by Facebook. Facebook had a phenomenal environment for building products, whether you’re talking about the products that everybody knows and loves, like Instagram and Facebook Messenger or internal products that most people aren’t aware of, but employees use every single day. That’s all built on top of set of technologies, a set of services that are largely common across all of these different products that run on scalable infrastructure, that abstracts a lot of things from the software engineer. Facebook– A lot of those ideas made their way into Woven. Facebook is built on a graph and has a very rich graph engine. That graph engine manages entities and relationships between those entities. In the case of Facebook, you’re talking about people and their friendships or photographs and likes and Facebook pages and addresses that you might check-in at. Those are all different examples of entities and the relationships that you have. With Woven, it’s similar but different. You still have people who go to meetings, and you have locations, but you have the whole notion of time and other information that might be related to a meeting or an event, like private notes or tags or alternative suggestions for when an event can occur, or even things like documents and customer records and other information. All that’s managed in a graph engine, so very much inspired by Facebook. We replicated a lot of the ideas on how Facebook does continuous integration. The Facebook site is pushed multiple times a day. You don’t have, even though there’s– I can’t say exactly how many servers and probably wouldn’t even know it at today’s day and age, but it’s a lot, let’s put it that way. So it’s just not possible for that to be human administered. You have a lot of technology and automation that handles the replication of software through the environment, and we’ve started with that same idea. Woven is built on an infrastructure that allows us to push changes into staging environments, as soon as they’re coded. Then we can test that. Today we do it twice a week. We could do it as frequently as we want or as infrequently as we want. To push from our staging environment to production is a very simple process. If there are any problems, it’s very easy for us to roll back. We have multiple environments to test and verify that everything is working and a lot of automation in here. Automated tests to make sure that code changes are ready to be merged into the master branch. A lot of tests to ensure that environments are ready to promote from testing to staging, to production. What that does is it offloads the work from the engineers. Now they can focus on their particular changes and what they’re working on at the time. It’s created a very efficient environment. So we’re relatively small, in terms of the number of engineers that we have, but we have done a massive amount of functionality, in a relatively short period of time. Thanks to the architecture of this environment.

Joe: That sounds fantastic. As a developer, making the development environment as easy as possible, for one, is a dream. So that sounds cool. It’s cool that you were able to take a lot of the stuff that you learned at Facebook. Let’s talk a little bit more about the product and the feature set. I know we touched on this a bit, but how did you decide to build out these features? Because, the common calendar exchange, as we talked about, is “When are you free? It’s 4:00 PM in Eastern Time, that’s 1:00 PM Pacific, or whatever. Daylight Savings Time changes things. How did you determine exactly how you would figure out “This is the calendar, this is what free times worked for both of us, and things like that.” What’s that handshake like?

Tim: Some of this came from a lot of user research. Some of that user research we were able to do while we were still at Facebook. Some of it was done afterwards, but it came from the understanding that there’s similarities across people on how they manage time. For example, when you think about, “How does an event show up on your calendar?” It starts with an idea like “I want to meet with Joe.” That idea then becomes a collaboration where I’m like, “Hey Joe, and you want to get together? When would work for you?” We start collaborating on this concept of an event, and that collaboration continues even after we schedule it. Maybe we have our– Maybe we’re doing a dinner party. We’ve got our dinner party coordinated, but who’s going to bring the appetizers? Who’s going to bring the main course? Who’s bringing the dessert? Who’s bringing the wine? There’s continued collaboration there. Or maybe we’re talking about a different kind of an event, like an interview. I’ve got a candidate who’s coming in to meet with me and two other people. What am I going to ask this candidate vs. the other two people? What are some of the concerns that the candidate has that we want to make sure we address in that interview? Again, that’s the collaboration that occurs on an event. We studied this and learned what the general workflow is across events. Then we wanted to architect a system that would support that. There were some very simple ideas that are profound. For example, there is no events on your calendar that don’t have a time associated with them. The counter needs a time in order for an event to go on the calendar. That’s not the case with Woven. We can have calendaring events that don’t yet have time so that they can be collaborated on. We call them scheduling links, similar to what Calendly has, but Calendly’s links are persistent. You have a web URL that you can go to all the time. So after I’ve scheduled this podcast, I can schedule another podcast. But most people don’t operate that way when they’re scheduling their events, and it’s a one-time thing. Let’s get together for drinks one time. So our scheduling links exist both in Calendly form, as well as in one-off form. But that’s, like I said, just the beginning. The information that we can now associate with those events also follows the lifecycle of the event, both the pre-meeting activities. The “Let’s get you into the meeting activity.” and then the follow-up activity. What’s the follow up from this interview or what’s the follow up from this? Maybe it’s a board meeting that you went to. As we studied that by talking to more and more people, then we had the general ideas of the architecture. The next thing that was important is to get some data because we wanted to know, “How many times do people meet with one person? How many times do they meet with multiple people? How many times do they just put stuff on their calendar when there’s nobody blocking out time to take the kids to school, or something like that?” We partnered with a few different companies, and we asked them if we could survey their calendar data, and they gave us permission to do that. That gave us some really valuable insights on what’s common between companies and what’s different between companies. That, again, fed into some of the design decisions that we made in the back end. Then finally, we started the user journeys. Figuring out, “What problems are we going to solve, and how are we going to solve them?” We started by designing them first, getting some mocks of what they might look like, talking to a lot of people about those capabilities. Once we got those mocks to a state that we were comfortable with– In parallel, we were building our engineering team, so we then had the people to start building this. That’s the general strategy that we followed. I’d say it’s evolved a bit as we’ve matured as a company and as the product has gotten more mature, but we still follow a lot of the same concepts and principles.

Break: This episode is brought to you by Gusto. Now, small business owners wear a lot of hats. I know, I am one of them. While some hats are great, like doing this podcast and getting to talk to people, others like the “Filing taxes” and “Running payroll” hats are not so great. That’s where Gusto comes in. Gusto makes payroll taxes and managing a team easy for small businesses. Gusto automatically pays and files your federal, state, and local taxes, so you don’t have to worry about it. As a New Yorker supplanted to Pennsylvania, not paying my local taxes, thing bit me a couple of times. It would’ve been great to have Gusto then. Plus, they make it easy to add on health benefits or even 401Ks for your team. You can also get direct access to certified HR experts, too. This sounds like a pretty good way to kick off 2020 for your business, right? But here’s the thing. Deadlines for the new year creep up earlier than you think, and you’re going to want to get started now. I don’t know about you, but I know that I’ve started thinking about this stuff around this time and all of a sudden February or March is here, and I’m like, “I need to do something about my taxes.” So don’t wait, let Gusto make it easier on you. As a bonus, listeners get three months free when they run their first payroll. This is one hat you’re going to be glad you gave up, I certainly am. You can try a bonus and see it for yourself over at Gusto.com/Build. Get three months free when you run your first payroll, try a demo, and see it for yourself over at Gusto.com/Build. Thanks so much to Gusto for their support of this show.

Joe: I think I maybe realized– I think it’s always been the case, but I’m just realizing this now as you’re talking, that I am also insanely interested in how people manage their calendars. Because I’ve seen, when I was employed by an agency, I saw my boss’s calendar, and it was just overlapping meetings. I’m like, “How do you live your life?” I am always– We talked about this in the preshow, where I block specific recording times off for this show. I’ll put blocks on my calendar for “This is going to be deep work. Nobody can have this time.” I’m sure digging into that information was incredibly interesting. I don’t know how much data you could share, but were you looking at like US trends, or worldwide specific areas of the world? Did you find that Europeans and Americans manage their calendars differently?

Tim: We focused largely on the US and Canada, as markets. A couple of other markets that were in Australia and the UK tend to have very similar meeting behaviors. I will share some things that we did find that were interesting. We now have over 45 million events that are managed inside of Woven, so it’s quite a bit, and we’re able to use that information to help us really fine-tune how we build the product. One of the things that we had a question on early is “First off, when do people meet? What’s the most common time of day for people to meet?” The other question was, “How far in advance do they typically schedule?” We were originally debating, “Is a 7:00 AM meeting very common?” When does the day stop? Is a 6:00 PM meeting, quite common. If I could show you the histogram of events, you’d find it’s interesting, that most people do not start their day before 9:00 AM. There’s a few that start their day at 8:00 and a very small percentage that start their day at 7:00, but it’s a quite tall spike between 6:00 AM, and 10:00 AM, on when meetings start to occur. 10:00 AM is actually the most common spot in the day. That’s when people seem to like to meet the most. Then when you get to the end of the day, it falls off in a much slower fashion. There’s not the equivalent “It’s 5:00, and there’s no more meetings scheduled for people.” Instead, that extends out into the evening, on a very long, slow degradation. That was one thing that was interesting for us, is how there’s not a lot of people who like to use their early morning time, at least from a calendar perspective, and it very much mirrors a personal anecdote that I have that I like to do my workouts and my maker time, early in the morning because I’m the least likely to get interrupted and least likely to have conflicts. With this data, I could see why that universally people generally don’t use that time to meet with each other. The second thing that was interesting is “How far in advance do people schedule? Is it two weeks in advance, is it one week advance is it a couple of days in advance?” It was really interesting to see that the most common interval is actually a day or less, which makes using your calendar for planning purposes tricky, because it means that if I’m looking at what’s going on two weeks in the future, I actually don’t have all the events that I’m going to put on my calendar there yet. This also mirrors a common bit of anecdotal feedback that we’ve gotten, where people will make commitments in their time, in the future thinking “I can meet with so-and-so in a couple of weeks because I don’t look like I’m that busy.” But really, the decision that they’re making is “It’s not so important to meet with so-and-so today, because my calendar says I’m free two weeks from now, I’ll make the time for them then.” Except they’re not free two weeks from now. They don’t know what they’re busy with yet. So if you could build a calendar, a pro forma calendar– How you normally consume your time, you have a better understanding of whether or not you actually could take a meeting and it would help you prioritize better. I’ve seen for myself, and I have a pretty consistent pattern of 26 hours a week of meetings. No matter what’s going on, I have 26 hours of meetings. Sometimes it goes up and down by a few hours, but the average is pretty consistently 26 hours. If I start with an idea that “I only have 14 hours left.” for something that I wouldn’t normally do, I can answer that question “Does this fit in the 14 hours of time? Do I want to give it to this person?” Maybe that’s just an excuse for me to say, “I’m not interested in spending my time in this way.” Just a couple quick anecdotes. There’s tons of interesting things that we have learned helping people optimize their time with our product.

Joe: Yeah. That’s insanely interesting. I mean, first of all, 10:00 AM is also the sweet spot for me, because from 8:00 to 10:00, I like to do my own thing, in the office. Then by 10:00, the coffee is kicked in, 10:00 or 11:00, because 11:00 is right before lunch. So I’m probably not getting any deep work done. Then, how far in advance do they schedule? I have time-boxed, specifically for this reason. I’m doing a project right now with a bigger company, where they have a culture of this “I’ll grab a time on your calendar.” So people would do that, and I’ve been aggressively guarding my time. If someone just puts a meeting on my calendar, I’m like “I can’t meet at this time. Use this link to figure out when we can meet.” Because 5:00, I’m out of the– I got to go pick my daughter up from daycare. Then the rest of the evening is family time. If you’re going to meet in the middle of my morning, that’s deep work time for me, usually.

Joe: A lot of consultants do this, for example, where if they are working for multiple clients, they’ll block off time in their calendars for each client. One, to make sure that they don’t overbook themselves and two, to make sure that they preserve time to do the things that they’re trying to do for that particular client. It’s actually, I think, a good practice is to block time for things when you make commitments. Whether that commitment is to put together a presentation, or complete a coding task, or to meet with somebody. That’s one of the values of calendars, and if you can make them easier to use and more valuable for people, you can use them in ways to help people spend time better.

Joe: Absolutely. Then, I would just add, commit to that. I say I don’t meet on Fridays. I don’t break that rule. So, if someone’s like “Can, I grab a meeting on Friday?” I’m like, I don’t meet on Fridays, talk to me Monday morning.” Because Friday– Probably contrary to a lot of people feel, Friday is my most productive day, because I don’t have to meet with anybody.

Tim: For Facebook, we had no-meeting Wednesdays. The biggest problem in no-meeting Wednesday is that it was often disregarded by non-technical functions because they would have to meet with people outside of the company, who didn’t have no-meeting Wednesdays. In the counter tool that we built internally, we were able to codify this, so you could at least warn somebody that “You’re scheduling time during no-meeting Wednesday. Do you want to do that?” Inside of Woven, we’ve taken it one step further, where we use templates which are like predefined meetings, and you can set up your templates to say, “When should this meeting occur?” If you didn’t want to have your Fridays booked, you can change the template so that it never proposes times on a Friday and it will never do it for you, and it will never do it for anybody else who tries to schedule time with you.

Joe: Yeah. That’s fantastic, and I love that. When I was at the University of Scranton, we had something similar. We had no-meeting Thursday or something like that, but it was never honored, by anybody. When I was like “I thought we weren’t meeting on Thursdays, this is supposed to be a workday.” They’re like “They’re from outside the department.” I’m like, “They’re not available the rest of the week?” We work from 8:00 to 5:00 every day.

Tim: What you’re highlighting here is a truism. This is something that was important to learn at Facebook, which is that culture is often a function of the tools that you use. The tools can help make sure things happen. Facebook was very much about open communication, and it used Facebook Workplace as a way of helping people communicate because it’s more open than, say, e-mail is. For meetings, we used Exchange. Even though Sheryl Sandberg sent out an e-mail to the entire company, that we are no longer going to have, 60-minute meetings, they are going to be 50-minute meetings. Because Exchange didn’t support that, we ended up having 60-minute meetings. That was– The tool is overpowering one of the most powerful individuals in the company and arguably one of the best leaders in technology. That’s the value or the power of tooling for culture.

Joe: Yeah, that’s incredible. I love that quote. I’m going to make that a pull quote, for this episode. But we are coming up on time. I do need to ask you my favorite question, which is I mean, you’ve given us a lot of really great advice, but do you have any trade secrets for us?

Tim: They’re going to sound not so secret, but they are very powerful. It starts with if you’re going to build a great product, that starts with having great people. One of the things my co-founder and I both learned this from Facebook, and he was at Google beforehand, that part of what made Facebook such an incredible place to work was that people were so amazing. They were the best at what they did. That wasn’t by accident, and the company was very deliberate about hiring. So we’ve been very deliberate about hiring. If I were to go back through my entire career and highlight my greatest successes and my biggest failures, they’ve all related to whether or not I stuck it out for the right person in a role. When I compromised and made shortcuts, it usually cost me. When I stuck to my guns and went for the right person, even if that took a little bit longer than I wanted, it always paid off. So people make a big difference. The second thing I would say, and this is really for startups, speed matters. It’s great to take the time to build something well, but you have to recognize that, as a startup, you don’t know everything. It’s impossible not to know everything. So really, what you’re doing is every bit of code you’re writing is to learn more about what’s going to resonate for your product. When you write that code in a way that allows you to get it in front of users quicker, to get that learning faster, you’re better off than if you take a lot of time to write something that’s perfect, because it’s not going to be perfect. The designs are never going to be perfect. The architecture is never going to be perfect. Even the product focus is never going to be perfect. It’s got to be designed for speed. It’s very relevant learning, for us, on a principle that Facebook had of “move fast and break things.” That moving fast part, especially in the early days of a company, is really valuable.

Joe: The man I love that. That’s been echoed a bit on this podcast, as well, because you could spend six months or a year building something that you think is amazing. Then if people don’t use it the way you expected it to be used, then no one’s going to use it. So then you just sunk a bunch of months into something that’s not usable. So get something out quick, iterate quickly, we have the luxury to do that in today’s development environment.

Tim: Yeah, I mean, one of the other things that we learned is, if there’s ways to test stuff without ever writing a line of code, then you just shaved a bunch of time. You have no tech debt that way, you have no bugs that way, but you get the learnings. Mocks, surveys, we would use ads, sometimes, to advertise for features that we were thinking about developing and we’d see what the click-through rates were. All those were different ways to get to the answer to questions without having to write a line and code. So that when we did write that code, we knew that we had a higher chance of writing the right stuff.

Joe: That’s great. I’m going to steal that one. I’ve done similar things with pre-launching a course. Then if nobody buys the course, I know “Great, I don’t have to write that course. Nobody wants that course or nobody on my current e-mail list, at least, wants that course.”

Tim: That’s a modern-day variant of [Lean Startup]. The whole customer development cycle is built off similar principles.

Joe: Awesome. Tim, thank you so much for your time today. Where can people find you?

Tim: They can find us at Woven.com. The product is in open beta, so the only requirement is that you use your G Suite or Google Calendar. If anybody wants to find me, I’m easy to find on Twitter. @TCampos or Tim@Woven.com. I do also have LinkedIn, and Facebook profiles are easy to find, as well.

Joe: Awesome. I will link to those and everything we talked about in the show notes, over at HowIBuilt.it. Tim, thanks so much for joining me today. I appreciate it.

Tim: Awesome. Thanks for having me.

Joe: Thanks so much to Tim for joining us today. While there’s a lot to take away from this episode, I think what stuck out the most, for me, is how people’s availability and when they meet spikes in the morning, so people are not available before a certain time in the morning, but then it peters off in the afternoon, meaning people continually make themselves available later into the evening. That’s really interesting stuff for me, especially because I pretty aggressively guard my time and my calendar. Thanks so much again to our sponsors Gusto, Ahoy! and Pantheon, they make this show happen. If you want to learn more about Tim and see all of the show notes, you can head over to HowIBuilt.it/140. If you want to create a podcast, just like this, for yourself. Be sure to check out my free podcasting workbook over at HowIBuilt.it/Liftoff, you’ll get checklists and show note templates, and all sorts of other stuff. Thanks so much for listening. Until next time, get out there and build something.