Solving synchronicity with asynchronous communication (Sam Corcos, Andrew Conner & Scott Klein)

When is communication necessary, and when does it detract from the workday? As a rapidly growing asynchronous company, this is a very important question at Levels when it comes to culture, new employee onboarding, and expectations. In this episode, Levels CEO Sam Corcos sits down with Head of Product, Scott Klein, and Head of Engineering, Andrew Conner. They discuss the current daily challenges faced at Levels, and brainstorm ideas to further streamline asynchronous communication.

8:28 – Solving the puzzle of effective communication

Sam says that he is focused on keeping the company fully asynchronous, leaving time for deep work, and minimizing “project debt.”

How do we solve the last five or 10% of communication gap without also risking breaking the 90% that is working? And this is a concern. I was talking with David Sinclair about this. He has this issue where his email was getting really overwhelmed. So, he started pushing everyone to text messaging, and now it’s just worse. And how it’s just completely unthreaded. It’s expected to be synchronous, and now is just worse. So, I can very much see that happening. Some of this, I think, comes from the cultural expectation, which I was talking with Josh about earlier today around I’m going to put some more documentation together on this, on the idea of Project Debt, and making sure that we really do prioritize communication. Because once that starts to slip, especially for people in leadership, it can really have detrimental effects on the rest of the company.

11:31 – The need for instant communication is rare

Andrew says that he almost never finds himself needing on-the-spot communication with team members.

It’s pretty rare I need someone’s response within an hour. It’s pretty darn rare. And in that case, I’m pretty comfortable breaking into, I guess more personal communication mechanisms. But I think, to me, that is exceedingly rare. And we use Signal now, I think more than we could. We could actually reduce it, because but that’s the one way that I know, if I message you, you’ll see it before Threads. Threads is 24 hour SLA, I know that if I messaged you on Signal will be a little bit faster. And so, I think we’re just looking for this in between space, that we may be enforced with very strong cultural norms.

12:58 – Setting guidelines for communication tools

Scott says that clear guidance is needed on what company “defaults” are when it comes to communication.

I’m trying to assess out, say, if we could come up with a framework for tool usage. Because I think that there’s two things from it. They’re sort of defaults and there’s sort of permission. What are we going to sort of paternalistically tell you, “This is what your default is going to be. Part of onboarding is, we’re going to set up your Slack.” And we’re going to say, “Turn off the unread notifications and turn off all push notifications.” It’s just off, off, off, so that you should be able to close the app and there’s no harm done. And then I think there’s also permission in the sense of, what should you as an employee, absolutely feel free to just ignore for up to 24 hours or something like that? It seems like we’re carving out text messages as if you get a text, you need to respond to it. Those should be used absolutely sparingly. In the five minutes I have been here, say, you text me one time. So, that’s fine. And then everything else you should, that to me is sort of like the nugget of asynchronicity is, what do you feel you can shut completely off and never feel bad about.

16:28 – Fighting the pull of synchronicity

Scott says that staying async will require onboarding and also flexibility for various team.

I’m still feeling that you’re wanting to exclude Slack if we can, because there’s this worry about it. The entropy tending toward synchronicity. So, I don’t know if there’s more that you want to say there. I just think I guess a leadership team, the focus should be sort of on the principles and the default sort of set of onboarding and defaults and whatever else that we do. That’s the stuff that we can control. And I think that, look, if the dev team decide to adopt Slack for a little chitter chatter, as long as it’s not taking them out of flow, we’re going to lose a bunch of goodwill on the back end, if we remove the tool specifically, if they feel like they can be using it well.

20:13 – Deprogramming new employees

Scott says that many professionals need to be reset when coming from a synchronous work environment to an asynchronous one like Levels.

I like the phrase deprogramming because I think there is such a jarring experience coming into an async remote thing. And we kind of need you to commit to, let’s do the cleanse, detox, whatever you want to call it. And we’ll call in six weeks. So maybe, you don’t even get access to Slack until six weeks have gone by. And you sort of get the feel of the Notion of and then you can like sort of ease into it. I think that makes sense. I think what you’re concerned about, and I think rightly so because I do share this concern is, at some point, the company will probably be growing, where it’s going to be impossible, the rate at which we have cultural reinforcement is going to be slower than the rate that people are joining the company. And in that case, things will get out of whack very quickly.

21:56 – Battling compulsive behaviors

Sam says that it’s easy to get lured by the dopamine rush of Slack and social media.

I’m not perfect at this. I still suffer from the same compulsive behavior. I just add friction, so that now it takes me 10 extra seconds. And in that time, that dopamine hit has dissipated and then I don’t do it. And though, Twitter and Slack were my two dopamine pathways that I had as my website blockers. I don’t have Threads as a block website. There’s probably a reason for that. I just don’t feel the need to compulsively check it. Same with email. I have Mailman on and I get email twice a day. I don’t really need to constantly check it for new dopamine hits. So, I’m really cognizant of, it’s like I’m mindful that it is really dangerous to introduce inherently pathological tools into the organization.

25:33 – Don’t introduce friction

Scott says that it’s important to not introduce friction and resentment in the quest to streamline communication tools and best practices.

Because I came from dev is, I want us to be very sensitive to folks that are in the blocking and tackling of the day-to-day stuff. Justin and Steph are working very closely right now on table stakes. At some point, if we introduce those frictions, they’re going to feel not heard and they’re going to feel pissed off that we’re introducing friction where they otherwise don’t need it. I think that there’s a custodianship that we have to choose the right tools and defaults. But their job is way different than ours is right now. We’re spending a lot of different time than they are, and I don’t want it to be, it’s going to come off as sort of ivory tower a bit if we are forcing stuff that’s going to annoy them into their job.

31:30 – Leave opportunity for time-sensitive updates

Andrews says his main concern is providing access to instant communication when needed. Finding the right communication mix may mean conducting monitoring and testing.

In terms of my own priorities here, some of them are just annoying. Like as in Ben was 15 minutes late to a meeting. He didn’t effectively have a way to let me know. I didn’t know when I waited around. Okay, it’s annoying, right? We are bad at engineering outages right now. It’s like Threads just a bad model, because things go out of sync and you can’t just leave it open and get updates effectively and stuff like that. That’s the one I’m feeling pressure to solve first. I feel very optimistic that do a hard reset did reset the norms. And if we get very clear, what is the use case? That kind of stuff. And then maybe just keep track of it. Maybe monthly Miz runs that report of messages. In that way, it’s like an integration test. And if you notice, I think last year, there was a month I sent like a thousand DMs or something like that. And if you notice, “Andrew sending a thousand DMs.” That’s a really good 200 DMs. That’s a good time to be like, “Hey, Andrew, what’s up? What are you doing? Is there something we need?” Almost like a wake up kind of thing. And maybe just like every manager for their team just keeps an eye on it.

32:49 – The problem of channels and forums

