How to Avoid Meetings & Build a Great Remote Culture

Alex: What's up, everyone? Welcome back to another episode of Founder’s Journal. I'm Alex Lieberman, co-founder and executive chairman of Morning Brew. Today I'm talking about how to best manage a remote team and build a culture that is not dependent on meetings. My guest today is Sam Corcos, the co-founder and CEO of Levels, a healthtech company focused on metabolic health using continuous glucose monitors. At Levels, Sam has built a fully remote team with a culture that is defined by very few meetings and a ton of documentation so that info can be shared asynchronously across the organization. If you are someone that is trying to build a great remote or hybrid work culture, or you're just trying to get rid of unnecessary meetings on your calendar, which is basically all of us, this episode is for you. Let's hop into it. Sam, thanks for joining the pod again. 

Sam Corcos: Good to be here. 

Alex: Okay, so we spoke about how you think about your time as a CEO, how you're really methodical about tracking your time and reflecting on the way in which you spend it. Something else that's also interesting about how you run your business and kind of the way that culture at Levels works is it's highly asynchronous versus synchronous. I can't remember who was the quote by that said, “we are as async as possible, but not more.”

Sam Corcos: Yeah, I stole that directly from Matt Mullenweg. That's his quote. 

Alex: Exactly. So I'm always fascinated by this because you know, honestly, just looking even at Morning Brew as a company pre-pandemic that was entirely in person and like a lot of companies, went entirely remote during the pandemic, shifting to a more async culture did not feel natural or easy at all. So can you just talk about the way that communication works in your company? 

Sam Corcos: Yeah, I think one of the conclusions that I've come to, and I'm not the first person to come to this realization, is that being remote successfully probably requires an async culture. Trying to replicate the same synchronous working styles, except not in a meeting, but in Zoom, is soul-crushing in a way that is very hard to explain. Like it just sucks the life out of you sitting in Zoom calls, where you're kind of stuck there and you try to just turn your camera off so you can actually do work, but you hear chirping and words and you can't really be productive and you spent six hours just sitting in a chair listening to people talk at 1x speed.

Alex: Sounds amazing. 

Sam Corcos: Yeah, it's horrible. And this is a situation a lot of people are in. Async allows you to really lean into what this medium enables. It allows for all information, all meetings, like this meeting here, if you wanna call it that, is recorded. It is content. Somebody can watch this five years from now at 2.5x and get the same information as if they were here live with us. And you can scale that in a way that you can't in any other format. So what we've learned is that certain roles are much more suited for async. I think software development roles in particular are extremely well suited for async because you need large blocks of uninterrupted time. If you were to look at the calendars of a lot of our engineers, it is very common for engineers to have something like three meetings per week. 

Alex: Wow. 

Sam Corcos: And they just have, it's funny when I see companies who announce something like, no Meeting Tuesday or something, and for us it's almost exactly the opposite, which is like Meeting Mondays. It's like the only day where people will even have meetings or something along those lines. But I do think that where we've had challenges is that the important point of Matt's quote of as async as possible but not more, is that there are absolutely times when synchronous communication is valuable and useful and important. In fact, in person time, there's a reason why we do offsites and people meet in person. There's a certain degree of high bandwidth, low latency communication that can really only be done synchronously. 

Alex: What are those, outta curiosity, when does synchronous communication make sense? Obviously you talked about offsites, but when else, especially in a digital environment?

Sam Corcos: Yeah, I can give, I think maybe I'll give some specific examples. 

Alex: Yeah, that'd be great. 

Sam Corcos: And then maybe we can try to extract a principle from that. But one is, say a project kickoff, it's something that I personally like to do. Not every project has one of these, but it's like we are officially starting with this group of people on this project, on this timeline and we're all here, we can all answer questions, and there's an emotional resonance of that moment of like, we're starting this project for the next eight weeks, we're gonna be working on this together. Another is daily standups. We default to doing them async. But if you're working on a really high velocity project, just having 30 minutes of sync time in the morning really makes a big impact. And we found for a lot of our projects, people might do two weeks of daily standups that are synchronous, live answer questions, get more context, higher velocity, and then they eventually transition into async standups where at the end of the day they just say, this is what I worked on, if you have any questions, let me know. And so I think other aspects, if we do a lot of our code review live, we default to async, you might record a Loom walking through the code, but if it's a really big poll request with, I dunno, a thousand lines of code changed and it's on a part of the code base that people are unfamiliar with and you need it to get shipped very soon, it's way faster to just say, hey, let's get on a two-hour call and just walk through this line by line so that I don't have to write all my comments of like, Hey, what does this do? And then the next day I write, oh, it does this. They say, oh, okay. But I still don't understand. And like you're five days in now on this super high latency back and forth where you're just waiting, you know, three, four hours for each response. So if you need that, I think we try to push people, you feel like you should take it sync, just take it sync. But the alternative is defaulting to sync, which is a lot worse. 

