0:00
The median tech worker never gets more than 30 minutes of uninterrupted time.
The median tech worker never gets more than 30 minutes of uninterrupted time.
Could you imagine trying to write something if every 30 minutes you got distracted. You couldn't do it.
People don't get that deep work because they're constantly distracted by these communication tools.
What about Levels, the nature of your company makes it work well for a writing heavy culture?
Levels is an experiment in what happens if you turn deep work up to 11.
If you want to build an average company, you can just do average things, and that's okay.
But if you want to build an extraordinary company, you have to try new things.
People talk about business writing all the time, and there's a lot of junk out there.
The best thing that you can do is learn from an entrepreneur who is truly obsessed with it and an entrepreneur who has built a successful company with writing.
At its core, that's what Sam Corcos is all about.
He's the founder and CEO of Levels.
Company's valued at something like $300 million and writing is the pillar that everything orbits around.
He talks about hypotheses and retrospectives, why they do long form memos, how he thinks about them.
What does he do when he goes on a think week?
How does he write strategy memos?
That's what this episode is all about.
We basically, we sat down and we said at every single juncture, we're going to go the nerdy, the esoteric that we are, the strange, the obsessive route.
We're really going to get into the weeds of business writing.
This is the most in-depth conversation I've ever had on the topic and it's time to get started.
Sam, I want to start off with this quote of yours. Writing is thought.
If you can't write out your ideas, you don't have coherent thoughts.
I think that it's really important to be able to articulate your ideas.
And in my experience, most people have ideas in their head and they think that they know the answer, but when you actually...
It's a similar idea to why people go through the act of teaching is that if you think that you know it, but you can't explain it to another person, you probably don't know it as well as you think you do.
That's certainly been my experience personally doing a lot of writing.
One of my favorite quotes from James Clear is he says, "If you think you can learn a lot from reading a book, try writing one." Yeah, I believe that. Rips. Such a good line. Yeah, definitely.
So how much time do you spend writing?
A lot less than people would expect.
I keep pretty rigorous track of how I spend my time.
So if you exclude things like emails and company writing, which is just more communication, you wouldn't know it, if you saw just how much content we have internally of all of the long form strategy memos, the thought pieces that we have.
We have a lot of content.
In fact, you've seen a lot of it.
It turns out it's less than 5% of my time.
So it's actually a lot less than people would anticipate.
What's interesting is you said it was less than you anticipated because you track your time and you were like, "I expected writing to be, call it 20% of my time.
It was actually closer to 5%."
And what I reckon is that writing takes up a lot of cognitive bandwidth, but it actually doesn't take up that much time on your calendar.
Yeah, that's exactly right.
It feels like a much bigger lift and certain other things that are really energizing or just they feel less of a cognitive load, like meeting with people and having a casual lunch or breakfast, that actually takes a lot of time, but it doesn't feel like you just spent six hours doing it that day.
But when you're writing a thought piece on company strategy, it can feel like you just spent three days on it, but it actually took two or three hours.
And walk me through some of the principles and parameters at Levels for how you think about business writing and why it's so important.
So part of this stems from the fact that we're a remote first company.
And so, it's really hard to communicate ideas effectively to a lot of people with a consistent message when everyone's distributed.
You have to be able to write it.
As a consequence, all future people are also able to capture that information.
So every new hire that we bring on is able to fully get up to speed on everything that's happened at the company, understand what our mission is, understand what the goals are, they can see the entire process of thought that led us to where we are today as well, which is also very helpful.
They're not just dropping in at one point in time with no context.
I'd say broadly speaking, the amount of thought that has to go into something should be roughly proportional to the degree to the importance of the thing that you're doing.
So we don't make everyone write everything down. This is not a...
We don't do it process for process sake.
It's more pragmatic, where something that might command a $50 million commitment for the next decade, you should probably take a lot of time.
You should probably really, really know what you're doing.
If you want to make a small change to the app, where you just want to move one thing from here to there because you got some feedback, and it's going to take you 10 minutes, just send somebody a note so that they know that you're doing it, but you don't really need to spend an equivalent amount of time.
So I think where a lot of people get stuck is that it can seem daunting to write these memos.
We actually have gotten this feedback internally where people, especially newer people, where they see our whole catalog of these really long thoughtful memos and the hurdle that they perceive is that it's really high.
They're like, "I'm never going to be able to write these 30, 40, 50 page memos.
It's just never going to happen."
But also the things that they're doing don't really require that.
Maybe they only need to write a one-page memo or even a two paragraph memo just saying, "Hey, here's what I'm going to do.
Here's what I think is going to happen." That's pretty much it.
It seems that one of the things that is important here is that writing freezes thought and when you have, what you're trying to do is reduce the game of telephone inside of a company.
So if you were to ask 10 people inside the company, what you're trying to do is have ideally have them all say, "We're going to the same place and we stand for the same things."
And that speech has that game of telephone function, but writing, because the words are frozen, you're going to get more congruence in terms of what are we doing, where are we going?
Yeah, you want to have a source of truth that you all share.
And writing is the only way to have a source of truth because even if you manage to get everyone on the same page aligned verbally, it never ceases to amaze me how often those ideas diverge.
The good thing about writing, at a minimum, is that it still is the case that people will read a memo and then act in a way that is not congruent with what was described in the memo, but it's much easier to then say, "Hey..."
I can actually give a very specific example.
We have a memo on how to write a good hypothesis and everyone read it.
We all went through it, we had question and answer.
I felt like everyone was aligned. We had a written memo.
We talked about it a lot verbally.
And then somebody during their project ran into an issue where they felt like the way that we write our hypotheses don't work because it doesn't cover this specific situation.
And I said, okay, it makes sense.
It's your first time doing this, but let's go back to the memo.
It's like, so you said that we don't handle this particular case.
Well, there's a whole section here on how to handle this particular case, and they're like, I just forgot that was a thing.
And so it allows you to just constantly course correct.
Whereas if it's verbal, these things can just diverge forever and then you course correct and then they don't know where the source of truth is and it's just kind of in the ether.
So doing it in writing really makes it a lot easier to come to that level of alignment.
Why do you ask people to leave comments at the bottom of the memo rather than in the side?
So very specifically is that...
Yeah, so instead of using the inline comments, we ask people to just write it in long form at the bottom.
The main thing is that the comments are actually really useful to understand how the memo has evolved and to understand people's perception of that over the course of the discussion.
The problem with all of the things in the margin...
You're basically saying, I have long form thought, and then you're only allowed to comment in one sentence at a time.
But other people have ideas that they want to contribute, and so doing it in the margin with one inch on the side, and then this is even worse in Google Docs, where you've probably seen this, where there's a thousand comments and you actually can't find them.
There's not enough space there.
In a lot of our memos, I will write three or four pages and we might have five pages of comments and it's people saying, "Hey, I really like this idea, but I wonder if you could expand it to this, and here's what I was thinking about this."
And then I'll reincorporate those if it seems relevant.
I noticed this in your principles for effective communication memo that the main body of the memo is fairly pro-email, and then the comments are much more anti-email.
And what people are trying to point at is that email is default closed and it's harder to loop people in.
But it was interesting to see how the tenor of the debate began to change later on because of the comments.
There's an interesting thing about email that is challenging, which is that it is a, information siloing will always happen.
But there's a fundamental difference between an open silo and a closed silo.
So email is a closed silo.
Only the people who are looped in on specific messages can ever access that information. It's not searchable.
Nobody in the future will ever find that information.
It is an information silo.
Another way to think about it is an open silo, which is like an open channel on Slack, which a lot of people use, or something where you might not be involved in the conversation now, but if you get looped in, you can see the whole thing.
If you say, "Hey, I wonder what the deal is with that project," you can find it.
If you join as an employee two years later and you say, "Hey, I wonder what the discussion was on this two years," you can find it and it's actually really easy to find.
That's the main difference and probably the big challenge with email as a closed silo.
The other is just the specific methodology for adding people in is really cumbersome.
I think Miz on our team gave some really specific examples where there was an email thread that was like 146 lines long, but what was problem is that he would loop somebody in, but in the same time, somebody was already writing a draft for something that was above, and when they responded, it got threaded and then this person was deleted because they didn't realize.
And then you're just constantly trying to add and remove and then re-add.
And then you have to try to dig context and it's a real mess.
So figuring out how to make these things more open when necessary or when useful, I think that's a big distinction.
Why don't you just copy Stripe and do some sort of open email policy.
So it's funny that you say that.
We took a lot of inspiration from Stripe on these things.
Stripe doesn't really do that so much anymore, just at their current size and scale.
But in the early days, they had basically a Google group that you would CC and then it would be shared with everybody.
That was the methodology, and I think it's actually really brilliant.
But they're really hacking together tools that aren't really meant for that use case.
But I think conceptually, it's a really, really good idea.
Something that we talked to somebody from Stripe about, he said, "Fight until your dying breath, the formation of information silos."
It was a very strong statement.
Fight until your dying breath, the formation of information silos. Yeah.
Well, we've actually taken a lot of those ideas and we really were hoping not to have to do this, but we ended up building our own internal communications tool, which should replace Slack and email and really most of the tools that we use in workplace communication that makes open silos the default and makes async and deep work the default for communication.
One of the things that I thought was really interesting, and we can put the graph here, but you seem to be pro synchronous work with a lot of caveats that it's last resort and pro very asynchronous.
It seems that the death is when you're not intentional about one of them or you're kind of in the middle and as a culture you seem fairly anti-Slack, definitely anti-text message, and it's like these moments when it's like, oh, you're expected to respond in 20 minutes to an hour.
Actually, don't be doing that.
Either go full a stringing full async where you can respond tomorrow, the next day you be on different time zones or go synchronous and just get it done. Yeah.
That's exactly right because we're, I would say, solidly anti-Slack.
There are use cases for chat rooms.
For things like, the most common one that we see is if you have an outage in engineering, you all kind of need to be async, but you also largely accept that you're not going to get any real work done that day.
It's like we're all going to be in the war room trying to figure out what's happening. We're on standby.
We're not going to take on any real projects because things might come in that we need to fix.
So for the most part, these sorts of, I'll call them pseudo async tools are really pathological.
Text messaging is another really good example because most people would define it, "Oh, it's async. It's text.
You can read it whenever you want." Yeah.
Well, in practice, I believe the statistic is that 97% of texts are read within three seconds.
So that's not an async tool in my book.
That is a synchronous tool that is, I need your attention immediately and I will get it within three seconds.
You can say, "Oh, well I can look at it and then respond to it later," but it's already broken your concentration and it's changed your focus.
And imagine you get those all the time and you're trying to work and you're like, "Oh, got another one. Oh, got another one."
There's no way you're going to be able to get into flow if you're having that.
And then to pull this to the extreme, this is the ultimate argument for long form writing. It is the most async.
You can read it years later.
As I was prepping for this, I read memos that were three, four years old and they were just right there. I could read them.
And they're written with the expectation that they will be read in a long time.
So you're sort of saving things for posterity. Yeah.
I think one of the quotes that we use a lot internally, which I stole from Matt Mullenweg, from Automattic WordPress is, "Be as async as possible, but not more."
I think that's the right way to think about it, where when you're out of alignment with somebody, when you are potentially rowing in different directions, you need to correct that as fast as possible. Ideally right now.
Let's get on a call and let's figure out how to get back on the same page because the longer we spend rowing in the other direction, we're going to have to then row to get back and delete all the stuff that we just did, and then we can actually start doing real work.
Misalignment, the longer that goes, the worse it is.
And so async is really bad when you don't have clear alignment with people because you can end up spending tons and tons of time with multiple people going in different directions, and then the cleanup from that is really hard and it's also really demoralizing.
This is a thing that programmers experience all the time.
It's like you get a bad set of instructions, you get some bad specs, you build a thing for two, three months and they go, "Oh yeah, we don't need that anymore. Just delete it."
It's like, "I could have been on vacation for three months.
That would've been better for all of us if I just did nothing, but instead of just building a thing that we didn't even ship, I should have just been in Hawaii."
How much do you rely on mantras and mottos?
You talk about the Mullenweg concept.
Is that something that you bring in a lot or are you more sort of, dare I say, unbundled or something?
I think that we have an almost religious zealotry against acronyms because it's hard to ramp people up when they don't know the lingo.
I think a clear failure mode is you join a company...
This happens in a lot of companies.
You join the company and they give you the glossary of all the acronyms you now need to memorize that are specific only to that company.
It's like, "What are we doing? Why is this a thing?" Just write it out.
It doesn't take that much more effort.
In fact, it probably takes less effort.
But there's a certain thing around camaraderie.
I've talked to friends of mine who are in the military, which is a big acronym culture. Same with flying. Yeah.
And it's a thing where you're like, oh, you're part of the club. It's a bonding thing.
But it's bonding because it's isolating to everybody else.
It's bonding in a really bad way.
I think that the opposite end of that is narrative. Narrative is useful.
You tell stories that tell a deeper moral, like a specific example, we have a phrase that we use, pork tacos, which comes from a very specific thing, which is it comes to this, the underlying message of pork tacos is build a scrappy version and be okay with that.
The first version of the app that we shipped, we shipped it very quickly within just a few days to our customers. It was not very good.
We shipped it really quickly and I forgot I had all of the food logs hard-coded as pork tacos, and I forgot to change it.
And so everybody who logged any food, they'd have bacon and eggs and it would say pork tacos, and it was like, okay. And you know what? It wasn't a disaster.
I just updated it, shipped a new one, got the feedback and it's fine.
So that's one of these narratives where we remind people like...
Another one that we have that's helped us make better decisions is people don't like it when you move their cheese, and this is because when, this is another one of those things that has this down...
It's a narrative of some downstream concept that we want people to internalize, which is don't just move things around all the time.
You have to explain to people, "Hey, you've been doing this thing here and we're going to move it over here."
And give them some time, have some messages so that the app doesn't just suddenly change on them, and they have no idea what happened, and now they don't know how to use it anymore.
If you're going to move this button, put a little warning on it that says, "Hey, in two weeks we're moving this button over there."
And they see it, they're still using it.
They know that it's going to be over there. Set expectations.
Don't just move things without telling people.
So we have a lot of these broader concepts that I think tell a deeper stories that help us operate better.
What people, executives, have you looked at and you say, I really like the way that they communicate and what have you taken from them?
I think I really admire Patrick Collison's leadership style.
I think the writing, the clear communication- I agree- The deep thought.
I think that what's really good about Patrick is the rigor that he brings, and he sort of honors nuance while reducing complexity, and I really admire that.
A leader who can say, "You know what?
There is going to be nuance in this situation.
We have a contoured, sort of a textured thing that we're looking at, and we're going to acknowledge the little hills and valleys.
We're not just going to look at the peaks."
I think that he does a really nice job of that, but also somebody...
He does a good job of also simplifying things.
Our mission is to grow the GDP of the internet. And that's a real skill. Yeah.
I think another one is I really, I've learned a lot from Brian Chesky.
I wish he wrote more, but there are a lot of ideas that I have followed, especially around building software.
He's had a lot of it just from experience that feels very relevant to us.
He recently killed all of the product management function at Airbnb, and he did a podcast with Lenny that really...
My co-founder sent it to me because it was very...
The series of events that led him to make that decision was almost identical to the set of experiences that we have that led us to the same conclusion.
And so, he handled COVID and layoffs extremely well.
I reference that memo quite a number of times.
So there are people who handle these situations very well.
I'd say Brian Armstrong is another person that I really admire on this stuff.
He's a very clear thinker who has courage in his convictions, and he is willing to take the arrows to just pick a direction and go with it.
We had some early conversations with him and we were a fairly small company.
It was very helpful in helping guide us on how we should be thinking about building our culture.
What do you think that you changed as a result of those conversations?
I think the biggest one was we told them that we're going to be running some of these pretty wacky experiments around transparency.
We're going to share our investor updates publicly.
We're going to share our team all hands publicly.
We're going to share all of our meetings by default internally to the company, including one-on-ones, performance reviews.
If you don't want them shared, you can opt out of specific meetings, which is fine.
But by default, all of those things are shared.
Everyone knows how everyone else is performing, everyone knows who's not performing, and we can all help each other. We act like adults.
And I think it really helped reinforce...
He said that if he was doing Coinbase again, he would would've been more aggressive on these things earlier, and he would've been more transparent and more open earlier on.
And I think that gave us more courage in you know what, let's go for it.
We should try these things.
If you want to build an average company, you can just do average things, and that's okay.
But if you want to build an extraordinary company, you have to try new things.
So it gave us a lot more courage to push those things.
When you're writing a performance review or just generally coaching people on how they can be better in their work, how do you structure that feedback?
It depends a lot on what the issues are.
So one of the heuristics that I have found is really helpful is...
And this maybe ties into the previous question around who do we admire?
I think Netflix has a lot of ideas that we've pulled from.
Treat people like adults is either directly from Netflix or it's very similar to how Netflix operates.
We've taken their heuristic of the "keeper test." Do you know this one? No.
The "keeper test" is really...
It's really helpful to just get at...
Oftentimes you can rationalize somebody being useful or good or not making a decision because you can always point to good things that anybody does.
You wouldn't have hired them, initially, if they didn't have something that was positive.
But the "keeper test" is you do role playing and ideally you really try to get into it.
And you imagine yourself, you close your eyes and you have somebody on your team, and you imagine that they just came to your desk and they said, "David- ...
and you imagine that they just came to your desk and they said, "David, I have some bad news.
I've decided that this is not the place for me, and I just took a job at Google, and I'm going to be leaving in two weeks."
Then they really reflect on how you feel right now.
Do you feel relief, which is often the case? Do you feel excitement? Do you feel indifferent?
Do you feel, "Oh, my God, this is really bad.
This is one of our top performers.
I have no idea where this came from.
We need to keep this person"?
The only acceptable answer is the last one.
If you feel anything other than, "We have to keep you, I would fight really hopeless.
Whatever we need to do, let's figure this out.
We need to keep you on the team," you need to have that conversation with them.
Like a conversation that I had with somebody a few months ago was I did the exercise and I realized I would actually be completely indifferent.
And I had a call with them.
And these calls can always be uncomfortable, but I said like, "Hey, I did the keeper test exercise, and I realized that if you left, I would be indifferent."
And that's not good for you and it's not good for me.
So we need to figure out how to get to the point where, I'm excited that you're working here, that I'm confident that you're working on really high value projects.
Otherwise, I think we'd both be happier if you were working somewhere else where you could add a lot more value.
You're obviously very talented, that's why we hired you, that's why you've been here for so long, but where we are right now, this is not a match. So that's at the end.
How about at the beginning?
In the hiring process, you talk about these memos, you do have so much long form writing.
How is that infused into the way that you hire?
I think the biggest thing is approaching it as recognizing that it's a matching problem, not a sales problem.
We spend most of the interview process legitimately trying to convince people that they do not want to work here.
That they do not want to work here.
We have a very strange way of operating that most people would not be comfortable with. Yeah, no kidding. Yeah.
Legitimately, at least 95% of people would not be happy working in the culture that we've built.
And the 5% who would be, have been looking for this their entire lives.
Every hire that we have made since we started the company, every new hire has been more and more aligned, and more on board, because there's so much more information and they know what they're opting into.
It's less of a surprise to every new person that joins.
They see interviews like this where I talk about how this works, and some people will go, "That sounds like a nightmare."
And it would be for some people. And that's okay.
And that's why employment is voluntary.
Now, if I'm applying, would it be a nightmare, let's focus on the writing, would it be a nightmare like, "Sam, I'm not a good writer. I can't function here"?
Would you say, "Yes, that's true"?
Or would you say, "It's actually not about the writing necessarily.
We need you to be able to think well.
We don't need you to write this beautiful purple prose, but we've seen that we can train people up"? What do you say to that?
I think the answer is that not everybody needs to write long-form strategy memos, but we do need documentation for things.
One of the hacks around this is for people who really struggle to write, they can partner with somebody.
One of our EAs, they can record a Loom where they get all the ideas out and they just stream of consciousness, they just say all the things, and I think some of this, and some of that.
And then the EA can outline it for them, or sometimes they just use ChatGPT for this to get the first draft.
And then just the activation energy is just so much easier to go from having an outline of something, versus coming into an empty page and not knowing what to do.
And so I would say people who are not good at writing in general, especially in leadership roles, have really struggled at levels.
But I think that's okay.
One of the things that we do in our recruiting process is, we have everyone, at least for our engineers, we have them do a teach me something, where they record themselves on video, usually on the Loom, teaching the rest of the engineering team and engineering principle.
Because when you're a remote company, being able to communicate effectively in that format is really, really important.
And communication is not just some secondary thing to do.
It is a core part of everyone's job.
If you are not capable of communicating, it doesn't matter how good you are per se at your technical role, if you can't communicate, it's going to be very, very hard to do, especially at a remote company.
I think you can get away with a lot of this if you're co-located, but it really is such a necessity because of the way that we operate.
So what I hear you saying is that it's written communication with these memos, but you do not need to be the person unless you're a leader, or spoken communication, lots of Loom videos.
I think you said you record 15 to 20 per day.
Yeah, I record a lot of Loom videos per day.
I think this ties into writing is just one medium.
And I know you and I have actually had a conversation about media theory and how the- One of my favorite topics. Yeah.
The medium is the message.
And it is not the case that writing is the correct medium for all types of communication and for all messages.
And so for a lot of things, if you're giving somebody tough feedback, you shouldn't do that in writing.
You should meet them in person, you should do it on a video call so they understand your tone.
It's so easy, even if you assume positive intent, it's so easy to read into things that were not intended.
So having the correct medium for the right message, a lot of things where, if you're giving somebody feedback or you're criticizing something, it's way better to do it in a Loom, where you say, "Hey, so I was looking at this thing and, I don't know, it doesn't seem right.
I think if we do it this way, that might be better."
If you do it in writing, all of that tone of like, "Oh, he's just kind of saying this casually, this is clearly not a strong opinion that he has."
And this is something like, as the CEO of the company, things that I write are very easy to misinterpret.
I was like, "Oh, this is the new strategy of the company."
As opposed to, "Yeah, no, I wonder...
I was just thinking, maybe that would be better? I don't know. It's kind of up to you." That's interesting.
How do you use maybe punctuation highlights to be able to get those I wonder thoughts out as a CEO?
I think some of it is, it's really challenging.
Some of it is doing it in video so people can understand tone.
Some of it is, you have to just be very, very explicit.
I use text expander, I have a snippet called Hedge.
It's literally I write Hedge and then it autocompletes, which says, "These are just my passing thoughts.
This is not intended to be a change in priority."
I have a whole paragraph of just Hedge. It's like a disclaimer. It's a disclaimer.
And even when I include things like that, it doesn't always work.
So I know a lot of CEOs at larger companies where...
We're still small, we're 40 people.
I'd like to keep it as small as possible for as long as possible, but I see other CEOs, once they reach some threshold, they discover that their communication is more disruptive than it is helpful.
And so they end up creating this silo of only these 30 people get to see anything that I write, because these 30 people will be able to contextualize it and understand it.
I hope that we don't have to do that. It might be necessary.
There's a lot of very thoughtful people who I think have the same intentions that I do, but who end up in that because it's just too much effort.
We experience this a lot because of our transparency culture of writing, and everyone gets to see everything.
People at every level of the company can see our company financials.
We do a meeting, the Monday Metrics Meeting, what we call it, where we go through the things, what are the things that are not going well, let's look at those numbers, and let's figure out how to fix them.
Something that we didn't appreciate until we've been doing it for a couple of months, is that people thought the company was dying, because in the Monday Metrics Meeting, we're not saying, "Hey, all these things are going great."
It's like a nuanced discussion of a sub-metric that's going down.
And so people watch the recording and they're like, "every chart is going down into the right," and they're like, "this is bad. We're going to die."
And then at some point, I asked O'Reilly who was leading finance, and he's now running all of business operations, I asked him like, "Hey, let's level set and let's show people, let's zoom out."
And when he showed a chart of like, "Hey, our revenue is like this," everyone was shocked, because every chart that I've seen for the last two months was down into the right. "How is it? Revenue is triple?
That doesn't make any sense."
Well, this is the challenge with written communication when you're so open with these things, is it requires so much more contextualization.
I think it's worth the effort, but it does create additional overhead, because not everybody is going to have a degree in accounting, and they're not going to understand the nuances there.
To go back to the Loom video point with feedback, Tim Ferriss was sitting in that chair, and he said that Looms have really helped him with writing feedback.
Where, what he'll do is he'll do line by line edits, but then he'll give the overview feedback in a Loom.
And I find that that's really helpful, because it is just nice to when you're giving edits to say, "Hey, this could be better, that could be better, that could be better," but if you just listen to those, you kind of forget that there's this overarching, "Hey, that's pretty good," "Hey, I feel like this really has a lot of potential," "When your voice came out in the third paragraph was awesome."
And what I'm hearing you saying is that the combination of Loom videos and writing, those play really well together. For sure. Yeah.
And a lot of the videos that we have, we also include a Loom overview, so people can see- You put them at the top.
You put them at the top of the memo.
It's a common thing that we do, is, especially for the long memos, and we have some memos that are 50, 100, I think our longest memo is 200 pages.
And it's going to take you, what, a couple of days to read the whole memo.
So having a 20-minute Loom overview that summarizes it where you can see what that person feels and thinks is important, and you can watch it at 2X while you're on a walk, makes a huge difference in people's ability to ingest this information.
And this 200-page memo, that was one we were talking about the other day, big project, going to cost you eight figures to basically do the investment, and you're thinking through, "Do we do it? Do we not?"
And this person, I guess needed to convince you that it was worth spending all that time and money. Yeah.
And what's funny is I told him, "I need you to write this memo because I need you to convince me this is a good idea."
And his response was, "I first need to convince myself that it's a good idea." Oh, interesting.
And so for him, the process of writing the memo, although it was a slog, I remember seeing him while he was in the depths of writing this memo, and he was not sleeping very well, and it was really stressful for him, but by the time it got to the other side, he really deeply, deeply understood the decisions that needed to be made, and all the different trade-offs on the choices. So it was well worth it.
But I think what this ties into one of our first topics, is, the challenge is that if that's the first memo that people encounter, they think that all decisions have to be made in a 200-page memo. But that's not the case.
And a lot of projects can be very, very short.
It's just a matter of documenting it.
I think one of the other benefits of writing is we're pretty rigorous about the scientific method. Really, all it is.
Write your hypothesis beforehand and write it down.
The nice thing about writing is that it doesn't change.
Your perception of what you thought you said three months ago changes a lot.
Whether you wanted to or not, the most well-intentioned people, our brains are rationalization machines.
Our brains will come up with crazy rationalizations, even for the most well-intentioned, most disciplined people.
I'm guilty of this myself, that's why I write, in order to be able to hold myself accountable to my own thoughts.
So specific example would be you say, "We're going to launch this feature and I think we're going to get this many conversions."
If you say that out loud and then the feature does something, it does less than that, it does whatever, it's like, "Oh, yeah.
I mean, we all knew that was going to happen."
Whatever it is, your brain will tell you that you were correct.
If you go back to what your prediction was and you realize, "Oh, wow, I was like two orders of magnitude off here.
That's actually really bad. How did that happen? Where was I wrong?
How can I adjust my thinking so that I can do better next time?"
If you don't have that feedback loop where something is written in stone so that you can't change it, and you can't run from what your original hypothesis was, it's so easy to find yourself in this trap where you're constantly rationalizing.
Let's dive into the idea of the hypothesis.
So what you say is the purpose is that your hypothesis is what you believe is the return on investment of a given project.
Why do you use those words, the ROI, for the core part of a hypothesis?
So, the specific definition is more practical as a business application of how to use...
A hypothesis even more simply is what you think is going to happen.
But in a business context, you probably should not bother creating hypotheses if you don't think that the outcome of the thing you're going to do adds value to the business. Sure.
I think that's where people will get stuck on this.
People will often, I was talking to somebody just yesterday about this, where his frustration with his product team is that they create a lot of work, and they move things around, and they're doing lots of work, and they have lots of specs, but doesn't drive any business value.
Then they might get upset and they say, "Well, how are we supposed to quantify this?
It's impossible," and this and that.
I found that if you zoom out and you say, "Okay, you want to do this thing.
What do you think is going to happen?"
It's like, "Well, people are going to X." Great.
We have now started a hypothesis.
You said we're going to do X and I think something's going to happen.
What is that thing that you think is going to happen?
It could be, people will like it more.
Cool, but just you are only building this because you think something is going to happen.
Otherwise, what are we doing here?
You're not saying, "Well, I'm building it because our engineers have extra capacity and I don't want to keep them idle."
It's like if that's really the reason, that's a bad reason, which is how it works in a lot of companies.
People need to rationalize that their jobs should exist.
They need to create, it's like, "I don't have anything to do, so I need to look busy.
Otherwise, I'm going to get fired, because I don't actually have any useful work to do."
So they need to do things to justify their existence in the company.
That's not a good situation for anybody.
It's not good for the company.
It's not good for that person.
They're not going to grow in their role, they're not really going to learn anything.
So, to the greatest extent possible, you want to try to create a hypothesis for what it is that you're going to do and how that derives direct business value.
Ideally, this just comes down to dollars, which is, you would say something like, "I want to build this feature."
It's going to take eight engineering weeks to build it.
I think if we assume that this is related to our retention metric and that it correlates, in our case, it might be, "We can assume from the data that we've seen, that 12 month retention is increased by this amount if people log more food.
I think building this thing in eight weeks will increase the rate that people log food by 20%.
Retention, we value it from an LTV perspective at X dollars, and so therefore, this eight weeks of inch time I think will deliver us $90,000 a month in business value." Awesome.
That's the best case scenario.
And then you can compare that with what other projects do we have.
It's like, well, we have this other one that says with two weeks we can update our email system and we think that can give us $200,000 a month in business value, just from more conversions.
It's like, Well, 200 is bigger than 90, so we should do that.
And so the closer you can get to understanding the ROI of your projects, this is where people often get hung up as well, is that the specificity is not that important, because you almost always end up with an order of magnitude difference between these projects.
The times when I've done this, people had eight projects and they were reluctant to do a hypothesis.
We would walk through each one, and one of them has $50,000 a month for very little effort.
And then another one is like, we expect this will be ROI of $8.
It's like, on paper they look the same, but this one is basically completely worthless, but you wouldn't know that unless you did the math on, how many people does it affect?
What it impact do we think it'll have?
How much does that impact conversion or retention?
Something that's sort of a sister to a hypothesis that I noticed about your culture is how much time you spend framing problems.
This is, out of all the things, maybe the number one thing that stuck out.
Before you dive into the solution, make sure that your concept of what the problem is, is accurate.
And I want to hear you talk about that, because I've heard something similar, I think I heard it from Peter Thiel, where he says that a lot of the time people don't get to the right answer because they're not even framing the problem correctly in the first place.
So whatever board they're looking at, whatever they think that the rules of the game are, or where true North is, it's actually off.
What kind of companies should be leaning towards this way of writing-centric working?
I think most companies should do more writing.
One of the reflections that I had is I do the most writing of anybody at the company, most likely, in terms of long-form thought and strategy.
It's less than 5% of my time.
Which means that at most companies, most CEOs probably spend less than 1% of their time thinking about strategy of their business.
That's kind of terrifying.
So, I think almost everybody can benefit from more intentional, deep strategic thought.
I would say that the specifics of what enables us to do it is that, some of it's almost just necessity, because we're fully remote.
If you don't have a culture of writing and you're remote, people just get dropped in...
This was actually feedback that we got very, very early on, before we'd figured out how to do this, was new hires would show up, they'd get their laptop, and that's it. They're like... "Get to work." "Get to work." They're like... Where do I go? "Where do I go? Who are these people?
What does this company do?"
They have no idea what's going on.
And so we put a lot, we have a full month of onboarding.
The whole first month, you don't have any deliverable expectations.
There's two things that I think stand out from that.
The first is the Async Week, and the other is the leaders have to write a strategy memo about their domain, right? Yep. Yeah.
So Async Week is one that ties into, it's really reprogramming, maybe even deprogramming more than anything, where people are so used to this hyperactive hive mind of Slack culture, where, there's a great essay called LARPing Your Job. Have you seen this one? No.
Yeah, it's a really poignant article. That's a great title. Yeah.
Where it's like people think that their job is to be on Slack and jiggle their mouse so that it says status available, and it's like every once in a while put something into a chat room and you're just like Whack-a-Mole.
It's like, "Oh, new thing. Respond. Thumbs up."
You just kind of wait, or you go do something else. "Oh, new message."
And you're just all day in this hive mind of communication.
And the goal of Async Week is to break people of that habit.
I think this was even an earlier conversation that we had of, the problem with these pseudo synchronous tools like Slack, Slack is really just a superset of text messaging.
And people pretend like it isn't, but it's the same as getting text messages all day.
And you can say, "Well, you could ignore them or not." People don't.
Data from rescue time on this, which is that the median tech worker, cannot go more than six minutes without checking your communications tool.
They can't go more than six minutes. Geez. That's haunting. It's haunting.
Another statistic is that the median tech worker never, at any point, gets more than 30 minutes of uninterrupted time. Ever.
Could you imagine trying to write something if every 30 minutes you got distracted, or every six minutes you had to check your email, or check Slack. You couldn't do it. You couldn't do it. It's impossible.
People don't get that deep work because they're constantly distracted by these communication tools.
So the goal of Async Week is to help people reorient around how to communicate with people.
Another thing is, people are generally uncomfortable sending videos, Loom videos, so we have to basically force people to do that.
They're used to either being in a meeting live, or writing an email.
Very few people, I actually honestly can't think of any companies, where a normal method of communication is to record a ten-minute Loom and send it to somebody.
And so we have to force people to do that for an entire week.
You send a voice memo, you can send a Loom video, but it's Async, and we try to push people to the point where it's intentionally past the point where it's useful.
Instead of giving a thumbs up to a thing, you have to say, on a Loom, it's like, "Hey, that looks good," and send them a three-second Loom.
It is not efficient to do that, but it shows you where that boundary is.
And it's almost always a lot further down the Async path than people are used to.
They're used to saying like, "Oh, okay, well, let's get on a call and sync on that."
That's how it works in almost every company. Think on that.
That's how it works in almost every company.
The number of people that I've spoken to where it is very common for people to have three or four meetings a week at Levels.
We talk about how we see companies who say no meeting Wednesday.
It's like a big moment for them. That's how we are.
That's exactly what we do. Exactly. No meeting Wednesday.
It's like, that's fine, but it's more common for us for people to have meeting Monday, which is the only day that they'll have meetings and then the rest of the week is open.
People just have lots of time to do deep focus work.
I would say that in many ways, Levels is an experiment and what happens if you turn deep work up to 11? I love that.
It's like what if you gave people the maximum amount of deep work?
There was a famous study that was done around deep work, which you may be familiar with, where they wanted to assess the quality of ideas because everyone fetishizes collaboration. It's like collaboration. We need to collaborate. Right.
And they severely undervalue smart people thinking deeply about something for a long time.
And there's a series of studies where they take a group of people and one group has, they have some number of hours to think of good ideas to solve a specific problem.
One group, they spend the whole time together at the table discussing and collaborating.
The other group spends half of their time writing and thinking by themselves, coming up with their own thoughts.
And then they collaborate at the end and they come up with their ideas for the second half.
And the quality of the ideas in the second group is always better because people have time to think.
They don't just get steamrolled by whoever the loudest voice is.
They also have time to, like I'm not an on-the-spot thinker.
Somebody wrote an essay, I'm a slow thinker. I wrote this. You wrote that.
So this is,- That's funny.
Fast twitch and slow twitch. Yeah.
And I think it's like runners, because I've worked with people and you'll be in a brainstorm with them and they're just ripping it.
They're like this idea, that idea. Yeah, exactly.
And everyone's like, whoa, you are so good. Yeah. They're loud.
They have a real presence about them.
And then there are these other people who, because I'd always sort of say, those are my best people. Right. Right.
Those are the best people I know.
And then I would work with people who would be in a meeting and then they'd say, "Okay, thanks. Let me think about that.
Get back to you in a few days." I'd say, "What?
You can't contribute right now?"
They're like, "Just give me a few days."
And then they'd come back with something really thorough, well-thought-out.
And it made me realize that they're fundamentally these two kinds of people.
And I actually think that the brain makes some sort of trade-off between super on the spot, can get it, right to it, but they just have a harder time kind of going in depth and really refining things and giving them order and structure.
And I've had to learn to really give credence to those slow thinkers.
And I think that this shows up in writing too.
There's people who are fast Twitch, they're sub stackers, they tweet all the time.
And then there's people like Robert Caro, he is a slow thinker and he'll take 10 to 12 years on a book, but then once he has something that's there, you know it's going to be really good and really well-thought-out. For sure.
Yeah, there's been many times when people have thoughts or questions or concerns and they ask me and my answer is, "I have to think about it. I don't know.
I don't know off the top."
I can't rattle off a new company strategy on the fly.
I'm going to have to spend two days thinking about it and writing about it and then we can have a really good conversation about it, but it's not just going to come to me from the ether.
Tell me about your think weeks.
Yeah, so I've largely just stolen this from Bill Gates.
I think he popularized the idea, but I found that if I don't intentionally block off time to think and to write and to reflect, I won't do it.
Things will just come up.
I won't be able to do it.
So I try to block off a full week per quarter,- Okay.
To just think and to write.
I try to avoid accessing my email or my team communications.
I will sometimes if I feel like there are things pending, I'll check it maybe an hour in the morning, but I try to be as offline as possible.
I do almost all of my writing just in notion.
What's interesting about is that I have found that it often takes two to three days of detachment from the hive mind before new creative ideas can happen. Oh, interesting. Yeah.
When you're in the flow, when you're in the day-to-day of this problem, that problem, it's really hard to see the whole forest.
And so the first couple of days, my thinking is usually very tactical and narrow of these are the problems that I see and this is how we should solve them.
And then as I get more and more detached from that over the week, I realize like, wait, why are we doing any of this at all?
Winning is going over there, so how do we get from here to there?
And that's where a lot, you may have noticed, a lot of the memos tend to be, they all have dates.
They tend to be clustered around the same month and year. I've noticed that. Yeah.
Yeah, it's like June 2020.
That was a think week and I wrote four or five memos.
They tend to be clustered around the same time period, which is often a think week where maybe I start by writing something very tactical.
I have on my next think week scheduled to write about our product development process because we've made a lot of changes very tactically.
I would like to just write it down so that we have a reference for how we've been updating it and like a source of truth on the updated process.
But over the next couple days I might think a little bit more about broader company strategy.
And so just having that space.
This was a mistake that I made at a previous company, which I was leading product and engineering and I was just so in the weeds.
I was in the weeds coding every day.
I think forcing myself to have that one week per quarter to understand what is the actual problem that's worth solving.
There are an unlimited number of problems in a startup.
Identifying what problems are worth solving and which ones you just have to live with, that's really what determines whether or not your company succeeds or fails.
Where do you do the think weeks and why do you do them with other people?
That surprised me, that you wouldn't just do it alone.
It sounds like there's dinners.
Now, I do like the social convention that you have of you don't need to be obligated to join for anything.
So if there's dinner, if there's lunch and you're like, nah, I'm going to flow, totally cool.
No social stigma against that, but why would you even do it with other people?
So I've tried a lot of different ways of doing think weeks.
I've tried it by myself, I've tried it in different locations.
I have found that there is something about, there's an energy that you get when you're around other people in the same mental space.
When you have two or three other people who are also heads down, you can see them across the room and they're like in deep flow.
It feels really motivating. It does. Yeah.
I found when I'm doing it by myself, I'm easily distracted and I just lose motivation pretty quickly. Right.
So there's something about, there's some energy that comes with having other people around that really is quite motivating.
That's really the best answer I can give for it.
So if you were to think about one week, walk me through what are your days like?
How much time do you spend reading, writing, thinking?
What does that think week look like?
So sometimes, because I have all of them, everything's in my calendar so I can actually specifically show you the last several think weeks exactly what I did, like every 15 minute increment. You map everything out? Yeah. Yeah. Huh. Yeah.
I know that I have one full day blocked for product development process.
I think the rest of them are just open, and so if I feel like reading, then I'll do some reading.
If I feel inspired to do some writing, then I'll do some writing.
If I feel like just going on a walk and thinking, then I'll go on a walk and I'll think for a while.
When you're walking, do you carry that notebook?
Yeah, I always have a notebook with me in my back pocket. Yeah.
I've just come to accept that technological tools are more powerful than my will, and so my phone is permanently on do not disturb mode.
It's right now on airplane mode.
If I pull out my phone to take a note, there is a absolute certainty that I will get distracted and I will often even forget what I was going to do. All the time.
It's like, oh, I'm going to take a note. Oh.
Oh, somebody texted me, let me get back to them.
Oh wait, what was I going to write down? Yeah. Where am I? What day is it today?
It's like I've completely lost what is going on because these tools just suck you in.
So I have to really create firm boundaries around my attention because my ability to manage that myself is quite limited.
Let's switch gears and talk about some of your public content.
The Levels blog has crushed. Yeah.
And let's start by talking about the ultimate guides.
Those seem to have done really well. Why is that?
So Mike Haney, our editorial director, his motto is, I think he got it from a book somewhere.
They ask you answer, but his motto is "Add value to the internet." I love that. Yeah.
So when he's thinking about a content piece, has somebody already written the most definitive piece on X?
And if we look around and we don't find one, we can actually add value to the internet.
We could become the definitive, the ultimate guide on topic X. Yep.
And it turns out there's a lot of lazy copywriters out there.
There's a tremendous amount of opportunity to make good content that is deeply researched and rigorous, and it turns out people like good content.
That's been our experience.
If you make really quality content that people want to read, Google likes you and they'll rank it really highly.
People talk about all these SEO tricks that you can do.
In our experience, the correct answer is just make the best content that people want to read. That's so funny.
We're starting rite of passage, this cohort, and we had a pair of slides and it said, and now we're going to talk about marketing and the best strategy for marketing will always be, and then I had a little speaker note for myself, pause, hit the next slide, it's got the answer.
I go write a damn good piece.
That is the best marketing that there is. Write a damn good piece. Yep.
And it's very similar to the Y-Combinator motto, which is, "Make something people want." Yep.
Which I don't think people fully internalize how important that message is.
The number of people who start businesses that don't generate revenue for three years because they're like, we're going to build this amazing product.
And I'll ask them, "Are you sure people want this?" "Oh, tons of people."
It's like, can you empirically prove to me?
The way that you do that, by the way, is they give you money for your product. Right.
Lots of people have told us that they want it.
Okay, well the only way that you can validate this is if they give you money for your product.
Otherwise, people don't want your product and you're just wasting a lot of time and money.
So yeah, sometimes these simple things just get completely overlooked.
It's like write good content, make something people want, talk to customers. Right.
These things are not that hard, but people just seem to not be able to do them. Yeah.
The other thing that I think it was Mike who wrote about this was he had this spectrum when he was thinking about what you were going to write about on the company blog, and on one side of the spectrum it was we're directly going to pitch our product and this is the locker from loop. Yep.
And then on the other side is here's going to be a magazine.
Here's going to be a series of content that people are just sort of going to kind of know that is affiliated with the company, but it's not going to overtly pitch the product.
And this is the REI Magazine. Yeah.
Instantly you kind of know what it's about.
It's obviously not about tennis, it's obviously not about gardening, but it's going to be about nature and hiking and all that, but it's not going to explicitly sell REI over and over.
And in your content strategy, you went about 80% towards the REI strategy.
It is definitely correct in as much as we're not pitching the product, like buy this thing, buy this thing.
But I think REI's goal is to like, it's more brand building.
In our case, it was when we started this business, nobody knew what the term metabolic health was.
So you're like education and teaching. Education. Yeah.
And so we had to explain what is glucose? Why does it matter?
Really, what is metabolic health?
Why does it matter and what can you do about it?
Those are the main goals.
And so we knew that there was a massive education burden.
That's why we did, I think Casey went on 100 and something podcasts to explain, like spread the message of what it is and why it matters.
The metabolic health crisis is not a thing people were talking about five years ago, and now there's New York Times articles have this in the headline.
This was a major goal of the editorial team, was make this something that people are aware of.
And so we knew there was such a burden because this is a totally new market and category, so we had to educate people on it.
So that was the main reason for it.
I thought some of the metrics that you track are pretty interesting.
Overall blog traffic, average dwell time on blog, average blog pages visited per session, article dwell time, article exit.
Did they stay on the site or did they leave?
Number of articles posted and then email signups.
Those are the things that you're tracking.
So we have millions of people that come to our blog and view our content, which is really great.
I think the stronger statistic is how much time people spend on our blog. Right.
It's in the order of minutes.
People will spend three or four minutes on our blog.
That means they're reading all the way through the content.
They're spending a lot of time reading our blog posts.
And that's, I think speaks to the quality of it.
Similarly, the podcast downloads, the YouTube retention for things that we post on YouTube.
People really care about this content, and if you make good content, people will stick around and they'll pay attention.
To get back to the company blog, there's a line from CloudFlare where the CEO said, "Our blog really took off when we realized that it wasn't for customers, it was for employees."
How much employee oriented blogging do you do or prospective employee blogging do you do?
So we have two different channels. Okay.
We originally did them all in one feed, but we have a Levels company blog and podcast. Oh, really? Yeah.
Well, I've been on the podcast, so I know that. Yeah. Yeah.
It's internal where things that we want to post that are not going to be really public facing. Sure.
We might post them on Medium or we might post them on, I think we have Levels Culture is the YouTube channel where we have conversations with people inside the company and we publish it externally.
And it's interesting how people really resonate with a lot of the content of understanding how ideas came about and how we operate as a business.
The idea came from, do you know Zach Cantor? I love Zach Cantor. Yeah.
When I met with him in Miami, at some point he mentioned how if he could go back in time, he would've started a company podcast, internal to the company to keep everyone up to date on what's going on in the business.
And I basically just took that and ran with it.
And there was actually quite a lot of resistance internally of it's too much effort.
It's not going to be worth it.
But Ben on our team who runs growth for us is very scrappy, and everyone that we talked to was like, "You're going to need a producer.
You're going to need an editor.
You're going to need a full-time staff of five people to do a podcast."
And Ben was like, "I'll do it today." It's like, okay.
I mean, if you can do it in one day, then sure. It's worth a shot.
And it's ended up being extremely valuable.
It's one of our best recruiting tools.
One of my favorite things that you said is you were talking about some Loom video that 45 people watched. Yeah.
You're like 45 people watch that and people have this default assumption that content needs to be seen by the millions. Yeah. Yeah.
And I get why that exists.
And obviously if you're trying to make a business out of the content, it needs to be seen by a bunch of people.
But if you make a Loom video, it's 30 minutes long, 45 people see it and get to the end.
That is 45 people who didn't need to be in that meeting who could watch it on their own time.
And I think that you have a strong intuition that those 45 people are very undervalued because for whatever reason, the frame that we think around content is so correlated with broad scale. Totally.
And it's the same thing for the company podcast stuff, where a lot of the people who apply who want to join the company, they'll mention how they listen to a bunch of our podcasts, and that's what inspired them to want work here.
And those are podcasts that might've only had 100 people listen to them. Yeah.
But those are the 100 people that you want to reach.
I often have to reframe this for people on our team when they're like, "Why are we even posting these?
These only get a 100 views."
It's like if you had, that was a meeting we already did.
There was almost zero marginal cost to post this externally.
If you imagine we had that same meeting and 100 people sat in on it, you would say, that's the biggest meeting we've ever had.
But because you're comparing it to a YouTube video that gets 10 million views, we frame these things all wrong. Right.
So I'm going to give this to you so that you can look at this if you want for the answer.
So we'll put it on the screen.
Here is a chart of how your time spent has changed, and I think it's interesting that information processing has become so much more, but I want to just focus on the writing. Yeah.
In what ways are you writing more?
In what ways are you writing less?
How has the nature of the reading and writing that you do changed?
Yeah, I tend to do during different stages of the company, I flex into whatever role is needed.
I can send you an updated version of, because I still obviously keep track of all this stuff. Please do. Yeah.
So I can give you the,- What tool do you use to keep track of all this?
Google Sheets and Google Calendar. What do you do? Clock in, clock out?
No, so I just keep it all on my calendar.
I just use Google Calendar and I just keep track of where my time is going. Got it.
And then my EA, I think every couple days will go through and just translate that and categorize it. Okay.
I found that's the simplest, most flexible system.
I've tried basically every tool under the sun to try to use it as a product.
And I find that the simplest answer is just, it seems like almost every solution ends up just becoming a spreadsheet. Yeah.
It's like it's the most flexible.
Do you have time in your calendar for distraction and for just wandering?
Because this is an important thing that I see in my own writing is it's hard to quantify, but there is a kind of loosey goosey, I'm just going to kind of do whatever distraction that actually yields a lot of good new ideas.
I find that a lot of my best time reading, like last night, I had trouble sleeping because I knew I was going to wake up early for this podcast.
So I was like, sometimes the night before, I can't sleep very well.
So I got out of bed, I just was reading for two hours and I find that, whoa, those moments can be so inspirational.
But I've never really found a way to systematize them.
How do you think about that?
So often when I block off a big chunk of time for writing or for coding or for something, sometimes I feel like the best thing for me to do right now is to go on a long walk and just listen to something meditative and think.
And then would you re-categorize that after the fact in your,- I would just include it as part of strategy. Got it.
Whether I'm physically writing or whether I'm sitting or walking and thinking, if that is the intent of what I'm doing, then I will include that as part of the category. Okay.
So the 5% of time that I spend on strategy includes time that I'm walking around and thinking.
And so like I said, if I'm doing 5%, I think most people are doing massively less than that.
So let's get back to how has the composition of writing that you do changed?
I try to produce a company strategy document about once a quarter. Okay.
I think that sometimes the company strategy doc ends up just being basically the same as it was the last quarter.
It's like nothing's really changed.
Stay the course, which is a useful thing to recognize. It's like,- Yep.
The same strategy, which is working, we should just keep doing that.
Other times there's been a radical shift.
It's like realizing that this is not going to work anymore.
We need to completely change the way that we do this.
We need to go in this completely different direction.
We need to have a bunch of meetings.
We need to align on this.
We need to change the way that we're building this stuff.
So I'd say a lot of it has to do, recently a lot of it had to do with how we build software.
I've taken over the engineering org, the product org, the design org.
I now lead all of those now.
The recognition is how important it is to empower engineers to deliver on their own projects.
I think having the people who know how to do the thing should be the ones making the decisions.
That's maybe the simplest principle.
If you don't know how to write software, you should probably not be the person who tells other people how to build software.
And so giving engineers that control over their own time has really, really increased our velocity.
And so a lot of my writing has been around philosophy on product development and software development generally.
How we work between teams.
We've taken some ideas, we don't do it religiously, but the PR FAQ is an idea that we took from Amazon.
Yeah, tell me about that.
The idea is that I really like it, at least in principle.
In practice it's often more challenging to implement.
But the idea is that before you even start working on the feature, you should write the press release and the FAQ for the thing that you're about to build.
And if you can't put together a compelling press release and put together a set of FAQs on what it is you're going to build, you're probably not going to be able to sell it. ...
FAQs on what it is you're going to build, you're probably not going to be able to sell it, and if you can't sell it, you probably shouldn't bother building it.
And so it's a good practice of integrating marketing into the process of building products. I think where ...
Tying back to Brian Chesky, he mentioned how dysfunctional product teams, the dynamic is the waiter and the chef, where the way that it will work in a dysfunctional org is the chefs are all doing their thing and then they deliver something. It's like, "Here. Here's some gnocchi."
And then the waiter's like, "Okay, hey, does anybody want some gnocchi?"
And people are raising their hands and, "Okay, here you go."
How it should work is the waiters talk to the customers, they bring it to the chefs, they talk to each other, they figure out how to do it, and then they bring the thing that the customer wanted to them.
In an ideal world, you wouldn't even need the waiters.
You would just have the chefs talking to customers, making the stuff that they want.
Sometimes you do need some specialization where they need to be cooking more than talking to people, but you still need some degree of understanding among those groups.
So a lot of what I've been writing recently is we have not done a great job of product marketing.
We've done a really good job of building this category of metabolic health, doing the writing around that, of building a really strong go-to-market engine.
But the writing that we need to get better at is explaining what our product is and why you should use it.
And part of the reason why I think we've done a poor job of that is our marketing team and our software team have not been very well integrated.
So a lot of my writing recently has been about that.
You were talking about when to write a memo and when not to write a memo.
And Bezos talks about one-way door decisions and two-way door decisions.
So a one-way door decision, you make it and it's like getting a tattoo.
Once you get a tattoo, it's on your body forever.
And then a two-way door decision is much more like a hat.
You can put on the hat, you can take it off.
And with a two-way door decision, you can just ship.
But with a one-way door decision, it makes sense to write the memo because the cost of a bad decision not just can be expensive, but if it's the wrong one, it can destroy your company.
So those one-way door decisions that are expensive, that is the bullseye for when you write the memo.
Absolutely, and I would say in addition to one-way versus two-way doors, I would also say take into consideration the resource cost of whatever it's you're going to do.
If a thing only takes a week or a couple of days or even a couple of hours, you don't need to write a long memo.
But it is useful to train your ability to know whether your hypotheses are good or not.
If you just write it down, you can write it down one sentence.
It's like, "I think in two hours I can do this and it's going to have this outcome." Cool.
That's all you have to do.
Just write it down and then go ahead and do it.
So yeah, the more consequential the decision and the more expensive it is.
Even if it's a one one-way door, some one-way doors are just not that expensive.
It's like, sure, we can't go back from it.
If it doesn't work, who really cares? It's not a big deal.
What do you think GitLab got so right about their internal writing culture?
I think we benefited a lot from their experience and we've taken a lot from them.
The thing that is probably very similar to GitLab that we also benefit from is preferential attachment, which is it's in network theory, but it's the idea that once you've created, say in our case, a culture that attracts a certain kind of people, more of those people will come to you.
So you end up with this compounding effect where every new person that you hire is actually additive to the culture because they are seeking you out because that's what they're looking for.
And so GitLab with their writing culture with a lot of stuff, people now know, if I want to work at a remote company that has this type of culture, I should work at GitLab.
So as you develop a culture where people know what it is they're signing up for, you attract more of the same people who have similar values and you end up with a culture that compounds with these things.
So I was talking to somebody recently, I'm trying to remember the context.
They were describing, how do you make a culture that is resilient to the people in the company?
It was an interesting thought.
They said, "How do I know that after I leave the culture of this business will persist?" Sure.
"How do I build a culture that is so strong that no matter who we have in place, the culture will persist?"
And I hadn't really considered that because in my mind the two are inextricably linked. Right.
The people are the culture.
The people are the culture, or they're the manifestation of the culture and the culture is the ...
They're completely the same thing to me.
So we talked about it for a long time and ultimately the conclusion was like, this is not possible.
If you have a really great culture to start with and you allow in a few people that are banned ...
There's advice that I got from Marc Randolph from Netflix early on.
He said, "People notice what you tolerate."
And if you hire people and you say, "This is the culture that we have," and then people notice that not everybody is following that, you end up in a really bad spot because people know that you're not to be taken seriously and that your words don't actually matter. Right.
He also said, "People notice who you fire."
If everyone knows, "Well, so-and-so, we say that we do X, but so-and-so keeps doing Y and I guess they don't care."
And then that person gets fired, like, "Oh, turns out we do care."
That's actually a really good sign.
And so knowing- Do you promote writers? Do we promote writers?
I would not say that I've thought about that specifically.
I would say that people who are effective at communicating their ideas tend to get promoted.
Now that usually is in the form of writing.
Is it strictly in the form of writing? Not really.
Some of our engineers don't really do a lot of writing, but they work with people.
They're paired with maybe somebody from our support team who helps them write these things out in a really compelling way.
It usually involves some artifact that convinces me that they know what they're doing and it never happens in just like a free-form conversation.
How does writing help you delegate?
I think you have 12 EAs, 40 some people at the company.
So delegation is a huge thing.
Anyone has access to that pool of EAs.
What are some of the best things to write so that you can improve your delegation?
I think one of the biggest things around writing is how it develops trust.
So you can really only delegate something to somebody if you believe that they will do the job correctly.
If you hand something off to somebody and you feel like you have to constantly check in on them because you don't know if they're going to do it on time or they're going to do it well, that's not a good situation to be in.
You really can't delegate to those people if they're inconsistent or you question the quality of their work. Right.
If they can write something, if they can show over time ...
I've used the term proof of work as another one where writing a long-form memo is the proof to me that you have done the work to understand your industry, your field, that you know what you're doing. Society feels this way.
I gave a talk last week and a guy comes up to me after and he goes, "Hey, do you have a book?" And I said, "No."
And he almost looked at me like, "Huh, I don't know if I have that same trust in you."
But I think that as a culture, this is how we think about people.
It's like, we don't even need to know how good your book is, but just by the fact that you have a book that you can hold, we're like, okay, we all know that that person has at least thought way more about this than the average person. Yeah.
I was talking to somebody recently about this on the concept of genius, which is interesting because it's just a word that we use colloquially all the time.
It's like, "Oh, he's a genius."
We use it often in terms of, "He's really smart" or "She's really smart, she's a genius."
But the interesting thing about the phrase and how it originates is actually it originates more from the term generate.
Genius and generate are much more similar.
It's like a person who's created a masterpiece, a masterwork, it's actually more the act of the creation.
It has very little to do with how smart the person is, to be a genius, a genius is somebody who has created something spectacular or something of value.
And so writing a book could be a work of genius as opposed to, "Somebody is a genius because when I talk to them, I think they're smart."
Have you heard the Schopenhauer quote on this?
He says, "Talent is hitting targets that other people can see.
Genius is hitting targets that other people can't see."
And I think that there's something to genius there too, which is, and this gets back into why we write, gets back towards the product strategy, is so much of leadership is looking at the white space and knowing where to go when there is no real sense of structure or direction and kind of creating the map for people.
I have a friend who calls this The Person With The Map.
Who is The Person With The Map?
Who knows where we are now, who knows where the roads are going, who knows where the final destination is, what is the delta between here and there?
And they're the person who can provide that map.
And I think that a lot of what writing does is it gives everybody the map. Yeah.
It is remarkable to me how we seem to just reinvent the wheel all the time on this stuff, as I'm sure he would probably be the first to admit, Ryan Holiday doesn't have a lot of new material in stoicism.
It's really repackaging wisdom that's been there for thousands of years and making it approachable for people so they can actually understand it and make use of it today.
And there's a tremendous amount of value in that repackaging and making it so that people understand it and can apply it to their lives.
And then on the flip side, this isn't to criticize him at all. Yeah, of course.
But I think within a company is writing things down so that things don't need to be recreated.
I bet that there's a trillion times when somebody's like, "Hey, what's going on here?" Even for this podcast.
So I thought it was interesting, and I'll put the, if you'll give me permission, put the email on the screen, the one that your EA sent me right before we got coffee. Yeah, sure.
I thought that was interesting.
It was sort of here's a list of things about Sam that you might want to know.
Product strategy, things that you're thinking about.
So I could read that beforehand.
And there were probably 20 links in there, but then we were like, "Hey, we should record a podcast together."
And we agreed, "Hey, we're really going to through what it is that we want to talk about," and you just sent me a link to all these internal documents and I just went through, found 15 documents or so that were writing related, looked at those, and then it had 16 pages of prep notes and that took you no more than 5 minutes.
Oh, it took me a couple seconds.
I have a snippet already. Of course, you do.
I just did command apostrophe, long for long-form, and then I press return, I send it.
It was maybe five seconds. Yeah. That's crazy.
Saved us both a lot of time.
Yeah, and that is I think the essence of why it helps so much to write. Yeah, definitely.
Let's end with retrospectives.
We talked about hypotheses.
Earlier, we talked about the scientific method, but there's got to be a retro at the end. How do you do those?
The important thing about the retros is one of the things that we've changed about this process, which has been really positive is we eliminate any subjective terminology of like, this project was a success or this project was a failure because everybody will rationalize their project as a success no matter what the result is.
Because it's like if it completely and utterly failed to say it was a success because we learned something and that's really what we're here for.
So we use language like, "Did you validate or invalidate the hypothesis?"
That's just a clinical definition.
You said it would go up by X, it went up by less than X.
You have invalidated the hypothesis.
Success or failure, it's irrelevant.
Our subjective take on whether or not this project failed doesn't matter anymore because we're just using clinical definitions.
That has helped a lot because it makes it a lot harder to rationalize these things when you just have these clinical definitions.
So at the end of the project, most projects will have some validation period, which may be a week, two weeks to collect enough data, then we write the retro, we explain what happened, we align on next steps and then we go from there.
So the retros are things that are easily overlooked, because we're like, "Well, we already finished it, let's do the next thing." But you have to reflect.
Did the thing happen that you thought would happen? Why or why not?
How do we make better decisions in the future?
There were a few things I picked up on my research.
One was expected to take 10% of the time of the project.
Another was the interviews.
So people interview different people, I want to hear about that.
And then I want to hear about once the retro has been written or the information's been codified, how then do you share it with other members of the team so that you have organizational learning and not just individual learning?
We have 10% as a rule of thumb of people don't know how much effort should into a retro.
I would say 10% is a reasonable amount of time for somebody to commit to reflecting on the learnings from that project.
And so that means if you did a two-week project, that's one of those days is dedicated to writing the retro.
If it's a four-week project, maybe two days on the retro to think about how it went, what you can do better.
This is not like a rule, it has to be 10%.
It's just that some people think that maybe the retro is way too big or way too small.
If they do an eight-week project, spending one hour on the retro, definitely not enough time.
There's no circumstance where one hour is enough time to write a retro on a project that just commanded like tens of thousands or hundreds of thousands of dollars of resources.
We need to know, was that a good use of resources?
And is there something we can learn from spending $200,000 that will improve our decision making next time, even if it went well?
The other thing that we have is part of the retro process is interviewing everyone who was part of that project.
One of the pieces of feedback that we've had pretty consistently is that people often don't feel like they get enough feedback from their peers.
And we implemented this quite recently and it's been really, really positive, which is we use every retro from every project as an opportunity to collect feedback for their peers. Wow.
So if you work with three people on a project, each of those three people and you will be interviewed like, "How did this project go?
What was it like working with these people?
Do you have feedback for them?
What can they do differently that would go better?"
So we use that as a hook for better because we've tried all these different ways of a quarterly review process.
But we found that when it's project specific, those people have so much more context.
They're already in the moment with those people.
And so you can get much higher quality feedback and you can do it with a much higher cadence as well.
That's been really positive.
The last is around communication.
Funny thing about the scientific method that most people don't appreciate is that communication is actually part of the scientific method. It is the last step.
You do the analysis and you communicate it to the world.
If you cure cancer and nobody else knows about it and nobody has used your solution to cure cancer, did you actually cure cancer? I don't think so.
I think it actually doesn't count.
I think epistemologically you have not cured cancer.
You've just solved an interesting novelty. That's it.
Curing cancer means you have disseminated that information and you have solved this problem.
So in the scientific method, if you have discovered something, the last step in the scientific method, if you just go to Wikipedia and you look at the scientific method- Really? Yeah.
Communicating the results of your experiment is part of the scientific method. I didn't know that.
Yeah, A lot of people will say like, "Oh, scientific method is like write a hypothesis and then do an experiment." Yeah. It's like, yes.
And then you have to analyze and write a retro. Did the experiment work?
Then communicate the results of that experiment to everybody. That's the last step.
People often miss the last step and the second to last step.
And you do that in a memo and then your Friday meeting? We do that in a memo.
We do it in often redundant ways.
So we'll do it in a long-form memo that we share to the whole company.
We'll do it in the Friday forum, which is our team all hands, and we'll do it like a short summary segment so that people can learn.
Often, we limit that to a very bare bone summary of like, "We did this thing, this is what happened."
And then ideally, if there are learnings that we can percolate to the rest of the team, we'll do it there.
We also go over retros in the engineering forum, which is the whole engineering team, and we tend to go over the learnings that are specific to engineering.
So one of the projects might have 10 takeaways, and then 2 of them are somebody might say, "Hey, I learned in this project that our deployment pipeline is actually really cumbersome, so I recommend that we do a sprint on this sometime in the next couple of months where we spend at least a week updating this because it delayed the release of my project by a week.
And then I discovered this other issue where our packages are out of dates and maybe we need a new process once a week for the person on call to update our packages so that I don't have to spend three days fixing package misalignments."
It's like that's really good feedback and it's very specific to that forum. I lied.
That was my last question about business.
I do have one more question that is deeply aligned with one of my spikiest points of view, which is that our obsession with the news and the here and now is rotting minds and making us stupid.
You did a month of news sobriety, and I want to hear about that. What did you learn?
What was that experience like?
And what have you changed?
Yeah, I mean, I did a month of news sobriety 11 years ago, and I have been news sober ever since. Is that right? 11 years. Yeah.
I had this recognition that I was compulsively checking the news, that it was occupying a lot of my mental space, that I was fearful and angry about things that I had no control over that oftentimes turned out not to be real to begin with, which is kind of a weird thing that we do to ourselves.
And so I read Ryan Holiday's book, Trust me, I'm Lying. That's right.
And it really changed my perspective on this.
And I committed to not consuming social media or news for a month and to just replace that time with reading books.
And I went from somebody who reads maybe one book a year to reading eight books in one month.
And everything about my life was better.
I felt less stress, I felt physically different, like my neck hurt less. Wow. I felt lighter.
I felt like a level of flow and thought that I had maybe never felt before just being released from this compulsive need to check things.
And yeah, I've never looked back. It's been 11 years.
It was 2013 when I did that.
And a funny thing that happens when you are news sober is that people will often bring things up in conversation, assuming that you know it.
I'm trying to remember the last specific example, but someone was like, "Oh my God, have you heard about such and such?"
I was like, "No, what's that?"
They're like, "Oh my God, how don't you know?
It's been all over the news?" "I don't know. I missed it. What is it?" And they would tell me.
It's like, "Oh, does that matter?"
They're like, "Maybe not."
It's like, "Oh, well, it sounds like it's been occupying a lot of your mental space over the last few days, and if it's not important, why are you paying attention to it?" I couldn't agree more.
And then when you have your reading time, how do you think about occupying that time? Is that internal memos?
Is that I only read books?
How do you think about that?
I almost exclusively read books, and there's a heuristic that I stole from somebody, I actually don't even remember who it was at this point, who their heuristic is they only consume content that took the creator 100 times more to write it than it will take them to read it. Nick Maggiulli. Is that who it was? Yeah.
I was like, that makes a lot of sense, of compression of thought and information.
I think you nailed that idea. Yeah.
So books are one of the few places where I think you really get that.
There are some specific interviews and podcasts that I will read or listen to, I should say, where there's clearly just a condensation of many, many years of thought and knowledge that's just been condensed into one package, even though it's technically not a book.
And it only took them one hour to record, it took them a lifetime to accumulate that knowledge.
So I've managed to do 2 books a week since 2013 simply by replacing news consumption with books, just like a one-to-one trade.
So yeah, highly recommend it. Nice.
Well, thanks for doing this. Thanks for geeking out. For sure. Good to be here.