SEASON 2 - EPISODE 0052 - FEB 15, 2023

Hire Great Writers

Writing is crucial for communication and collaboration in both remote and in-person organizations.

But how do you find and hire great writers?

Today, Jason Fried and David Heinemeier Hansson sit down to share why writing is at the heart of the success of 37signals and why they believe it’s essential for every employee to be a skilled writer, regardless of their title or role.

Listen in as they walk us through the process they use to “Hire Great Writers” from their book, REWORK.

Join us to learn about the critical role that writing plays in collaboration, clarifying ideas, and unlocking solutions to the problems that have been keeping you stuck. Plus, discover how the developers at Basecamp and HEY are using writing to showcase their skills and share the solutions to their challenges.

Show Notes

00:37 - Jason shares why the cover letter is the most crucial aspect of the hiring process at 37signals.
01:34 - David shares how writing works to both set the tone for collaboration and as a ‘magic filter’ for eliminating BS.
02:26 - The personal scrutiny filter to use before you bother other people.
03:14 - The key to unlocking a stuck situation.
04:18 - The magic of writing and a few of the by-products.
05:17 - Meetings are toxic; why writing is a better way to do the bulk of collaboration.
06:23 - Why 37signals asks you to “show your work” during the hiring process.
07:53 - Why it’s a good idea to “treat code as prose.”
08:39 - No jargon required: designers and programmers need to be able to speak a shared language for a successful collaboration.
09:30 - For more behind-the-scenes, check out the technical blog at dev.37signals.com, where the people who build Basecamp and HEY share about their work, the problems they’ve run into, and provide insight into how they’ve solved them.

Links & Resources

Do you have a question for Jason and David? Send us an email or leave us a voicemail at 708-628-7850.

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m your host, Kimberly Rhodes. In last week’s podcast episode 37signals co-founders Jason Fried and David Heinemeier Hansson discussed their philosophy behind hiring managers of one. This week we’re talking about another one of their hiring suggestions, which is to hire great writers. They talk about this in their book REWORK and they’re here to talk about it today on the podcast. Guys, let’s jump right in. I understand from the book that you two think it’s important for everyone at the company to be a good writer, like regardless of their position. Tell me about that.

Jason (00:37): Yeah, there’s a number of reasons for it, and it starts in the hiring process. So the first thing we look at is the cover letter, and it’s kind of the only thing we actually look at, uh, initially, like we get a cover letter, we get a resume. Resumes are historically kind of BS. They’re just, you know, bullet points summarizing the best possible read of a history, which is fine, but the the real tell is in the cover letter because that’s where you can see who this person is. Like, do they want this job? How do they explain themselves? Are they clear thinkers? Are they creative presenters? Whatever it might be, that’s where it begins. And it’s important because the majority of our communication here at 37signals is written. Since we don’t have a lot of meetings and we don’t do much else to get, we don’t get together in person very often, you have to write. You have to explain yourself very clearly by writing, by thinking out loud, in words that you put down on the screen. And that’s, that’s it. That’s why it’s so important for every single position to, to be able to, to be a good writer.

David (01:34): And I think it really also just sets the tone from day one that this is how we collaborate. If you’re gonna struggle writing an application, you’re really gonna struggle once you show up on the first day. And what you’re met with is a chat room and a bunch of messages. And these are the ways of, of communication. But I think it’s not necessarily just something that’s relevant for a completely remote organization. And one of the first topics I remember I was talking to, to Jeff Bezos with when he, uh, uh, bought a small slice of the company back in 2006, was this idea that he right from the get-go, installed the idea that his meetings and they were, uh, company with, with tons of office spaces and actual meetings, but they would start with reading a memo that someone wrote up, that it would basically start as a silent meeting as though they were remote.

(02:26): That first you have to read through someone having thought through why are we here, why are we having a meeting at all? Cuz I think this is one of the great clarifying things about writing is that you think you might have this, uh, crisp concept in your head and hey, let’s just call a quick meeting and we’ll just hash it out. And your concept is not crisp at all. It’s totally crumbled. And if you try to straighten it out on a piece of paper, you realize just how crumble it is. And sometimes you’ll realize, oh actually this is a terrible idea. Uh, why even call a meeting at all because this is not worth meeting about because either I haven’t done my research and there’s more work to be done. Or the idea is simply poor, it falls apart under your own personal scrutiny, which is the best possible time for an idea to fall apart before you bother other people with it.

(03:14): If you can exact the scrutiny of simply trying to commit it to words. It’s interesting becaus e it’s so similar to how programmers often get stuck. They get stuck on something, um, something they’re dealing with. And if you force them to first write down how they’re stuck so often they will solve their own problem. It is this act of trying to explain in clear writing where you’re stuck, that provides the key to getting unlocked. So I think that’s, that’s, that’s really the forcing function is to really force all thoughts through this funnel of writing. And there’s just so much crap that gets filtered out. You can bullshit a whole lot, which is actually funny – On this podcast, one of the things I enjoy doing afterwards is to read the transcript. And sometimes I have in my head that I was really crisp and I was really on point and I’ll read the transcript or something I said and it was like, yeah, no, that wasn’t crisp, but that wasn’t on point at all. Writing is the magic filter for taking off bullshit.

Kimberly (04:18): Well, and it’s interesting because David, I assume that if we didn’t have such strong writers, you guys wouldn’t have been able to just spin up a blog like the developer’s blog that you guys have. That’s not something you could just all of a sudden be like, yeah, I wanna do a blog, if you didn’t have people who could really express themselves well in the written word.