Alex: Right. I'm just thinking out loud as you talk through these examples, whether it's code reviews or project kickoffs or you know, daily standups. I'm trying to think about what are the reasons that sync would actually be more helpful here? And I'm gonna throw out two ideas and I'm interested to see if you agree or how you'd think about it differently. One thing that stands out to me is kind of urgency where there's high urgency sometimes just to get people to operate asynchronously with high urgency can be difficult, or the probability of that happening could be lower because people are working on their own calendars and calendars haven't been synced. The second thing that comes to mind is high cultural importance. And I don't know how else to say it other than like increased motivation or energy around a project or a goal where there's a level of emphasis and importance, feels like it can, almost like, because you have an async culture, when you have a synchronous meeting, it naturally signals importance. What are your thoughts on that? 

Sam Corcos: I think that makes sense. I would add a third category to it as well, which is there's a degree to which alignment really matters for these things. In the early days of a project, there's a rule in aviation, it's like the one in 60 rule, I forget what it's called, where if you're one degree off for a certain, you end up in a completely different country. It's surprising how a very, very tiny difference in direction can compound as you continue to diverge. And so for early projects when it's really important that people are aligned, and you correct and you get to that point where it's like, okay, I'm now confident that if you spent the next five days in a cave and came out with a deliverable, it would be the deliverable that we need. As opposed to you come back and it's like, what on earth is this? How did you misunderstand so horribly what it is that I thought I was saying, that we ended up in this place where we have to undo all of this and we have to start over? So I think in the early days when alignment is a really critical piece, feedback, constant communication, I think if you ever expect there to be more than one or two back and forth with a person, this is where tools like Slack are really, really bad. I could nerd out on internal comms all day, but Slack is a synchronous tool that masquerades as an async tool. And so you end up getting into these multi-hour conversations with your thumbs where you're like waiting for five minutes for them to get back to you and you're just staring at your phone with the three dots going and you're just waiting and waiting. It's like the worst of both worlds. 

Alex: Yeah. I'd love to be a fly on a wall as you and like Jason just nerd out on that exact concept for three hours straight. And I want to talk about your three processes for async, but just on meetings for a second. So we've talked about kind of like what are the situations in which having synchronous meetings makes sense to you? What is a good meeting? How do you actually have a good meeting? Because knowing when to have one is important, but also most people are really bad at running meetings. 

Sam Corcos: Yeah, I think we'll specify meetings that are internal to the organization because that tends to be the most soul-crushing of the types of meetings that people have in general. There should be an action item at the end, often several. So I would say that is more of an artifact of a good meeting, is we had some…we had an hour and a half meeting today with our eng team discussing a number of things around how we do documentation, a number of processes, and we ended with three or four action items. So we're gonna fix this thing, we're gonna change this to that. We all agree that we're gonna start doing this thing that way. That's, I think, a good form of recognition of when a meeting was successful is if you have a series of action items. I think every meeting should have an agenda. And I'm pretty militant about this if I have one-on-ones scheduled for all of my direct reports. But I've made it very clear and everyone's on the same page that a one-on-one calendar hold is not an entitlement. It is a hold so that I don't double book myself. And if there's nothing on the agenda in the Notion doc that we share, then the meeting gets canceled. No question. Like the night before I go through all of 'em and they all get canceled. It actually, that process is handled by my EAs. They actually go through themselves and they cancel it for me. But it's the same idea; they go through, they cancel all these things and if there is no agenda, there is something to be said for just being friends with somebody, get to know you types of conversations. And I think if you're intentional about it and that's your goal, that's great.

There's a hilarious Seinfeld episode where George Costanza is talking to Jerry about how he dreads these Saturday calls that he has with his parents and he has to do it every week. And the whole episode is about how much he dreads these calls and then you cut away to the phone ringing at his parents' house and they're like, oh no, another one of these calls. 