Andrew says the most frustrating moments are where communication doesn’t include clear action items or loops you into never-ending updates that don’t apply to you.

The more I think about it, I like the idea of removing the channels, because channels are away that has this undefined priority for potentially a large group of people. I think if there’s an incident, cool. Create a channel, and that way we can link to the incident. But the incident ends and then the channel dies. It should be archived or something like that. If I think they’re my own stresses, it’s never, especially recently at the current volumes. It’s not DMs that stresses me at all about Slack. It was previously where, there was a message in the design channel. Is that something I need to read? Do I need to click through this? I don’t know. And Thread solves this five times better or 10 times better than Slack did because it makes it very clear. And we’re trained. People tag me and I am into the point now where I don’t read everything in Thread. As in I perpetually have unread forums and I’m not going to catch up. If you don’t tag me, I might not see it. Just tag me. If you need me tag me. And I think, people have been pissed at me.

49:20 – Employee bonding is important

Scott made the point that while communication is distracting, it’s also a primary vehicle for employee bonding.

My biggest concern coming into Levels was that it was going to feel very alone. And I think we had a fairly active social presence around WaterCooler and whatever else. So, I don’t know if there’s a way to keep that around. Discord seems very like it’s kind of like a game or tool. It hasn’t gotten nearly the adoption because I don’t think it has the same like kind of work feel to it. I just want to call out that there’s one thing about people coming into a company wanting to make progress and wanting to deprogram a little bit of that nervous system stuff. There’s a little bit of belonging that I think is a separate issue that Slack, at least for me did fill the gap tremendously. I was really, really enthused at how much people were sort of chit chat. And if I wanted to engage in that, and felt the pressure to do so, but I knew it was there. And it’s how I got to meet and know a lot of the people here. So just call it like, we have a huge blind spot. Because the three of us have been here for a while. Even me being here for five months is enough. But those first couple months are key. And I don’t know how we solve for the meet your people and spend time with them and get to know folks in your team.

Sam Corcos (00:00:00):

I don’t think that all rules are paternalistic. I think paternalism is when you have a rule, which is more like doing it for your own good. Requiring that everyone at the company exercise for 30 minutes a day is clearly paternalistic or organizing mandatory play dates for everyone on the team. The afterwork drinks equivalent feels paternalistic to me. But I don’t think that setting norms around communication, and this is maybe something that’s just not entirely crystallized for me. But telling people not to respond to email on weekends feels paternalistic.

Sam Corcos (00:00:50):

However, having people who install an app like Mailman, and setting maybe the default for just the first month of onboarding, to just say, this is default behavior. We have to deprogram the way that you’ve been working historically, to just get used to this. This is what asynchronous means, just do it for the first month and see how it feels, and then you can change it to whatever you want. There’s a lot of deprogramming that we have to do, where the defaults and the norms might take some time to change with people.

Ben Grynol (00:01:24):

Here at Levels, we’re building tech that helps people to understand their metabolic health. And this is your front row seat to everything we do. This is a whole new level.

Sam Corcos (00:01:46):

I’ll start from organizational level concerns is, I’m reluctant to add InstaMessaging in any of its many incarnations into the workflow for several reasons. One is that, it’s communication, if left to its own devices, becomes synchronous. And there are certain norms that is less about how it affects the individual and how it affects other people downstream. So, mis mentioned this as a source of concern and frustration that he had previously, when we were primarily Slack where he wanted to be asynchronous.

Sam Corcos (00:02:34):

But if he would do asynchronous deep work, and then he would come check Slack, many conversations had gone through an entire cycle of decision making, while he was working and he missed the entire thing. And then there’s, because it’s not quantized in that Firehose for eight different subjects that he can no longer keep track of and it created a lot of anxiety. And so, to solve that, he had to get push notifications for everything, which then turn it into playing Whac A Mole with slot communication.

Sam Corcos (00:03:06):

And so, my concern about any sort of instant messaging tool like that type of Firehose is that it gets even called a slippery slope, but it starts to trend towards that direction. So, in many ways, I’m okay over indexing on asynchronicity. Like, I think I was talking with Ben about this, maybe it was JM. I think it was JM. There was a project that needed synchronous communication and it was a little bit clunky, because he didn’t have everyone’s phone numbers and he had to find that and they had to text them. And there wasn’t a way to do them all in a group.

Sam Corcos (00:03:46):

So, it was just sort of managing synchronous things by text message and it was kind of clunky. In some ways, that’s obviously not optimal. But the tradeoff is, of course, the risk that synchronous culture, and we all agree we want to avoid meeting culture. And we want to, just as a company, culture and values we want to do, especially workplace communication, not to be the source of anxiety in your life. And playing Slack Whack-a-Mole, is that anxiety.

Sam Corcos (00:04:20):

So, how do we solve for synchronicity without introducing, it’s like, I don’t want to overstate it, but existential cultural risk, that all of our communication is sort of forced into trending in that direction. That’s the sort of the framing of what I’m thinking about.

Scott Klein (00:04:38):

I think the thrust of my comments were largely that I think that there is a place and a tone for setting sort of we get to choose the tools that people are going to use in a way. There’s a paternalism that’s already going on. And I think we’re sort of, it’s about a degree of how paternalistic do we want to be about telling people what they can to use, even if it’s maybe working for them. So, I’m in this interesting spot where I came in as a developer. A lot of my onboarding was, I was asking for help for people in the code base, a lot of that was done via Slack. I didn’t feel it was too disruptive.

Scott Klein (00:05:22):

And then, I’m now in a mode where I’m doing a lot more knowledge work. That’s not I guess, not coding work, I guess you could say. And so, I’m tending to use a lot more Threads and Notion and whatever else. So, I’m interested for us to define kind of for any tool, it seems there’s more of a definition here of, for any tool that we’re considering, what is sort of permissible? Because we could have everybody crank all of their notifications on Threads app and require it to be on their mobile device, in which case it would function like a dumb synchronous tool.

Scott Klein (00:05:54):

So, I don’t know that it’s actually the Slack tool in particular or any tool in general, that’s InstaMessaging. I just want to find, I think some of the developers are actually using Slack in a fairly effective way that is not too cumbersome and that they could just shut off. And the expectation is that they can just shut off whatever they want. And I don’t know that getting rid of that is going to actually be a net benefits, if we can control it. So, I guess the question in my mind is, “Do we have enough of a cultural stronghold now that any new person that joins the company, the first time they accidentally ask for something in Slack, that there’s a quick correction that says, I need you to put this in Threads.

Andrew Conner (00:06:34):

That’s actually something, I think, Mrs. Feedback is very good in that there was a time that if you fell behind, and this existed inside of email too. Where it’s like, email threads were going really fast and then decision made, and half the email thread recipients hadn’t had a chance to go through it, right? And so, I think, this can happen agnostic to tools. I think Threads was the right pressure release valve for, we’ll call it 90% of this kind of work. So, I think the combination of Notion plus Threads is indeed solving a real problem we have and is strictly better than what we had before.

