How to Avoid Meetings & Build a Great Remote Culture

What's up, everyone? Welcome back to another episode of Founders 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 Korkos, the co-founder and CEO of Levels, a health tech 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.

Good to be here.

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.

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

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?

Yeah, I think the 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, 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. 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 6 hours just sitting in a chair listening to people talk at 1x speed.

Sounds amazing.

Yeah, it's horrible. And this is a situation a lot of people are in. And async allows you to really lean into what this medium enables. It allows for all information, all meetings, like this meeting here, if you want to call it that, is recorded. It is content. Somebody can watch this 5 years from now at 2.5x and get the same information as if they were here live with us. And you, you can scale that in a way that you, you can't in any other format. So, uh, 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. Uh, if you were to look at the calendars of a lot of our engineers, it is very common for engineers to have something like 3 meetings per week.

Wow.

And they just have Like, it's funny when I see companies who announce something like No Meeting Tuesday or something. And it's like, 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.

Totally.

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. And so—

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

Yeah, I can give— I think maybe I'll give some specific examples and then maybe we can try to extract a principle from that. But one is, say, a project kickoff is 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 we— there's like an emotional resonance of that. moment of like, we're starting this project for the next 8 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 2 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 pull request with, I don't know, 1,000 lines of code changed and it's on a part of the codebase 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 2-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. You say, oh, okay, but I still don't understand. And like, you're 5 days in now on this super high latency back and forth where you're just waiting, you know, 3, 4 hours for each response. So if you need that, I think we, we try to push people If you feel like you should take it sync, just take it sync. But the alternative is defaulting to sync, which is a lot worse.

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 2 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, 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, 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?

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 1 in 60 rule. I forget what it's called, where if you're 1 degree off for a certain— you end up in a completely different country.

Yep.

It's surprising how a very, very tiny difference in direction can compound as you 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 5 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—

Right.

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 that's— if you ever expect there to be more than 1 or 2 back and forth with a person, this is where tools like Slack are really, really bad.

Yeah.

I could nerd out on internal comms all day, but Slack is a It's 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 waiting for 5 minutes for them to get back to you and you're just staring at your phone with the 3 dots going and you're just waiting and waiting. It's the worst of both worlds.

Yeah. I would love to be a fly on the wall as you and Jason Fried just nerd out on that exact concept for 3 hours straight. And I want to talk about kind of your 3 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.

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 a— 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 3 or 4 action items. So we're going to fix this thing, we're going to change this to that. We all agree that we're going to start doing this thing that way. That's 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. 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.

Yeah.

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. The night before, I go through all of them and they all get canceled. 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.

Totally.

And if there is no agenda, there is something to be said for the 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.

It's amazing.

Yeah. Like nobody, nobody wanted these calls, but there's just like 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.

Definitely. Yeah. I think it's similar to like how you said that Slack masquerades as async, but it's really sync. It's like I feel like oftentimes meetings that where like it's get to know you and like chitchat and water cooler talk, is like masquerading as, 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?

Yeah, I would say there's not like a strict rule. We try to limit it to 3 is really the number, but There were absolutely meetings where it's useful to have more. 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 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.

Yeah.

Especially because 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 because 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 Yeah, we used that for a while. Yeah, and it's great. We just have random pairings of people and the agenda is like, hey, get to know you, talk about random stuff, and they're super fun. But whenever you blend those 2, 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 like go into what's going wrong, how we fix things. I think just having a very clear intent on meetings is really important.

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 like 3 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.

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 wireframes without using visuals. It's like trying to explain in words how you would navigate between different pages makes no sense at all.

Yeah, it just doesn't work.

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 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, we're not militant about these things. I think where people sometimes get tripped up is they, when you get the, 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' 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.

Totally. And you referenced this kind of template that you provide employees for writing memos. And of course, 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?

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.

We'll just call it the product spec.

spec. The product spec will have, when you create the template in Notion, it'll say 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? Like, 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.

Yeah.

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 they— we've— We taught them how to do the daily check-ins, how to do— they even write the first draft of most of our retros now because 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 want to 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 100% rollout? Is it a 10% rollout? Is it a split test? It's like, oh, I didn't— I forgot that we do those. That's really useful that we have that as an element of discoverability.

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 kind of highest leverage skills. And something I always think about is just interesting to think about kind of 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 have considered to be the responsibilities of a high leverage or high knowledge worker, like a, a software developer or a product manager, how a lot of that stuff is getting delegated today.

Yeah, for sure. And it's getting more leverage out of people. I think it's— we work with Athena. They're an agency out of 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 an agent. 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, uh, it builds upon itself and, uh, yeah, you can get so much more leverage out of it.

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?

Yeah, I think there's 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— Yeah. What side you would like to default to?

Totally love it, Sam. Thanks for joining the pod.

Sure thing.

I hope you enjoyed this episode of Founders Journal, and if you like 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.