Alex: It's amazing. 

Sam Corcos: Yeah. And like nobody wanted these calls, but there's just a sense of obligation on both sides and nobody is able to have that conversation. So I think just being really direct about the intent is really important. 

Alex: Definitely. Yeah. I think it's similar to how you said that Slack masquerades as async, but it's really sync. It's like, I feel like oftentimes meetings where it's get to know you and like chitchat and water cooler talk is masquerading as one of those talks, when it really should have been a more structured talk that actually had an outcome and an agenda. And one last question on meetings is, do you have a cutoff on number of people to have in a meeting? Do you think like once you get to a certain number, just ever the marginal benefit continues to go down? 

Sam Corcos: Yeah, I would say there's not a strict rule. We try to limit it to three, is really the number. But there were absolutely meetings where it's useful to have more like, we have a weekly, the whole engineering team meets once a week to go over anything relevant to the whole org. And right now our engineering team's only 10 people, so it's not a huge meeting, but these things can become really onerous. I have a friend who runs a larger company than I do. And the problem is once somebody gets invited to like the exec meeting, it's really hard to then uninvite them. They feel like they've been demoted by not being invited. And it's just weird to me because if somebody told me I don't have to go to a meeting, I'm thrilled, especially 'cause I know I can always watch the recording later, but there is a pull to being in the meeting where these things are happening. I think it becomes less important as people get used to our culture, 'cause all of our meetings, including our one-on-ones, are recorded and shared by default to the whole company. So our board meetings, generally speaking, are shared with the whole company and so people can see what we're talking about. It's not a secret. So people don't feel like they need to be there necessarily because they can still see what's being discussed. 

So I would also add that we do have water cooler chitchat conversations. We do, I think we call them donut chats, which is modeled after one of these Slack companies. 

Alex: Yeah, we used that for a while. 

Sam Corcos: Yeah. And it's great. We just have like random pairings of people and the agenda is like, hey, get to know you, talk about random stuff, and they're super fun. But we don't, whenever you blend those two, it's like on our Friday forums, we announce at the beginning we are here to celebrate wins. We're not here to criticize, we're not here to do any of this other stuff. That's our other meeting, that's Monday metrics, where that's where we talk about numbers, where we go into what's going wrong, how we fix things. I think just having a very clear intent on meetings is really important.

Alex: Yeah, totally. Just sounds like you're very intentional about setting expectations of what the meeting is and what it isn't. We've talked about synchronous, I want to talk about asynchronous now. So you've talked about, you have three processes that suit async and one of the big ones is memos. Like you have a huge memo culture. So I'd love to start with, what are the different forms of async communication that people use at Levels, and then talk about where memos come into play. 

Sam Corcos: Yeah, I think part of the answer is that the medium matters based on the kind of message that you're trying to communicate. And so strategy almost always needs to be in writing. In fact, I can't think of a single example where strategy was not defined in writing daily updates. Some things are really only able to be communicated visually. I don't know if you ever tried to communicate what an app spec would look like via wire frames without using visuals? It's like trying to explain in words how you would navigate between different pages. Makes no sense. 

Alex: Yeah. Just doesn't work. 

Sam Corcos: No. So you have to use the appropriate medium. So if you're doing a code walkthrough, people need to be able to see the code, and they need to be able to see what you're looking at and hovering over and and selecting. So Loom is a tool that we use pretty religiously. I would say that we use Notion for all of our documentation and one of the things that people, it tends to take some getting used to, is recognizing that the amount of effort that you put into a memo and a strategy memo or whatever it ends up being, should be roughly proportionate to the importance of the decision. And so we're not militant about these things. I think where people sometimes get tripped up is when you get the full long template of a memo, they feel like, oh man, I have to fill out every one of these sections. And you know, this is not a TPS report. These are there to help you make better decisions. They're not there to force you to do unnecessary work. So I think where especially people from larger companies tend to get tripped up on this stuff is at larger companies you have to follow the process for process’s sake. But at our company, and I think really at all companies, the way it should be is the process is supposed to help you. Which is a weird thing for people to hear. They're so used to the process being the thing they're fighting against to get any of their work done, that it just really should not be the case.

Alex: Totally. And you referenced this kind of template that you provide employees for writing memos and of course there's, I would assume there's a level of flexibility to it. Like you said, you're not militant about it, but roughly speaking, what is that template? What are the general guidelines for writing a good memo? 