Andrew Conner (00:07:16):

So, I think we would do good to focus on this last 10%. And acknowledging that Mrs. Use Case is legit, but is not currently happening now. Because we have the norms that I think we do have sufficient weight where we can tell people how to use their tools and say, and I’m not saying we use I mean, this could even be your proposal for SMS. And we say, don’t text people, unless you’re intentionally trying to disrupt them or something like that.

Andrew Conner (00:07:50):

And so, no matter the tool, you still have the norms. And so yeah, I don’t know if that helps at all. We don’t have to solve for Mrs. Problem. I think Mrs. Problem is solved for and it should be, maybe we even say you should have a text expander snippet that says, “Can we take this to Threads?” Or something, like, make it so fast, where I can just, key combination to Threads, and I promise I’ll see it shortly kind of thing. And I think, this last 10% is currently hurting us.

Sam Corcos (00:08:24):

Yeah, I think that’s exactly a correct diagnosis, which is how do we solve the last five or 10% of communication gap without also risking breaking the 90% that is working? And this is a concern. I was talking with David Sinclair about this. He has this issue where his email was getting really overwhelmed. So, he started pushing everyone to text messaging, and now it’s just worse. And how it’s just completely unthreaded. It’s expected to be synchronous, and now is just worse. So, I can very much see that happening. Some of this, I think, comes from the cultural expectation, which I was talking with Josh about earlier today around I’m going to put some more documentation together on this, on the idea of Project Debt, and making sure that we really do prioritize communication.

Sam Corcos (00:09:26):

Because once that starts to slip, especially for people in leadership, it can really have detrimental effects on the rest of the company. So, it’s something that is in most companies not high priority. So, making sure that we make that a priority is important. And the 90% is, I think it is working quite well, Threads plus Notion. So, Threads for the communication and the back and forth and Notion for the long form thought. It does seem to be working quite well for this deeper work.

Sam Corcos (00:10:01):

One of the challenges that I have with the, we call these hybrid intermediate tools. Yeah, I think maybe separating it from the tool and talking about functionality there. There are push notifications and there are not push notifications. And whether that push notification has Threads, whether it is Slack, whether it’s text message, that is the interruption, does it interrupt somebody or not? And I think the challenge is that, and this is my own personal experience with Slack is that, it is an interruption. Slack is something that you get interrupted for. And then you could say like, “Well, you could just turn it off,” and then not get interrupted. But then what about times when you need to be interrupted? That does happen. Somebody needs your response within the next hour. It’s like, “Oh, but I have it turned off now.” Then what? Well then, do you text them? I don’t know.

Andrew Conner (00:10:59):

In that case, you would. I think, there is a natural escalation path, where I mean, you call me. Just like out of the blue and I call you, hoping to catch you at the right time or something like that. I think that’s fine for anything. For example, for an engineer outage, pager duty will have the ability to cause someone’s phone to go bonkers, right? And so, that’s handled. It’s pretty rare. I need someone’s response within an hour. It’s pretty darn rare. And in that case, I’m pretty comfortable breaking into, I guess more personal communication mechanisms. But I think, to me, that is exceedingly rare. And we use Signal now, I think more than we could.

Andrew Conner (00:11:54):

We could actually reduce it, because but that’s the one way that I know, if I message you, you’ll see it before Threads. Threads is 24 hour SLA, I know that if I messaged you on Signal will be a little bit faster. And so, I think we’re just looking for this in between space, that we may be enforced with very strong cultural norms. Maybe it’s even things like DMs and Firehose only. We remove the channels, right? And that way, there’s no natural, if we have this culture of doing things in the open, how would I loop in other people?

Andrew Conner (00:12:30):

And then, anyway, what’s nice is Slack DMs are clunky enough, where it’s difficult. Let’s say, Scott messaged me. And I’m like, “Oh, Helena would know the answer. Let’s add her.” There’s no way to do it, right? And so, what’s nice is there’s a natural way of, “Okay, this should be in Threads.” Or breaking out of whatever this in between zone is, if that makes sense at all.

Sam Corcos (00:12:54):

Yeah.

Scott Klein (00:12:58):

I’m trying to assess out, say, if we could come up with a framework for tool usage. Because I think that there’s two things from it. They’re sort of defaults and there’s sort of permission. What are we going to sort of paternalistically tell you, “This is what your default is going to be. Part of onboarding is, we’re going to set up your Slack.” And we’re going to say, “Turn off the unread notifications and turn off all push notifications. It’s just off, off, off, so that you should be able to close the app and there’s no harm done.” And then I think there’s also permission in the sense of, what should you as an employee, absolutely feel free to just ignore for up to 24 hours or something like that?

Scott Klein (00:13:33):

It seems like we’re carving out text messages as if you get a text, you need to respond to it. Those should be used absolutely sparingly. In the five minutes I have been here, say, you text me one time. So, that’s fine. And then everything else you should, that to me is sort of like the nugget of asynchronicity is, what do you feel you can shut completely off and never feel bad about, right?

Scott Klein (00:13:56):

And I if we can put any tool in that bucket, I think that that’s fine, right? Because I still have Slack on but everything is turned way down on it. So, I have to check in on it. But I don’t even use it for anything anymore. So, it’s like, what does it matter?

Sam Corcos (00:14:10):

Yeah, I think actually, it might be worth going up a level in terms of values. I wonder, related to the question of paternalism. I don’t think that all rules are paternalistic. I think paternalism is when you have a rule, which is more like doing it for your own good, requiring that everyone at the company exercise for 30 minutes a day is like clearly paternalistic or organizing mandatory playdates for everyone on the team. The afterwork drinks equivalent feels paternalistic to me, but I don’t think that setting norms around communication, and this is maybe something that’s it’s not entirely crystallized for me, but telling people not to respond to email on weekends, feels paternalistic.

Sam Corcos (00:15:04):

However, having people who install an app like Mailman, and setting maybe the default for just the first month of onboarding, to just say, this is default behavior, we have to deprogram the way that you’ve been working historically, to just get used to this. This is what asynchronous means. Just do it for the first month, see how it feels. And then you can change it to whatever you want. I think there’s a lot of deprogramming that we have to do, where the defaults and the norms might take some time to change with people.

Andrew Conner (00:15:38):

Yeah, I think all that’s fine. I mean, I think that there’s the book Nudge calls this libertarian paternalism. It’s like, we eventually give you a mode to use it on your own. So, in the case of Slack, maybe it’s like, “Hey, we just don’t get you an invite as part of onboarding. And then, “Oh, if you discover that you actually need to use it, you have to go through Miz to get onboarded onto it, so that he has you turn your notifications down and whatever else. And then, if you still want to use it, that’s fine. And we’ve got some cultural reinforcement around it.

Andrew Conner (00:16:10):

