Subscribe
Share
Share
Embed
On last week's Rework podcast, Jason Fried and David Heinemeier Hansson, co-founders of 37signals, joined host Kimberly Rhodes to answer listener questions about their approach to design, decision-making, and more.
Today, they return to tackle more listener questions, covering a diverse range of topics such as delegating projects, hiring, and remote work.
Listen in as they discuss their strategies for helping team members take ownership of their work and their tips on deploying projects. They also offer advice on attracting and retaining the right talent and discuss the role of communication and culture in building a successful team.
Show Notes:
[00:26] - Sarah McKenzie asks for tips on delegating projects rather than tasks and helping team members take ownership of their work areas as she wants to move in this direction with her small team.
[01:23] - Jason explains how Basecamp delegates projects instead of tasks. In contrast, team members are given a rough general idea of the project and some ideas for the interface design, and they figure out how to get it done in their own time.
[02:57] - David adds that even new employees and junior programmers can handle owning a whole project.
[04:38] - David shares that Shape Up's idea of a fixed time frame and flexible scope interlocks with delegating projects.
[05:32] - Let people live up to high expectations and see who does it quickly and best. Delegating a project means evaluating work based on outcomes, not effort, allowing team members to make decisions and run autonomously within the project's scope.
[06:28] - Julio Caesar from Sao Paulo, Brazil, asks DHH about the day-to-day work in a team of two, specifically about code review, pull requests, and dev to production deployments. He's concerned about the time wasted in long change management meetings and how to avoid having someone who doesn't know anything about the project approve a deploy.
[07:11] - 37signals has teams of two working on different aspects of a product, with any given feature having a designer and a programmer working on it.
[08:24] - David shares that the company has a process where someone is responsible for the quality of the work that goes out the door. There is a mentorship process for new hires. Programmers and designers review each other's work.
[08:40] - In the Seven Shipping Principles, there is a notion that if the person is confident that the deploy is low-risk, they are not obligated to get a review. Even CTOs and senior employees sometimes request a review to increase their confidence. The team encourages individuals to have a strong sense of confidence and delegate the responsibility of reviews to themselves.
[09:22] - The review process is asynchronous and shouldn't be a blocker.
[10:29] - Jason shares that although anyone can deploy work, the company has never had a catastrophic deploy in its history. And rollbacks are very rare.
[12:38] - A mystery caller asks David and Jason if they have any rules, constraints, or systems in place to help them decide when to grow and when not to grow, specifically around headcount and staffing.
[13:02] - Jason explains that their hiring is department-based and based on specific needs rather than global goals. They follow the principle of "hire when it hurts" and aim to alleviate actual pain rather than future pain.
[15:16] - Having two people is better than one—David shares an example where they had only one person in a role, and it was difficult for them to take a vacation or sabbatical without affecting the company. He also suggests that companies should consider redefining a role when someone leaves rather than simply refilling it and only hiring when necessary.
[17:54] - Jason emphasizes the importance of the "hire when it hurts" principle, especially for startups. He advises it's better to wait for reality to show what is actually needed before making hiring decisions.
[19:15] - Jason and David discuss the practice of hiring defensively, which involves hoarding talent and contributes to the malaise of Bullshit Jobs.
[21:06] - David talks about his experience of having a job where it didn't matter if he did anything and the cruelty of putting people in that position, not to mention the ding on the economy.
[23:23] - Listener Bhagyesh asks how to find team members that align with work principles and help the business grow without traditional supervision.
[23:48] - Jason says they find team members through word of mouth and by writing detailed job ads. They get many applications per role but narrow them down by talking to candidates and having them do a small project.
[25:50]- David stresses the importance of finding someone who matches their principles by incorporating them into the ad. They have been promoting Remote work for decades, which helps them find the right people and hire talent from all over the world.
[28:35] - Kimberly highlights the importance of the tone of the job description. As a previous candidate, she notes that it gives people a sense of the company's culture.
[29:01] - 37signals' job ads accurately describe the place and give people a sense of how they communicate, which is a big part of attracting the right people.
[29:33] - Do you have questions for David and Jason about a better way to work and run your business? We’ll be back next week with another edition of listener questions. Leave your voicemails at 708-628-7850 or email. You can find show notes and transcripts on our website. You can also find us on Twitter.
Links and Resources:
Creators & Guests
Guest
What is Rework?
A podcast by 37signals about the better way to work and run your business. Hosted by Kimberly Rhodes, the Rework podcast features the co-founders of 37signals (the makers of Basecamp and Hey), Jason Fried and David Heinemeier Hansson sharing their unique perspective on business and entrepreneurship.
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. Our last podcast episode was an Ask Me Anything episode, and we had so much fun that we decided to do again, and we also had more questions. But I'm joined by the co-founders of 37signals, Jason Fried and David Heinermeier Hansson, you guys, let's just, we get right to it. Our first question is from Sarah.
Caller voicemail (00:26):
Hey guys, Sarah Mackenzie here from the Read Aloud Revival at readaloudrevival.com. Love your work, love the show. Um, love Basecamp, the product, and I especially love your books. I think it was in Shape Up that the idea of delegating projects rather than tasks came up and I'm trying to move this way working with my own team. I just wonder if you guys have any tips or helps for making that transition, helping team members take ownership for their areas of work, maybe obstacles I can watch out for leading my team in this way as we move in this direction with a small team, just a handful of people. But, um, I would love to move in this direction where they're taking more ownership and I can delegate whole projects rather than, um, me kind of owning the project and then delegating tasks. So I would love any feedback or ideas you guys have on this topic.
Jason (01:23):
Yeah, actually, I saw this one come in. I wrote a post on it on my, Hey World blog. You can find it. I forget what it's called. Uh, delegating projects instead of tasks, I think is actually what I ended up calling it. This is a big difference actually, and people are surprised by it when they come work here that they, the people who do the work, so let's say there's a team of two, a programmer designer, they decide the tasks, they break down the project and decide what the actual work is. Um, what they're given is a rough general, it's not even rough, it's just a, it's just a general point in a certain direction. Here's the idea, here's where we're headed, here's what it's about. Here's some ideas perhaps for some, um, interface design, maybe as a sketch. Um, this is enough for you to know what we're trying to do here.
(02:10):
And then it's on you to figure out exactly how to get it done and the amount of time that it, it, it is given. So that's the big difference. It's not, no one is on day one, nobody's given a list of tasks and on day 30, no one has given a list of tasks. They make their own work out of the big idea that they have to do, and that's, uh, quite a bit different thing. So that's the idea of delegating a project, not delegating tasks. We, we've had some situations where we've had new employees come in and they're used to their manager basically giving them a list of work to do on a specific day. And that's just not how we do it here. And it's, it's quite a bit different. But, uh, that's, uh, how we found it to, you know, speaking of ownership and speaking of, of sort of, um, giving people, uh, a sense of control over the work they do. That's how you do it. You send them in a broad direction, let them get the details themselves.
David (02:57):
One way I've seen this described before in other places is whether you're evaluating the work on the basis of effort or on outcomes. And when we delegate a project, we're evaluating on the basis of outcomes, not in terms of effort. And some of this is tied to seniority, as Jason says. There's both the fact of someone being new to the company, but then there's also someone being new to their profession or to the industry. If you are a junior programmer or junior designer, it's sort of easier to think like they really need their meat cut out for them into tiny little pieces that they won't choke on a in any of it. And I can see where that comes from. But it's also one of those things where if you do that, um, you're never gonna know what the potential is. The best hires we've ever had that were junior hires came in and played under the same rules as someone who'd been here for a long time.
(03:52):
They were delegated a full project and they lived up to our high expectations. So this is part of it, right, that you can either sort of attempt to get people to live up to your higher expectations or you can see them live down to your lower expectations. Oh, this person is new. They probably can't figure it out. I have to cut it out into little pieces. Like that would be too much. I'd rather take the chance that someone, even if they're junior, is gonna live up to your higher expectations. They're probably gonna make some mistakes along the way, but they're gonna progress so much faster if you give them the opportunity to own the whole thing. Now, that comes with a couple of factors that's worth, uh, considering. One is if the whole thing is you still have it in your head what it is exactly supposed to look like, that's a fraud.
(04:38):
You cannot delegate a project that you actually have fully specked out in your head and you just said, no, you just go do it. Like you would do it right? And then you come in afterwards and said, well, that's not exactly how I would've done it. Ergo, now it's a failure. That's not gonna work. What is gonna work? And this is where all of these ideas are interlocking and interdependent, which Shape Up. we have the idea of a fixed timeframe, but a flexible scope. So you, we can't go into that and say like, well, you have, uh, uh, four weeks to do it. And it's exactly the so 42 tasks and that that is the success criteria. It has to be that that person is making decisions on their own, running autonomously with the scope of the project, and then you're evaluating the outcome. That's not to say you're gonna love every outcome, and there's gonna be some back and forth on that, but um, it is, it is such a faster way to see what someone is truly capable of.
(05:32):
And what I love about this is that it's so hard to predict who can really embrace this or who embraces it quicker than others. Sometimes, I mean, we've had in the past, we might have hired a handful of people at the same time and I'd go like, oh, I think this person might be able to just run with that really fast. And then they get into it and you're like, yeah, don't know, have no clue. Um, which sides to this fact that like hiring is just really difficult. Um, Google had this long analytics project at one point to find out like which of their hiring metrics work? Oh, is it hiring from Ivy League colleges? Is it hiring high GPAs? Is it whatever, some measure of grit. And they were like, the, the conclusion of a long academic paper was, we have no clue. Don't know. So throw it against reality. Let people live up to your high expectations. See who does that the quickest, the best, whatever, and be lenient with your expectation of what the final product looks like while still keeping a high bar of quality.
Kimberly (06:28):
Okay, well you guys brought up teams of two and that we work with designer and programmer and teams of two. So I'm gonna go to Julio Caesar's. Question from Sao Paulo, Brazil, Julio wrote in, first of all, thank you guys for all the great work you do in podcast books and the community. My question to DHH is how does the day-to-day work in a team of two with code review, pull requests and dev to production deployments? My question is because big companies have long change management meetings that last forever, a lot of time wasted. How do you guys avoid the idea of someone that doesn't know anything about the project approving a deploy? For example, a programmer does the review with the designer, it's a team of two. Please explain it to us.
David (07:08):
That's a great question and I think it gets to some of the misunderstandings some people have about our teams of two. It's like we don't have one team of two. We have many teams of two. I mean, we have quite a few people working on various aspects of the product. Now, any given feature, the main people working on it, uh, it's two people. It's one designer and it's one programmer. But that programmer lives inside a company with other programmers. And particularly as we just talked about someone just uh, joining the company. One thing we've instituted is a mentorship process. So when you join this company, even if you join as a relatively senior person when you first join, until you've learned your way around things, someone else inside the company who's been here longer is responsible for the quality of the thing that goes out the door.
(07:56):
That's a task they have on top of their own work. Um, we try to set it up in such a way that each mentor only have one person they're responsible for because if, if they have five or whatever they, they can't get any work done on their own. But it's this idea that you can get your review if it's needed, um, from someone on another team. Now that's programmer to programmer. We also have programmers to designer sort of in both directions. Like our designers know how to work with the materials. They write their own HTML. A lot of them write actually a large amount of the JavaScript. Some of them even write some of the Ruby that they do the first draft of that might not be perfect. So the other, the programmer who's on the team is gonna do the review and they're gonna sort of get on within that.
(08:40):
The other fact that we have, and this is something I described in, I think we called it Seven Shipping Principles, we can link to that in the show notes, is this idea that you're not obligated to get a review. If you're confident that the thing you're going to deploy is low enough risk. I deploy things all the time. I get no review with other things. And again, this is even as CTO and someone who's been here for a long time and know all of us isn't. Other times I'd be like, I'm not going to deploy this unless I get a review from Jeff or Jeremy or Rosa or whoever is involved with this because you know what? I just want a little more confidence. So we try to delegate even that, hey, you should have a finely tuned sense of confidence yourself. Like, am I confident this is gonna work?
(09:22):
If not, let me, let me ask someone to, to come in to to check it. Now the ask someone part is also important because it's all asynchronous. If you request a review of some work you have, you should not expect that that review shows up in final form in 30 minutes. You should expect that like maybe sometime, well, probably sometime this week, that's when you're gonna hear back. Um, it might be in the middle of the night your time. It doesn't matter. We work asynchronously, so don't have it as a blocker. If you need some review to come in, just, um, have that be be part of the process. But at the top level, think about teams of two as multiple teams of two. You have someone from another team help you review. It's never a full-time job and you only have people review your work if they know what the hell they're talking about, right? Like there's a ton of work that goes out every day. I have no clue, I have no standing to provide a review because I haven't spent the time getting into it. Those are the worst kind of check boxes or check marks to go through – people who are not familiar with the work trying to determine whether it should go or not.
Kimberly (10:26):
Jason, anything to add on your side?
Jason (10:29):
I would just say people are often surprised by the fact that we, that, that pretty much anybody can deploy work. I think that's just something people are shocked to hear. Um, and one of the things we try to avoid here is, uh, is grinding gears and too much interdependence. So big part of this is like, yeah, some mistakes can happen. It's very, very rare that we have to roll something back, but it's happened but incredibly rare. And so we found that it's best to default to trust and um, you know, again, this this degree of reason around like, well, is this so big that I really should get eyes on it and develop, helping to people develop that instinct I think is really important. So that's the only thing I, I have to add to, uh, to that as well.
David (11:10):
What I'll say too is it's actually funny because when you explicitly delegate the responsibility of deploying and not killing the app, not taking the system down, people are actually more diligent and more careful than if they can just like, well, uh, Peter did the review. So like, it's not my fault. No, no, it's, it's on you. I mean, so, so the shortcuts both ways, right? You have the power to deploy if you determined that you are confident enough to do so. But then, I mean, it's also on you if it didn't work and it just doesn't turn out to be a problem. And, and even the very few very rare cases, word is a problem, it's usually like a really key learning moment. We've never literally in the history of the company, we've never had a catastrophic deploy go out where someone you just go like, oh, we need to reshape the entire way we're doing this because this person almost killed the company because they deployed something that they shouldn't have, that that's just not a risk factor. It's worth trading off against the benefits of giving someone full autonomy and trust, Hey, we trust even junior people that you can build up confidence to deploy work. Again, there is someone looking at it, but there's not these check boxes and there's certainly not a rigorous process. What I've seen at some companies is like, it's literally built into the deployment process that like the, it can't go out the door unless there's certain people who pulled certain mechanical levers to allow it. Ugh. Yeah, that's not us.
Kimberly (12:38):
Yeah, I think that's Julio's experience with those long arduous meetings about it. Okay, we're gonna jump into some staffing questions. We got a mystery caller.
Caller voicemail (12:48):
Hey y'all love everything you guys are doing. Was wondering if you have any rules, constraints or systems in place to help you decide when to grow and when not to grow, specifically around headcount and staffing?
Jason (13:02):
Not globally or broadly, but I think it's department based, you know, so for example, we get a certain number of customer service tickets and we need to be able to handle those in a reasonable amount of time with a reasonable amount of load per person. And you can kind of feel that out and you go, we need an extra person here, or we need someone in this time zone because this time zone's lagging, we need more help there. So there's some of that in customer service. On product, we've decided that we want to be able to run at least two, maybe three products simultaneously. So a few years ago we can only do one product at once. And if we want to work on, Hey, we had to stop working on Basecamp now we can work on both simultaneously and work on a new one at the same time.
(13:38):
So we built up product there as well. We didn't have a marketing function a couple years ago now we do with just a few people. So we don't globally necessarily say like we want to. We certainly don't, not even necessarily, we certainly don't say like, we're gonna grow our headcount 10% this year or 20% this year. There's no hiring goals for that. There are just needs to fill. And um, our general principle historically has been, um, hire when it hurts, which is you should first feel the pain before you hire. Don't hire to alleviate future pain. A hire to alleviate actual pain. We got a little bit away from that recently in that we were trying to, when you hire for capacity, so we tried to say like, we wanna be able to do two or three things at once. We didn't have three things to do yet, so we had to put some capacity in place to have the the room to do that.
(14:26):
And in that case it's a little bit different, but in most cases in the company we're hiring based on real specific need. We need someone here because we've been trying to run this group, this team, this thing with one too few people basically, or a few too few people. And we need to kind of handle that. There's another situation where we have one person doing something. They're the only person who does something and that's typically not really the best situation. It's not great for them. Um, it's not great for the company if they, people feel like there's a, there's a huge burden on them not to be able to go on vacation or leave because they're the only person who can do it. That's not a really good situation either. So sometimes we'll hire to make sure there's not just one, although we do have a few positions in the company where there's just one, but it's typically not what we'd like to do. That's what comes to mind for me. I don't know if David has any additional details there.
David (15:16):
It's funny because that exact example just came up recently. Michael, who's our head of, uh, QA had been the sole person inside the company in that role. And then we were using, uh, an outside company to help with some of the QA, uh, task. And he was like, I'd like to first of all take some vacation and then also take a, uh, sabbatical such that, I think it was six weeks or seven weeks or something away from it. And we realized, you know what it, it's, it really is all on Michael. So if Michael is gone for seven weeks, um, if it's two weeks or whatever, we can sort of get through seven weeks. That was a little difficult to think about, like how would we do qa? And that is a version of, it hurts, right? We, everyone inside the company should be able to take their sabbatical once every three years without us feeling like, ah, that's a really big imposition on the rest of the company, on the rest of the teams.
(16:05):
So, um, we hired someone else to, to join the team and then we actually realized during the process of that, uh, that the two of them was better than one of them pleasant external partners. So it kind of worked out in that way. Sometimes that hurt is a little, um, hidden, right? That we were using this external company to help us and therefore it was not showing us that we actually needed two people internally to do it. And, and at least, uh, not least for, for the redundancy and, and just the, the feel good fact that that like Michael can take time off, um, even whatever, six or seven weeks or however it ended up being without that uh, uh, major issue. I'd say the other point or the other time to look at this is if you have natural attrition and then think like actually that role we just had with someone in it, um, is that exactly the same thing we want again?
(16:58):
Could you, could you let it hurt for a little bit? Um, we had someone leave our team on uh, on data analytics and we're going through that right now. This person was contributing some really valuable stuff, but does it need to be exactly the same definition of the role again? Do they need to have that same sphere? I think a lot of companies buy automation when they have someone leave the company in a certain role, they just go like, well now there's an opening, we need to refill that. That's such an opportunity to think like, you know what, maybe that role could look slightly different. Maybe some of the responsibility could go over here and some of it could go over here or, or whatever. So, um, I still think hire when it hurts is the best unifying principle of that, especially earlier on. I, I'm involved with a handful of startups here in in Copenhagen and I'd say any advice on hiring when you are less than say 15 people hire when it hurts.
(17:54):
That is literally number one, two, and three on the list because so often and so easy it is to get out over your skis. Oh well when we have so many more customers, we're gonna need someone here. We actually went through a little of that, right? Like some preemptive hiring in a couple of roles where we're like, oh, we're putting all this extra capacity in place then we should also anticipating thing that would happen perhaps nine months down the road, put someone in that place and you're like, no, it's better just to better to wait. Something else might happen. Reality might show you something else and by the time you you arrive of that, uh, you go like, actually the thing we thought we needed was not quite that. We would've wished it was something slightly different. And that's the thing with hiring, it's not easy to fix cuz you're not gonna wanna fire someone who's doing a good job in their role. If you are like, eh, you know what? We got the role slightly wrong or we got it slightly too early and now you sort of trapped in in a mistake that it's difficult to correct. Um, particularly early on in the business. That's not a good place to be.
Kimberly (18:56):
Well it's interesting that you say that cuz I feel like now you see all these reports, all these layoffs happening Silicon Valley where people have been let go who are really like, yeah I wasn't really doing all that much. Granted that's not everybody, but there are those stories of, you know, people who had jobs and had great salaries but weren't really doing much work.
Jason (19:15):
There's another article that just came out yesterday, I think it was, I dunno if you saw that about people who currently have jobs. They were saying this anonymously saying like, I have nothing to do. I've been doing nothing. Companies had been hoarding talent basically cuz they, they were hiring defensively. This is something we've also never gotten into the rhythm of and I would never want to, which is hiring defensively. I mean we're too small to do that anyway, but that whole idea just seems like such an insult to everybody. It's an insult to the person you're hiring who's clearly skilled, who has nothing to do. It's saying you're just a pawn. You're not, we don't really need you, we just don't want them to have you. It, the whole thing is, is pretty gross, but it's pretty common in Silicon Valley and this is a symptom of having too much money, uh, which is of slowly of course like eroding here because funding is drying up and, and people are starting to get into profit and the whole thing. But historically, um, it's, it's been a symptom of too much money. Hire, hire, hire. It's the best and easiest way to spend money that marketing basically. And you can do it defensively if that's the kind of mindset you're in. But that's again this war-like mentality, which we think is a pretty bad idea in general.
David (20:17):
And I think it connects directly to this malaise of bullshit jobs. Um, David Graber wrote a wonderful first article back in 2015 and then a book by the same name called Bullshit Jobs that came from a UK study of um, white collar workers that showed that something like 35% of everyone who was polled and there was thousands of people thought their job was bullshit, that they did not contribute anything meaningful. And if they didn't show up, do you know what the world would've been just the same. It wouldn't have mattered. And I think that is just such a deep existential wound to inflict on something or, or on someone that their job just doesn't matter. It doesn't matter whether they're here or not. And you might think like, well they can cry themselves to sleep with all the money that they're making, but it doesn't work that way.
(21:06):
Early in my career, I was working at a company where it wasn't clear what my job was. Like I was doing some HTML, I was doing all these things, but like there would be weeks where whether I did something or didn't do something didn't seem to matter. And that was a really depressing experience to me. I'd actually say that was one of the worst moments I've had in my sort of employment history was not to be out of a job but to have a job and feel like, you know what, like it doesn't matter what I'm doing or, or here. And we've had not full versions of that, but we've had tinges of that sometimes when we've done some preemptive hiring or, or sort of speculative hiring, hiring someone like, Hey, I think this is gonna fit in this role and it didn't, doesn't turn out right and you can't kind of fill a full productive week.
(21:52):
And I've now taken the position that it is just, it's cruel. It's cruel to put people in that position. And there's a reason why sort of the term is golden handcuffs that someone feels like, do you know what? This job is still great, the benefits are great or the pay is great specifically when it comes to big tech, right? Some of these pay packages, which is like astronomical, but I almost think like in somehow psychologically it can make it worse. Like I'm being paid this insane amount of money to do nothing or to do something that doesn't matter. I think there's just a wench there that is not healthy for, for anyone. So I think kind of getting out of that mindset somewhat, even if it's really painful to unwind, which clearly is, I mean firing, what was it Amazon fired like 30,000 people or something.
(22:41):
The numbers are so hard to even make sense of it, that's a painful transition and it wouldn't wish that upon anyone. But um, that doesn't mean it's not perhaps a needed correction. Part of this also being big tech, not only were they hoarding from each other, well Google doesn't want Amazon to hire their folks and Amazon doesn't want Meta to hire their people. There're also sucking in all these incredible talent that could have benefited the rest of the economy. Like there are all sorts of companies all over the place who can't pay $400,000 a year for a programmer. They really need programming, but it's being starved from it. And I think so many layers of that's just absolutely terrible. No, good. Very bad.
Kimberly (23:23):
Okay, another staffing hiring type question from you. This was a write-in from Bhagyesh. "While my perspective and practice about how an organization should work has changed thanks to your writings. I'm curious if you can outline the mechanism through which you find team members that align with your work principles and help the business grow without any traditional supervision. If and how you consistently do that." How do you guys find these folks?
Jason (23:48):
Some come through word of mouth, uh, people who already work here might know somebody who's a good fit. I think the biggest thing for us that the biggest lure we have is, is, is a great job ad. Um, we are very diligent about writing up the kinds of uh, or writing up very descriptive job ads that really define what it's like to work here down to like, here's what you would've done last week had you had this position. This is the stuff that you do here. And I think people who really are, are good at their work really appreciate that cuz they wanna know what they're getting themselves into. Typical job ads are bullet points, basically of broad generalized descriptions of a role. They're not, uh, demonstrations of actual work and I think people who really care wanna know what they're gonna do. And that really helps to, first of all, it draws in a lot of people.
(24:36):
So we get anywhere from a few hundred to over a thousand applications per role. So we do get a pretty good sampling. A lot of those don't fit pretty quickly. You can kind of tell, but the top 20 are, are really quite interesting. And uh, then you kind of narrow it down and narrow it down. So when you have that many coming in, you have a really accurate job description, you get, you're gonna get a good handful of really, really qualified candidates who then you talk to and have them do a little project for you and sort of walk through actual work together and you get a pretty good sense of who someone is and what they're capable of and how they approach their work and how they approach feedback and all the things that go into actually hiring someone well. Hiring someone who's skilled, um, and and making sure they're a good fit for the way you work.
(25:17):
And I think also speaking out broadly about how we approach work in general, which is David and I've been doing this for years. We do it here on this podcast with you, Kimberly, and you know, a certain kind of person hears that and they go, I wanna work there. That's the place I wanna work. So what we end up having is a lot of people who are, when they apply, they're like, I was not looking for a job, but this opened up and this is the kind of place I wanna work. Uh, I think that was your case. So like, you know, that that's the kind of thing you, if you can get to that, that's a good place to be. And that's sort of our, our aim when we're hiring people.
David (25:50):
And I think assistant says like, putting your principles out there if the principles are important to you. And that's, um, you're trying to find someone who matches with those. Like you gotta make them known first of all, right? Like how can you expect that you're gonna get applicants who will match with your principles if, if those principles aren't clear or, or the bullshit or they're vague, right? Like we ran on mission statements and, and all the other stuff all the time because it's vague mush as Jason says, the job applications we make, they're very specific and we often go through 'em multiple times to make them even more specific, right? How can we make sure that every paragraph counts? It's not just fluff, it should be, if it's about our principles, it should be something not every company would say. Because if it is, oh we value teamwork, what are you talking about?
(26:36):
Like, who's gonna say, uh, at this company we hate teamwork. Like, uh, only loaners apply. No one's gonna say that, right? Like, unless someone is willing to take the other side of a principle, it's bullshit. It's not a filter. It doesn't help someone figure out why this place not the other place. So having those principles out there, incorporating them into your, into your ad, and then for us, the super trick that we've been screaming at the top of our lungs for two decades is remote. The reason we get hundreds or even thousands of applicants is that we open our positions to the entire world. Like I'd actually go, like if Jason and I were just trying to hire within 40 minutes commute of, of Chicago, we'd go like, do you know what? It's a little slim pickings. It's a little slim pickings. We can't find someone who's an ideal match with our quirky principles and what we stand for.
(27:23):
Um, because the, the pool is so little, but you expand that to remote and, and all of a sudden we have a lot of candidates to, to pick from. Now lots of companies are not willing to do either of those things. They're not willing to have principles that actually matter, that are discriminatory in the sense of making it be something you're either for or, or again, something that matters. Something not every company would would say. And they're not willing to look at applicants from all over. And finally, I mean the proof is in that pudding for us when we're hire you, if you were to go back and look at the last 50 hires at the company, you'd find like, oh, here's one in England, here's one in South America, here's one in Canada, here's somewhere in the U.S. Like, it really does happen like that, like this. We draw the talent from all over the world and that just makes it so much easier and it's felt like such a cheat that we've had access to this incredible talent base because we're doing this in, this is what we wrote about in remote office not required 10 years ago. Now that was published in 2013, thankfully now it is a bit more common, but I'm also seeing the pullback to some extent, right? That the remote kind of everyone was doing it now, a fair number of people pulling back. So anyway.
Kimberly (28:35):
Well I was just gonna add, talking about the job description. I think as a previous candidate, the tone that you guys write in on these job description is also very clear. Someone who is looking for a very buttoned up corporate, I'm gonna wear a suit to work every day situation, reads that job description and knows like, that's not this company. I think we've talked a little bit about writing and the tone and I think that makes a big difference too.
Jason (29:01):
Yeah, it's, it's one of just one of the variables that all come together, you know, to give someone a sense of the place. I think that's the, actually maybe kind of the, the hidden thing here is that I think our job ads give people a sense of the place and most job ads just describe a position and they don't really do it that accurately. And I think people are, people are joining a company, they're joining a place. So that's why I think describing the place and giving people a feel for how we communicate and how we talk is, is a big part of it.
Kimberly (29:33):
Okay, we're gonna take a break right there and come back next week with some more listener questions. But if this session made you think of any questions of your own, please send it our way and we just might answer it on an upcoming episode. You can leave us a voicemail at 708-628-7850. Or if it's easier, you can email us at rework@37signals.com. Rework is a production 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. You can also find us on Twitter at @reworkpodcast.