Sam Corcos: So I can give maybe a very tangible example. 'Cause this is a memo that's commonly written is we write memos for all of our product specs. It's a very, I think the acronym that people use is PRD. I'm very bad at remembering what acronyms are, but we also have a no acronym rule 'cause I can't remember them for the life of me. 

Alex: We'll just call it the product spec.

Sam Corcos: Yeah, the product spec. We'll have, when you create the template in Notion, it'll say, you know, hypothesis generation, success criteria, it'll have 20 different sections for you to think through. But if it's not relevant for your project, you just delete that section. And so figuring out what are good prompts to get people to think, oh, you know what, who are the stakeholders of this project? It's like, oh right, of course I should loop in this person and that person and this person. And then we actually added another process, which has been really helpful, is my experience working in software for as long as I have is that oftentimes product managers are really underutilized in terms of the high leverage skills that they have. A lot of product managers end up spending their time shuffling tickets and scheduling things and they're doing admin work and that might be half of the time that they spend. And so we've been working with our EAs in the Philippines to do a lot of that admin work. And so we taught them how to do the daily check-ins, how to even write the first draft of most of our retros now 'cause they can see all the daily updates. And so they're able to do a lot of the ticket shuffling admin work. And so figuring out how to get as much leverage out of people as possible. 

And so tying this back to the template for memos is that you wanna remind people, I would describe it as an exercise in discoverability. If you've never written a memo before, you might not know that this process is available to you, that you have these resources or that, you know, having a deployment strategy is something that we talk about. It's like, is this a hundred percent rollout? Is it a 10% rollout? Is it a split test? I forgot that we do those. That's really useful that we have that as an element of discoverability. 

Alex: Yeah, it's super interesting. And it's also interesting to think about, and this could be a whole ‘nother conversation, but obviously you're very pro delegation and having people work on their highest leverage skills, and something I always think about, it's just interesting to think about the companies of tomorrow, if they're built on this foundation of delegation and automation, how much more effective and efficient are those companies? So it's really cool to hear that you're using that even for tasks that I think people would've considered to be the responsibilities of a high leverage or high knowledge worker like a software developer or a product manager. How a lot of that stuff is getting delegated today. 

Sam Corcos: Yeah, for sure. And it's getting more leverage out of people. I think it's, we work with Athena, they're an agency outta the Philippines and when you compare the cost of an EA in the Philippines relative to the cost of an engineer in the US, it's night and day. If they can pull 15%, 20% of the work that an engineer would have to do, that sort of toil of updating documentation and doing that sort of thing, you get so much more leverage out of them and being able to train them, especially if you work with, there's a whole bunch of agencies that do a good job of helping you spread this knowledge across the entire org so that you don't have to individually train each of them on these processes. It sort of, it builds upon itself and you can get so much more leverage out of it. 

Alex: Any other final thoughts or lessons you have from a high quality async culture that you've learned from just building it with Levels that you wanna share? 

Sam Corcos: Yeah, I think there is a degree to which people do need in-person time with other humans. And so accepting that and building into your culture some way for people to interact is really important. I would say that other things that we've learned is that I'm pretty confident there is no such thing as the perfect balance between too much sync and too much async. And so the question is really, what systems do you have in place and what is the direction of entropy is how I would describe it. Is it towards more and more and more meetings, where by the end of the year you have 30 hours a week of meetings and you're just trapped in Zoom hell? Or is it, we don't have enough meetings and I feel disconnected from my team and I feel bad in that direction? It's way easier to correct for we don't have enough meetings, let's try to schedule more of them, than it is, how do I get out of this situation where I'm trapped all day in meetings? So this is a pretty regular cycle. I would say we go through it maybe once a quarter where people feel like we don't have enough meetings, which people who are at other companies might find that absurd that we have that as a problem. But every so often we say, hey, we need to do more synchronous time, we need to have more meetings. And so there's never gonna be the perfect balance. You just have to figure out what side you would like to default to. 

Alex: Totally. Love it. Sam, thanks for joining the pod. 

Sam Corcos: Sure thing. 

Alex: I hope you enjoyed this episode of Founder’s Journal, and if you liked this celeb shot format where I curate badass entrepreneurial guests, shoot me an email to alex@morningbrew.com to suggest a future question or challenge you want answered or a specific expert you would love to see come on the podcast. As always, thank you for listening and I'll catch you next episode.