Helena just did this to me. I asked her to do her areas of responsibility and she Slacked it to me. And I could have just reviewed it in three minutes, but I purposely told her please put this into threads just so that it got built in and it was totally fine.

Sam Corcos (00:16:23):

Yeah. Yeah, I understand.

Scott Klein (00:16:26):

How do you say, maybe I’m still feeling that you’re wanting to exclude Slack if we can, because there’s this worry about it. The entropy tending toward synchronicity. So, I don’t know if there’s more that you want to say there. I just think I guess a leadership team, the focus should be sort of on the principles and the default sort of set of onboarding and defaults and whatever else that we do. That’s the stuff that we can control. And I think that, look, if the dev team decide to adopt Slack for a little chitter chatter, as long as it’s not taking them out of flow, we’re going to lose a bunch of goodwill on the back end, if we remove the tool specifically, if they feel like they can be using it well.

Sam Corcos (00:17:10):

Yeah, I wonder, the entropy point, the fact that Helena felt the path of least resistance is Slack, which is the case for most people coming from any other company is send it on Slack. Part of it is because you get that immediate dopamine reward. They got it quickly, and maybe they responded to it quickly. And so, in some ways, it makes the case for why it is such a dangerous tool is that it by its existence, it will become the default, and now we’re fighting the tide. We can, with really good culture fight it. Where like, if you’re in leadership, and somebody comes from a different culture, we have to fight this.

Sam Corcos (00:17:58):

And when things get put on Slack, we have to tell them to move it to Threads, and we’d have to constantly fight that. Or we can do something else, which is we can not have that and then we can add friction for synchronous, where it’s like, sending it by text is cumbersome and annoying, so you’re less likely to do it. This is hypothetically, that’s the principle that I’m thinking about. It’s how do you remove friction for good processes? How do you add friction for bad processes?

Andrew Conner (00:18:29):

I agree with that. I think you’re saying, we already have this fight. The default that every software engineer will come into is a meeting-centric planning and things like that. And Scott and I were just like working through, we want to have a product planning process that is maybe 80-90% async. That’s going to be foreign for most people. I think we’re doing this already. Really clear messaging, really clear best practices. And then, people emulate what they see. If no one is messaging them on Slack, I agree with you, it is something that we have to keep a close eye on.

Andrew Conner (00:19:12):

I was smirking because my market-based answer to this is charge everyone 10 cents for every Slack message. But yeah, I’m not actually advocating for that. But yeah, I think this is doable, because we already have to do it. There’s already going to be a lot of momentum. And especially, I’m thinking through engineering leaders coming in. We’re very opinionated how they should run their teams. And even if you have someone who’s highly technical and very empathetic and everything else we’re looking for, we’re also going to be, I don’t want to see a recurring meeting with your team. You don’t need to be doing stand ups or anything like that. So, I don’t know. It doesn’t scare me maybe as much as it does you because I see these already existing and us needing really good documentation and norms to build a fight against it.

Scott Klein (00:20:07):

So just to say really quick, Sam, really quick, two things. I like the phrase deprogramming because I think there is such a jarring experience coming into an async remote thing. And we kind of need you to commit to, let’s do the cleanse, detox, whatever you want to call it. And we’ll call in six weeks. So maybe, you don’t even get access to Slack until six weeks have gone by. And you sort of get the feel of the Notion of and then you can like sort of ease into it. I think that makes sense. I think what you’re concerned about, and I think rightly so because I do share this concern is, at some point, the company will probably be growing, where it’s going to be impossible, the rate at which we have cultural reinforcement is going to be slower than the rate that people are joining the company. And in that case, things will get out of whack very quickly.

Scott Klein (00:20:53):

So, I think that it’s good to think about, at some point, this sort of person to person small correction around stuff like, “Hey, please send me this in Threads instead of Slack,” will not be enough to keep up with the amount of new people joining the company assuming we’re successful. So, I like the idea of detox, because it doesn’t matter our rate of growth at that point. Everybody’s going to go through the six-week detox, and I think they’ll start to understand at least, you will be forcing them into that way of doing it for at least a little bit of time.

Sam Corcos (00:21:21):

Yeah, I’m open to, I’m open to figuring out some way of using these tools, but ensuring that there is friction. I do this for myself, personally. I have website blockers when I’m trying to stay focused. I’ve recorded some of my workflows, like when I’m writing a strategy doc. And I think it was Tom was saying how he was laughing how many times I would open up Twitter, and it would say “Blah.”

Scott Klein (00:21:54):

Yeah, yeah. It’s the same thing.

Sam Corcos (00:21:56):

Yeah. I’m not perfect at this. I still suffer from the same compulsive behavior. I just add friction, so that now it takes me 10 extra seconds. And in that time, that dopamine hit has dissipated and then I don’t do it. And though, Twitter and Slack were my two dopamine pathways that I had as my website blockers. I don’t have Threads as a block website. There’s probably a reason for that. I just don’t feel the need to compulsively check it. Same with email. I have Mailman on and I get email twice a day. I don’t really need to constantly check it for new dopamine hits. So, I’m really cognizant of, it’s like I’m mindful that it is really dangerous to introduce inherently pathological tools into the organization.

Sam Corcos (00:22:51):

A tool that creates compulsive behavior, this is a lot of the conversations I’ve had with the CEO of Threads, which I think I’ve shared on Threads. Talking them about how if we are really going to commit to using Threads, I want more features that align with our values around communication. And fewer of these like, “Somebody read your message, somebody did this, somebody did that.” I want fewer notifications. I want fewer of those types of slot machine behaviors. So that’s my concern is, does adding a slot machine that if left to its own devices will create hurry and compulsive behavior. Is that something that we want to introduce into the organization?

Scott Klein (00:23:43):

Yeah, I hear you there. I just don’t know. I don’t think that is, I definitely don’t seem that’s particular to Slack. So, I think we need to solve it in the general case. Because we got to tune down notifications for Notion and Threads, just like we do for Slack.

Sam Corcos (00:23:59):

Yeah, what’s nice is that Threads is adding, largely because of our recommendations, they’re adding a lot more controls on notifications, both on the individual and the admin level. So, we will be able to configure on an organizational setting the, no more push notifications for somebody read your post. We basically never want that to exist ever. There’s no reason for that. And so, we’ll be able to control more of that. I’d like for them to at some point have batch delivery, which is something that I would totally use instead of the constantly getting more and more notifications.

Sam Corcos (00:24:41):

Just like 11:00 and 2:00 are my times when I get them by default or maybe there’s some pathway, again, just like a high friction pathway, which it could be as stupid as you have to go to a separate page and you have to solve a basic math equation, and then you can get a delivery. That would be enough for to take Andrew’s example of Slack. Sure, we can enable it. But how do we add friction to it? Maybe we do have admin controls. We can see how many messages are sent. We can have the wall of shame of people who send too many messages. Obviously, you don’t want to do that. But that’s a hypothetical of things that we can use to discourage that type of behavior.