David (04:34): This is the second magic of writing, is that there’s so many by- products. So for example, if we write up a proposal, rather than call a meeting with three people, that proposal gets (a) to live forever (b) to be read by someone else coming along, wanting to learn something about that project later. So this is why, for example, we just recently had this discussion. We were having these uh, betting table meetings when we were deciding on what to do with the next, um, cycle of work we were gonna do. And they were, the betting table was growing because we had more people, more teams, more folks who had to be involved. And we were having a hard time cutting down on that. And all of a sudden we are looking at a meeting of, wait, are we gonna be seven or eight people in this meeting? That doesn’t feel like us.

(05:17): We have other essays talking about how meetings are toxic and they get extra toxic the larger they are. What was the answer? The answer was to solve it with writing. Solve it with the bulk of that work happening as written products that eight people can look at or 10 people or 14 people can look at. It doesn’t really matter. It doesn’t have this exponential function. Meetings get exponentially worse the more people are in the room. Writing? No, completely linear. Completely linear. Someone can read a writeup that we, uh, detailed. Brian for example, can write up a pitch about some new feature and if you have five people reading it, it’ll take them a combined what, five minutes to read or 10 minutes to read. And if, if you have a few more, it’s a linear curve. It is such a better way to do the bulk of collaboration that isn’t happening in this sort of, um, realm that can only be sorted in person. Which to be fair, there’s also some of that. We’re not saying replace every human interaction ever with totally considered writing. That’s not what this is about. Just like, you know, the bulk of it.

Kimberly (06:23): So Jason, you mentioned the cover letter being how you guys find good writers. Are there other parts of the hiring process, cuz I would think that cover letter’s just that, you know, first thing to get you to stand out when you’re trying to decide between candidates, how are you using that kind of writing strength in that process?

Jason (06:40): Yeah, I can only speak to the design hiring process cuz that’s the part I’m part of. But what we do at the end of the process for the last few people is we give them a project to do. We hire them for a week actually to do a project for us. And even though it’s a design project, the deliverable is essentially a write up of what you did, and why you did it, and your thought process. And however you wanna present, whatever you wanna present, but you’ve gotta write it up. And that’s another place where you begin to separate people, uh, great design work but can’t explain themselves or you know, really good explainers, but like they didn’t, they spent all the time explaining and kind of fell apart on the work. You kind of wanna see a good balance of both. But primarily what we’re looking for besides good work is the ability to explain yourself and make a pitch, like persuade or explain or talk about the things you didn’t do, whatever it might be, however you wanna do it. But that’s another great giveaway. Can this person, you know, basically speak for themselves? Can they present an idea on their own and make a case, if they’re not able to stand up in front of five people verbally and present, you know, so that, that’s a big part of it too.

David (07:53): We have the same thing on the programming side. Every programmer will do a take home test. It’s a little shorter than the one we do in the design, but it is also a form of prose. First of all, you’ll describe in prose how you’ve solved something, but you’ll also describe in prose through your code. This is one of these big things for us that we treat code as prose. I analyze code in much the same way as I was analyzing prose – Are you succinct? Are you clear? Are you picking the right names and terms for things you’re trying to implement? If we were to sit down with a designer who’s not fully versed in all the code stuff, would it make sense to them? So much of the work that we do is this collaboration between designers and programmers and we need to be able to speak a shared language.

(08:39): So if you’re coming at it as a programmer who can only speak in heavy jargon, who can only use these esoteric terms to describe things that maybe some other programmers will understand, that’s really a ding. And I think this is actually also one of the things that serves quite well to separate some types of programmers who perhaps can end up being very impressed by the um, specific jargony terms that they’ve accumulated over a long career. And you’re like, that’s not actually a benefit to you. The benefit is if you can understand those things but then explain it to, I was about to say a layperson, but that’s not what it is. Our designers actually do know code, they’re in it, they understand it, but it still has to be clear and succinct and that just comes across very easily when you look at a piece of code as you would at any piece of prose .

Kimberly (09:30): Amazing. Well I think this is very straightforward. Before we wrap up, David, I mentioned the developer’s blog. Do you wanna tell us a little bit about that and what people will find over there?

David (09:39): Yeah, so we just started the developer’s blog. It’s at dev.37signals.com. Yes, that’s right.

Kimberly (09:44): It sure is.

David (09:45): It’s a great example of what happened when you look for great writers when you hire, because lo and behold, there’s a bunch of great writing on that blog, not just great technical content. Sometimes you can have great technical content that is not very well presented, it doesn’t have a clear story, it doesn’t speak to you, but these pieces of writing, they’re actually great pieces of writing. And why are they, because we hire great writers, because we put such an emphasis on the fact that even technical individuals have to be good writers. And that is different. And it is possible, to some extent, to be a strong technical person and not be a greater writer. I tend to think that there’s actually a fairer degree of overlap because clear writing is clear thinking, but I’ve seen exceptions. I’ve seen exemptions where there are technical people who can be really good at this one thing and aren’t great at writing.

(10:41): And you know what, that’s just, we’re not a good place for that because as Jason says, so much of the collaboration and here you have to work with other people depends on that. So the blog really takes this approach of sharing and telling about our work. All the problems that we’ve run into, hey, here’s how we solved it and here’s what we thought through when we were solving, explaining your work. You could basically say any one of those articles could have been a job posting, could have been almost like a cover letter, could have been a submission to one of these at home tests we did.

Kimberly (11:14): Perfect. Well with that we’re gonna wrap. REWORK is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. And for that technical blog David mentioned you can go to dev.37signals.com.