Scott Klein (00:25:26):

Yeah, one of the things that I really want us to be and maybe have a unique view about this, because I came from dev is that, I want us to be very sensitive to folks that are in the blocking and tackling of the day to day stuff. Justin and Steph are working very closely right now on table stakes. At some point, if we introduce those friction, they’re going to feel not heard and they’re going to feel pissed off that we’re introducing friction where they otherwise don’t need it. I think that there’s a custodianship that we have to choose the right tools and defaults. But their job is way different than ours is right now. We’re spending a lot of different time than they are, and I don’t want it to be, it’s going to come off as sort of ivory tower a bit if we are forcing stuff that’s going to annoy them into their job.

Sam Corcos (00:26:15):

Yeah, one of the things that I think would be, this is just changing the way that Threads handles the stuff. It actually only became clear to me when I was writing out the long form document is that, sometimes the word notification gets overloaded. There is a difference between getting an email that says a thing was changed and getting a push notification. And I think oftentimes, at least in my mind, I had conflated those two. And so, to solve this, I will semantically call it an intrusion is the push notification, which is different than any other form of notifying something that something happened.

Sam Corcos (00:26:57):

So, I think it’s okay if we have all of the intrusions on threads set to off by default for everything, no intrusions, but you can opt in to intrusions for different things. I’m actively working on a project with Andrew and I’m here to be responsive to him. And I think this will actually be the case for Andrew’s role for a lot of these things. Andrew is there to be responsive to engineers when they need it. And so, he can turn on intrusions for these projects or for direct messages for people. That seems fine, but it feels very much like it should be an opt in rather than an opt out.

Andrew Conner (00:27:42):

I think that’s yeah, totally fine. If I wish, I don’t think Slack does because they’re full business model is geared up around them subsuming more your organization. And we’re like the being the place that work gets done. But yeah, ideally, I would love for it to be non-intrusive by default. And then, in these fringe scenarios, if there’s an active incident for example, that’s like a scenario where I would want to turn the intrusions on, because maybe it takes three hours of my day, but then I can turn it off when I’m no longer needed. That seems to be a way better. I don’t know that Slack has that ability. I do not know that we’re include some road map to be able to do that.

Sam Corcos (00:28:20):

Yeah. And I think I have a feature request for Threads right now, which is the ability to actively intrude. So, I can do app notify Andrew or something. And then Andrew will get an intrusion. And it would be effectively the same as a text message. It would be pushed to his phone and it is intentional, because I need his attention right now.

Andrew Conner (00:28:48):

And that seems reasonable to me as a form factor.

Scott Klein (00:28:55):

That is interesting to me. I don’t know what Threads’ thing is. Apple just released actually, there’s a lot of focus loads in the new iOS. Have you seen this? And it’s interesting. So again, all libertarian paternalism, everybody is sort of respected at their default level. But you always have that option to override and sort of notify people that you did override it on purpose. So, I don’t know if Threads, this isn’t really in their wheelhouse. But yeah, for these semi sync incidents come to mind.

Sam Corcos (00:29:25):

It’s not out of their wheelhouse because they do have notifications on for everything by default right now. When I installed the Threads app on my phone, it was super annoying. In fact, I have notifications on Threads turned off at the iOS level, because there were so many and I didn’t want to go through every channel and turn them off. I think if it was the opposite of that, where you opt in to what you’d want to be intruded upon, that makes sense. For me, I would probably not have any thought. That’s not going to be the case for everybody. There may be specific projects where I’d want to be notified, because there’s a fast cycle time. No, no.

Scott Klein (00:30:10):

What is your urgency for this right now? I mean, I feel we were sort of on the tail end of this experience where we like hard shut off Slack. I think it’s absolutely the right call. I feel everybody is now retrained onto Threads and Notion by default. Anecdotally, there is still people using Slack. Andrew and I will still chat on Slack, nothing substantive. It’s usually around scheduling or like, “Hey, here’s a doc for the upcoming meeting.” Stuff with 15 minutes for the meeting. Stuff at Threads is just like way too cumbersome. Sometimes I just don’t want to pull up Threads either. It seems like the right amount of tool for the job.

Sam Corcos (00:30:51):

Yeah. So, I saw Miz sent me the details on Slack usage. It’s super low. So, I don’t think there’s super high urgency. It’s really just a question of Andrew sent me these five scenarios. And so, it’s a question of these are edge cases, but they are edge cases that do happen and need to be solved. So, it’s really just a, I’d like to get the shift maybe by end of week. And just figuring out what a good solution is for each of these edge cases. And there will be more over time that we have to resolve.

Andrew Conner (00:31:30):

In terms of my own priorities here, some of them are just annoying. Like as in Ben was 15 minutes late to a meeting. He didn’t effectively have a way to let me know. I didn’t know when I waited around. Okay, it’s annoying, right? We are bad at engineering outages right now. It’s like Threads just a bad model, because things go out of sync and you can’t just leave it open and get updates effectively and stuff like that. That’s the one I’m feeling pressure to solve first. I feel very optimistic that do a hard reset did reset the norms. And if we get very clear, what is the use case? That kind of stuff. And then maybe just keep track of it.

Andrew Conner (00:32:19):

Maybe monthly Miz runs that report of messages. In that way, it’s like an integration test. And if you notice, I think last year, there was a month I sent like a thousand DMs or something like that. And if you notice, “Andrew sending a thousand DMs.” That’s a really good 200 DMs. That’s a good time to be like, “Hey, Andrew, what’s up? What are you doing? Is there something we need?” Almost like a wake up kind of thing. And maybe just like every manager for their team just keeps an eye on it.

Andrew Conner (00:32:49):

And the more I think about it, I like the idea of removing the channels, because channels are away that has this undefined priority for potentially a large group of people. I think if there’s an incident, cool. Create a channel, and that way we can link to the incident. But the incident ends and then the channel dies. It should be archived or something like that. If I think they’re my own stresses, it’s never, especially recently at the current volumes. It’s not DMs that stresses me at all about Slack. It was previously where, there was a message in the design channel.

Andrew Conner (00:33:26):

Is that something I need to read? Do I need to click through this? I don’t know. And Thread solves this five times better or 10 times better than Slack did because it makes it very clear. And we’re trained. People tag me and I am into the point now where I don’t read everything in Thread. As in I perpetually have unread forums and I’m not going to catch up. If you don’t tag me, I might not see it. Just tag me. If you need me tag me. And I think, people have been pissed at me.

Sam Corcos (00:33:59):

That’s how it should be, totally. Their primitive request response is super, super helpful in that regard. I probably still read. I don’t know, more than half for there are quite a few that I’m not involved in at all. This is something going on and content. They haven’t handled that. I don’t need to see that. I do wish actually for many of these there was an easier way to unsubscribe. Maybe there’s a hotkey that we can add, just like unsubscribe.

Andrew Conner (00:34:28):

In Gmail, I do this. I use Threads. And it’s actually kind of a sledgehammer because if later someone needs me and they’re expecting that I see it. But at Google, there’d be an email with 100 people on it and like someone got promoted, and there would be “Congrats. Congrats.” I would just mute that. I would love to mute it. But if you make the feature request of Threads, not only mute it, if you get tagged again, it’s unmuted. And so basically, yeah, I would love that. And that was my feedback to them was like, “I read a message, and now, I keep on getting pulled back into this message on a topic I do not care about.”

Sam Corcos (00:35:09):

Yep, totally.

Scott Klein (00:35:11):

So, I think one specific thread, you can do that. You can change your thread specific, not form specific but Thread specific notifications to only be a few like I mentioned. You can do that if you originate the thread though. If you create the thread you’re on. You’re on the roller coaster after the whole thing.

Sam Corcos (00:35:26):

That’s funny. Yeah, I wonder if there’s a, I don’t think there’s a hotkey right now to quickly do that, but it would be great if there was. Going back actually to the specific applications. So, the Ben running late couldn’t tell you. What’s interesting, using that as an example, I’m opening up Signal right now on the company messages. The last ones were Scott saying we’re on for a meeting in two minutes, and it doesn’t have a zoom link, which is exactly the right use case for text messaging. JM, saying that he’s running late on the meeting, and he wants to talk 15 minutes later. And me sending a message to Ben telling him that I’m running a couple of minutes late. And so, those are pretty common use cases for that.

Sam Corcos (00:36:22):

And what’s interesting in the example is that those are intrusive, and they’re intended to be. However, Slack, I think we have agreed is not intrusive by default. So, if you’ve sent that message on Slack, if Ben had sent you that message on Slack, he could not guarantee that you received it, because you might not have Slack open because it’s not intrusive, right?

Andrew Conner (00:36:44):

Well, so here’s how I would do it, right? So, I use macOS’ Do Not Disturb pretty liberally. So, right now I have Do Not Disturb turned on, I wouldn’t see even a fringe text messaged me. During like the Friday Forum, sometimes I’ll leave it off, right? Where if anything comes up, because I know it’s recorded and that kind of thing. The way I would have it is I would have Slack open, and ideally, I get less than one message a day. And I don’t mind when I’m at my computer working, getting interrupted or something like that. If I’m away from my computer, I’ll see it when I get back to my computer kind of thing. So as in like, neither pull, I would be decently responsible or responsive. Let’s say I am working through something like deep work. I blocked off two hours, Slack is just not open. So, I think I opt into a level such that a message would not hurt me. And I would be fairly responsive to it in the cases where they come in, if that makes sense.

Sam Corcos (00:37:55):

Yeah, I’d like to dig into this one a little bit further, just in terms of expectation setting for the team. If you send somebody a message on Slack, do you expect that they will see it within the next 24 hours?

Andrew Conner (00:38:12):

I send, I am the originator incredibly rarely, exceedingly rarely. So, I don’t have strong expectations. Right now, I have no expectations unless people message me, because my expectation is that they don’t have Slack open right now. So, let’s say before we hard cut off Slack, within 24 hours, yes, that they would see it. And my expectation would be they would opt in such that it’s not disruptive to their work and they would see it when they see it, right? And so, yeah, I don’t know if that’s an answer to you. But my goal would be if they are, let’s say an engineer is deep in a pull request, and they’re trying to get something done, my expectation would be that I would not disrupt them. Yet when they come out of it, when they go get some water or something like that, they might see it.

Sam Corcos (00:39:07):

Yeah, I wonder is setting 24-hour SLAs on Threads seems pretty reasonable. You don’t necessarily need to solve the problem that’s being requested, but acknowledging it. And setting expectations is totally doable on threads within 24 hours on default workdays. The challenge that I have and the expectation is that with text messaging, It’s intrusive. So, it is acknowledging that It’s intrusive, and that’s okay. The challenges with Slack or these intermediate tools is it is both expected that it’s within 24 hours and it’s intrusive, but it’s not intrusive when it doesn’t need to be, but it sometimes is or doesn’t maybe.

Andrew Conner (00:39:55):

Well, I think you’re trying to solve like hard SLA rules where they might not need to exist? And then it just works decently well. So, Scott sent me a Notion doc today, it said I realized I haven’t hit the stock in a while. I guess we can take notes during sprint planning and then go back to update it. I think that was very quick. It was a reasonable venue. It would be almost strange to send that over text message. Also, there’s fringe in Threads, I think. I think it was just like an offhand like, “Hey, we’ve got this meeting coming up in 30 minutes. Are you thinking about this, too? I just stumbled upon this, maybe you might want this.” If he hadn’t seen it, there’s actually no skin off my back there. It’s not a big deal.

Scott Klein (00:40:37):

Yeah, so I would say the guideline is use it as it’s working for you and don’t try to force it into something it’s not. I would feel weird setting a real response SLA kind of thing. We don’t have an SLA for text messages, right? It’s just understood that that is incredibly disruptive. Even if you’re out hiking a trail, as long as you have cell signal, you’ll see it kind of thing. And so, I guess I’m comfortable in this a little bit more nebulous space, and we just use the tools, and we’re very firm on the boundaries of the tools.

Scott Klein (00:41:17):

But then, if it’s going well, and people don’t feel it’s burdensome or something like that, then we’re able to continue and able to use it. And if it is turning into a problem, we solve those direct problems. And perhaps that means, I mean, it could be as simple as communication and messaging. It could be resetting expectations. It could be moving away from the tool and finding something else. I brainstormed about this, I think you know about the tool Yak. It’s just like asynchronous voice messaging. In my mind, the overlap with Threads is pretty significant. They’re not replacing Slack. It’s Threads basically.

Scott Klein (00:41:59):

And so. trying to find the right tool, I couldn’t find anything else. Techspace is a great feature, the fact that it’s text base. They have audio, I can record a quick snippet or something like that. But I don’t know. Maybe one difference is you want hard SLAs because you want to set the cultural expectations. And I’m just comfortable, people using it as they use it. So, for example, if I know John doesn’t like Slack, then I might formalize my communication, bring it to Threads and something like that. If I know that someone leaves it open when they’re not busy, when they’re not doing deep work, and they’re doing more managerial stuff, email processing, or something like that, that’s good to know.

Scott Klein (00:42:44):

And so, I don’t know if that feels more amenable to you. You kind of just tune it. I would not message you on Slack. I know that you prefer highly synchronous, highly asynchronous, and so, I would pick which one it is. And that’s exactly what we do. And so, I guess I’m comfortable just tuning that. And maybe people, you can use Slack like away online, offline indicators to kind of indicate what you’re interested in. I don’t know.

Sam Corcos (00:43:14):

Yeah, I hear what you’re saying. I think my biggest fear with a tool like Slack is just coming back to the entropy question, which is, are we opening ourselves up to a situation where there’s now a critical mass of people who are using Slack? And if you want to be involved in a project, somebody says, “Oh, yeah, well, we’re working on that in Slack. You have to get Slack.” If I’m somebody who doesn’t want to ever use Slack, how do we make sure that that situation does not occur?

Andrew Conner (00:43:53):

In my mind, project should not be worked on in Slack. You shouldn’t be thinking that you’re doing the work in Slack. That’s a wrong tool. I would be very comfortable and being like, “Hey, let’s take a step back. Let’s reset.” It sounds they’re you’re working in a way that’s not our preferred manner of working at Levels. In practice, I guess I have viewed into every engineering project, I don’t see anywhere Slack would be the right tool, and I would be very comfortable telling someone that.

Scott Klein (00:44:26):

I like that as a heuristic. If we’re going to enable something like a Slack, you could just set the tone that like no work gets done in Slack. There are no channels.

Andrew Conner (00:44:36):

And are going to keep coming back to incidents because they are the most acute thing we’re ever going to do. And Slack is weirdly the best tool for them to start out with. So, I don’t want to index too heavily on that.

Scott Klein (00:44:47):

Andrew, it’s like Firehose stuff. I mean, so we have one, two, three, four, five, six, seven. I have I’ve seven shared Slack channels with other companies. I’m not old or active. But they’re very valuable. Our one Stripe and US was actually really valuable as we were really getting the ID verification stuff. They were very responsive. It’s unfortunate that I would not want to be responsive to random customers. And so, that’s going to exist. Slack is the de-facto standard.

Scott Klein (00:45:24):

The other is, there’s an integration with literally everything. And so, even if Threads built something solving for Firehose, not everyone builds against Threads, because they have such a minor kind of thing. And it is so simple for me to webhook into Slack. And so, our back end has this like orders thing. And I don’t know. I think there’s these like very niche outlets that are just, I can’t think of a better tool.

Sam Corcos (00:45:55):

Yeah, I think circling back to Scott’s earlier point, maybe the path forward here is solving for this with some of the deprogramming where we are, we’re very intentional in our onboarding, on explaining our communication styles. And we don’t onboard people to Slack, maybe for the first month for four weeks. And then, we give them a Slack as an option and they can use it. There might be situations where they need to use it. Maybe engineers need to be on it for incident management. But it’s already created enough of a gap where they know how to communicate effectively without Slack as a tool.

Scott Klein (00:46:36):

I think that’s fair. And I think if you go to the emotional focus of, people coming into a company wants to make progress and they want to make it fast, they’re going to use the lowest friction thing. And I think given them the permission to slow down a little bit, don’t try to ship stuff immediately. Don’t try to bug people immediately. Just explore. Take a look at Threads, get used to the tools. This is how we’re using. It’s deprogramming on tools, but it’s also deprogramming on their nervous system in a way. We want you to just feel like you can slow down a little bit without feeling bad about it.

Sam Corcos (00:47:04):

Absolutely.

Scott Klein (00:47:06):

Yeah, and I think that might set enough of the tone. We all went through it when we went to Threads, by the way. I think there was this real good, go back and look at the thread. I think even I had some fairly aggressive comments about, this seems a little parental, telling us what tools we can use. And I think once you get over that hump of it, you’re like, okay, all right. The wheels are still turning. We’re all right.

Sam Corcos (00:47:30):

Yeah. It feels much lower stress from it. I think it’s different for different people. Like Josh did, he and I talked about this. He had no issue with Slack, but he also didn’t need to be involved in a lot of channels, and didn’t really do a lot of communication on Slack. My primary role is communication. And so, I’m in the Slack Whack-a-Mole lifestyle, and it sucks. And people in ops and support are also dealing with that. And so yeah, it’s definitely using the right tool for the right job.

Sam Corcos (00:48:02):

So as maybe an action item here, it sounds like I can have an action and I’m here to coordinate with Miz on creating some onboarding material around this. We can keep Slack active. One of the things that Miz proposed is a Slack reset. But I don’t think that’s really necessary. We don’t need to kill it and then create a new instance. We can just have the cultural norm around it, have onboarding material around it. Not have people be added to Slack by default. And so, have that deprogramming period. I think four weeks is probably reasonable.

Andrew Conner (00:48:41):

Would you be comfortable if I just could clear out all the existing channels?

Sam Corcos (00:48:44):

Yeah.

Andrew Conner (00:48:45):

The way we operate a general channel makes no sense. You should be able to send a message willy nilly to the whole company and interrupt them. And so yeah, if you’re fine with that, I’ll just archive everything that exists that isn’t like a business purpose, a pairing with another company or something like that.

Sam Corcos (00:49:04):

Yeah, it seems totally reasonable.

Scott Klein (00:49:07):

We’re currently using a team Discord. So maybe social as the only other topic, bit I think we maybe kind of need to have a stance on. I’ll just open by saying, my biggest concern coming into Levels was that it was going to feel very alone. And I think we had a fairly active social presence around WaterCooler and whatever else. So, I don’t know if there’s a way to keep that around. Discord seems very like it’s kind of like a game or tool. It hasn’t gotten nearly the adoption because I don’t think it has the same like kind of work feel to it.

Scott Klein (00:49:45):

I just want to call out that there’s one thing about people coming into a company wanting to make progress and wanting to deprogram a little bit of that nervous system stuff. There’s a little bit of belonging that I think is a separate issue that Slack, at least for me did fill the gap tremendously. I was really, really enthused at how much people were sort of chit chat. And if I wanted to engage in that, and felt the pressure to do so, but I knew it was there. And it’s how I got to meet and know a lot of the people here.

Scott Klein (00:50:12):

So just call it like, we have a huge blind spot. Because the three of us have been here for a while. Even me being here for five months is enough. But those first couple months are key. And I don’t know how we solve for the meet your people and spend time with them and get to know folks in your team. Because that’s how I did it and I don’t know. Most people normally do it is the Slacks. I don’t know. That might be a separate friction point that people feel good.

Andrew Conner (00:50:37):

Yeah. So, I think one success of Discord is it’s allowed everyone to determine their own engagement with it. So, for example, personally, I keep it closed, and I open it a few times a week, and check in. The downside is, I agree, it basically killed all most chit chat kind of things. I would say it’s maybe a 10th of the level that used to be. And so, I guess, one question to solve is, what’s the outcome? What would be the right level? And recognizing that we may not be the chit chattiest. I’ll specifically say Sam is not the chit chattiest, right? And I’m probably not either, right? And there’s some people that gives them a sense of belonging, talking about an Apple event, or something like that. It gives them a sense of identity in a team.

Andrew Conner (00:51:31):

I don’t know, I would feel uncomfortable if we create Slack as this almost like sacred in between space. And you’re really supposed to tune your usage of it. And it is the way that you can send me something and it won’t disrupt my day too much, but I’m opting in and social. It feels maybe Discord is the wrong tool. And we have a separate Slack social channel. I mean, Slack allows you to sign in and out of multiple accounts. Maybe that I don’t know. But it just, I would feel uncomfortable, engineering outages, integrations, like Firehose integrations, and all social chatter. To me, they almost just feel in different spaces. While acknowledging that, I think there’s something here, people were engaging with it. And the Discord thing just hasn’t resonated.

Sam Corcos (00:52:32):

Yeah, I wonder, one of the things that we learned more than a year ago, we brought on somebody part-time to help us with growth stuff. And he ended up opting out of the rest of his contract after a few weeks. And the biggest reason was that, at that time, our onboarding processes really didn’t exist. And his number one reason was that he felt he had no idea who our team was. And it was completely disconnected. And that was, I think, a year and a half ago now. So that was really helpful feedback. And as a result, we started doing, I think Tom was the next person we brought on and I had a daily call with him, I think, for the first month. And now we make onboarding the first two weeks much more intentional around meeting everyone on the team, on reading the documents, really getting to know everyone first.

Sam Corcos (00:53:30):

So, it might be interesting to check in with people on how integrated they feel. It is something we have to be much more intentional about as a remote team than a co-located team needs to be. So, I guess I have two questions around Slack and incident management. Is the expectation, when an incident happens, you get added to the channel, have notifications on, is it an expectation that as an engineer, you will have Slack open and have the ability to be notified when an incident occurs?

Andrew Conner (00:54:04):

They don’t necessarily need that will have pager duty in due. So, if I need John and I need him right now, I have a way of doing that. We just need the venue that once everyone is online and going, I think the last major outage, l had a Zoom room open for a couple hours and I think people jumped in down a bit. But it was really bad because people, an ops weren’t getting updated. It’s incredibly disruptive for them to sit in the Zoom room because we’re talking about very specific, instance sizing how many instances, and that’s disruptive but I need to be able to give updates and so we were using Threads for that.

Andrew Conner (00:54:42):

I found out later like Braden was seeing it, but Mercy wasn’t. I’m actually not too worried. For a major incident, we created a channel we add the appropriate people to it, either I know are online or that are I’ve notified or something like that. And then we can link that thread, channel and threads. If anyone wants to follow along, you’re welcome to but it is operating independently from anything like that.

Scott Klein (00:55:11):

The other call with incidents as well is that they happen at weird times. And there’s this mixed mode where if it’s dinnertime, and I’m hanging out with my family, I don’t want to leave them completely. But I can just kind of keep tabs roughly on what’s going on if it’s in Slack. And I can sort of comment on things to look out or whatever. So, there’s sort of this like half attached mode that I think is enabled specifically for incidents that is good.

Sam Corcos (00:55:41):

Yeah, I think that’s reasonable. We can give that a go. We should just be mindful of proliferation. Just the recognition that Slack by the nature of its existence, and the way that they optimize their product is trying to pull us into a style of working that we really want to avoid. So, I guess, the circling back also to the question of SlackSocial, it would be interesting to maybe ask the team why they’re not as engaged on Discord, the form factors are nearly identical. My guess is that the reason why engagement on SlackSocial was so much higher, is that everyone was basically spending all day with Slack open and in all the time. It was like, “Oh, is there one more channel that I’m cycling through?” Whereas now, being social takes intentionality and friction. That’s my guess.

Andrew Conner (00:56:39):

Yeah.

Scott Klein (00:56:40):

That’s what I meant by, we have to decide what is even the expected outcome? Because maybe it’s this, maybe it is like not. And it could also be that the problem solved itself once we have more people, so it feels there’s a buzz there. Whereas right now, messages are so infrequent, you could check once a week and be fine, even if you’re interested in something like that.

Andrew Conner (00:57:04):

Yeah, I know, the social stuffs important for me, but I am getting a bit worried that if we put it back in Slack, then the entropy is just going to happen really fast. I don’t know. I don’t know how to solve for that.

Sam Corcos (00:57:18):

Yeah.

Scott Klein (00:57:19):

I think Slack had like forced, like ephemeral, like quiet channels. That would be one thing we could do. But I don’t know, maybe this is something that we just bite. Again, look, the point is not to be social with the entirety of the company. It’s sort of to get assimilated into my group. I have my little tribe of three or four people that I’m going to be working closely with and I want to feel like I’m part of that group as soon as possible. I think there’s probably other ways that we can do that. There probably actually aren’t even Discord. It’s probably just having good touch points where it’s like, cool, you got a new person on your team. It’s now like beers every Friday afternoon, and everybody just kind of gets together and you tell stories and kind of do whatever. But for the first month, there’s a lot of social touch points that you can kind of get to know the people you’re working with. I don’t think that’s Discord actually would shudder to think it would be.

Sam Corcos (00:58:03):

Like an interesting thing is there’s no reason philosophically why Threads couldn’t be used for social chatter. But I guess it wouldn’t be chatter, like Reddit is a forum. It’s the same format and Reddit is a very popular kind of social network, right?

Andrew Conner (00:58:23):

Yeah. But it’s also not Chatter. The form factor determines how it’s used. And so, like, I wouldn’t want a company Reddit, for instance. I don’t think the same outcome would occur.

Scott Klein (00:58:36):

Yeah. Chatter is specifically low friction. And there’s a temporal sort of nature to it. Usually, like WaterCooler stuff is like, “Oh, did you see this article that came out about a competitor or whatever?” I’m inclined to maybe we can focus on this a little bit more. Maybe this is something for Jackie and Lauren, and they kind of just started today, that we’d just sort of keep an eye on, how close they feel and what things worked for them. I think, despite, I’m not rushing to push this back into Threads.

Sam Corcos (00:59:05):

Yeah, it makes sense. Well, I think we’ve resolved all of the outstanding questions that I had. Are there any other questions you had from the doc?

Andrew Conner (00:59:16):

No, no. I don’t think so. I’m happy with this. It solves all my issues.

Scott Klein (00:59:32):

This is cool. I actually really liked this sort of, maybe not detox because it comes as a little bit of a social stigma, but I think there’s almost like a baptism or a cleansing into Slack that we’re going to sort of do with people. I think it would be fun to just sort of like an angel gets its wings in a way where it’s like you’ve done this the requisite six weeks of slowing your nervous system down around work, and now we’re sort of giving you, we’re reintroducing you into the wild though you can sort of be on Slack and sort of safari that with your co-workers.

Sam Corcos (01:00:01):

Yeah, for sure. I mean, it’s very real. I think I’ve mentioned this on a podcast before, at my two-week check in with Chris Jones. He literally described it as going through rehab where playing Slack Whack-a-Mole and coming to Levels and just like getting your computer, and there’s nothing on your calendar, and there’s no notifications to check. He’s like, “Well, what do I do now?” There’s some anxiety that builds up. And then after about two weeks, that seems to be about how long it takes to reprogram the brain. And then you look back on it and like, “Wow, I never want to go back to that.”