SEASON 2 - EPISODE 166 - SEPTEMBER 24, 2025

Escaping Workaholism

In their book REWORK, 37signals’ co-founders Jason Fried and David Heinemeier Hansson caution against glorifying nonstop work. In this week’s podcast, they tackle a listener’s questions related to the chapter Workaholism and dig into employee management including how to measure productivity and how to track progress. They explain why simple conversations often matter more than complex systems.

Watch the full video episode on YouTube

Key Takeaways

00:00 - Episode Highlights
01:05 - Judge productivity by paying attention and staying engaged
08:40 - Tracking progress doesn’t require complicated systems
12:34 - Conversations matter more than systems; don’t be a coward
16:01 - When work ramps up, handling busier times without burning out

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes with Jason Fried and David Heinemeier Hansson, co-founders of 37signals. This week we have a question all about workaholism. This is a chapter in their book REWORK, and Nestor wrote in with a listener question. He said, “Hey guys, first of all, thank you for your inspiring book. It really hit home for me. It helped me reconnect with my purpose, let go of some of the pressure I put on myself, and most importantly, it gave me hope. Hope that work can actually be enjoyable, that you can have fun and feel alive doing what you do. In my environment, there’s always been this belief that work has to be hard, painful, almost like a sacrifice, and that never sat well with me. So reading your perspective was super refreshing.

(00:42): One thing that really struck a chord with me was the chapter about being a workaholic that hit deep. It’s something I grew up with. My dad was one my boss too, and I’ve definitely picked it up myself. It made me deeply unhappy over the years. Honestly, I don’t want to work as much as I do. It’s affected my relationship, my mental health, and yet I’ve carried on because it was ‘the right way to succeed.’ Your book gave me permission to rethink that and now I’m even considering sharing this idea with the rest of the company because I truly believe there’s value in focusing on being productive, not just on doing a lot.” Then he said, “That said, there were a few fears that came up for me while reading and I’d love to know your thoughts. Maybe you’ve already solved these things in your own team.”

(01:22): So Nestor has a couple of questions. I’m going to start with the first one, which is “How can we measure productivity without setting goals? We’re not big fans of setting targets in our company, not even for the sales team. We trust people to do their job and give their best, but still, I wonder how do we track whether someone is actually being productive without falling into the trap of micromanaging or adding pressure?” I think this is a great question for you guys ‘cause we don’t do a lot of these kind of tracking things either, but how do you guys handle that, knowing someone’s being productive?

Jason (01:52): I’ll just say that first of all, I hate the idea of measuring productivity, like as a thing. I hate it. I hate the concept. I think you just have to pay attention to what’s going on and what people are doing and when you’re involved with the work, you know who’s doing the work and you know what they’re doing and what’s going on. I think everything else is an abstraction and a representation of something that you could actually know if you just were paying attention. Now, I understand in massive organizations it can be very difficult for people to be doing that and there’s a lot of places to hide. I think one of the things is in our company it’s just obvious. We have a few people working on one thing together and there’s nowhere to hide. You know who’s pulling their weight, you know who isn’t and you know because you’re paying attention and you’re involved in the work itself. This might not be a satisfying answer because maybe she can’t do that or other people at that organization can’t do that or he, I’m not sure if it was a he or she.

Kimberly (02:36): I think it’s a he.

Jason (02:37): He. But just the idea of measuring it and trying to quantify it in a way where then it can be comparative like you’re comparing one person to another by the number of commits they’ve done or the number of hours they’ve checked in or whatever, that doesn’t actually represent what they’re actually doing.

(02:55): It’s just a measure of something that isn’t the actual work itself and the only way to know I think, is to pay attention to it, and that’s just sort of my sense. It’s a feeling like most things. I think most things are actually judgment calls and feelings based on experience and nothing more, nothing less. So anyway, that’s my take on it. I dunno if David has a different take, but that’s my sense.

David (03:13): I know that for literally the entire existence of the software industry, people have tried to crack that problem. Can we count lines of code? Can we count issues closed? Can we try to reduce the work and the productivity to a metric. Story points is another one, velocity is another one, and like Jason, I think it’s all a bunch of baloney. I don’t think you can boil it down to a metric because all of these metrics, first of all can and will be gamed as soon as it’s clear what the metric is. As Jason says, what you need is you need to know the work. When you’re asking someone to do work for you, you have to have the capacity to gauge the quality and the pace. It’s all good and well someone works real fast, but if they turn out dodgy work, it’s not really going to help.

(04:09): And it’s also all good and well that someone can solve a problem, but if they take five times as long doing it as is reasonable, that’s also not going to go well. You have to be able to weigh those things for the correct level that the individual is at. I ask very different things of a junior programmer than I do of a senior programmer then I do of lead programmer. Having some quantification of the kind of projects and the kind of scope that they’re supposed to be able to take on I think is quite helpful. And then having small teams is really helpful. Usually the problem with productivity and the need to measure it is exactly when the team is so large that someone can freeload for sometimes weeks or months without detection. The closer you are to the work, the smaller teams are, the more obvious it just is when the ball didn’t move forward for the past week or two weeks.

(05:04): Now, we actually do have a little bit of an enforcement mechanism at 37signals, and it’s the automated questions. We ask everyone in the company on Monday, what are you going to work on this week? And then every day we ask, what did you work on today? And we ask that everyone at the company, I think it’s like two or three times a week, you got to answer the question. So there’s two things that usually happen when someone is struggling to be productive. One is they just go dark. That’s one thing. They just don’t answer the questions for quite a while. That kind of stands out. Sometimes it takes a couple of weeks. It’s not like we’re on every one like, oh, you didn’t answer yesterday, but if a couple of weeks have gone down, you’re supposed to be working on things and you haven’t filled anyone in on what’s going on, how you move the ball forward, that’s a red flag and one we will go investigate.

(05:53): The other one is when you do answer the questions and the answer is a kind of wake bullshit, you’re enumerating minutia to have something to fill it up on that can also happen. And that’s also called for investigation. So it’s mostly in the field, but that field should also be informed by you being reminded about what an individual is working on. I think Basecamp really is uniquely good at this. Before we used Basecamp with these two automated questions, I had more frequently the urge to go look for metrics in other ways. Lemme go look at the commit logs, lemme go look at something else. And after we started leaning so heavily on these questions, it’s really rare that I find a need to go look somewhere else. And what’s the magic about this question is they’re not automated tabulations of to-dos clicked off or I don’t know, chat messages sent or… they’re not quantifications, they’re stories.

(06:53): This is in that person’s own words, what did they work on? And it’s really easy perhaps because we’ve been telling each other stories for literally tens of thousands of years to smell a bullshit one, to smell a weak story with a plot line that’s lost in the weeds somewhere where someone isn’t getting to where they’re supposed to get to. And then finally on top of that we have a final sort of backstop is that we work in cycles and the cycle, six weeks, that’s the final truth, right? All right, so you’ve been here for six weeks working on a variety of things that you set out to do at the beginning of it. If you didn’t move those things forward in that time, okay, huge red flag, but that’s sort of like the safety. You really should be catching these things earlier, but if you don’t, by the time you get to the heartbeat as we call it, writing up what a team has been working on for six weeks, it’d be really apparent if you didn’t do your part.

Kimberly (07:50): I was talking to someone about Automatic Check-ins at Rails World, at our Basecamp booth because people were like, this just seems, explain it to me. Do you see everyone’s, and it’s interesting to explain it when you’re so deeply ingrained in it that A, how simple it is, but also how much information you get out of it. Some of them are just bullet points. These are the five things I worked on over the last two days and it’s bullet pointed. Sometimes it’s paragraphs, but we also read everyone else’s. You can choose to read every single one if you wanted to or just the people in your group or department, but I think it’s interesting you guys even do them. We know what you guys are working on from the top that everyone is very transparent across the company with these.

Jason (08:30): Something I want to push back on in general is this level of everything needs to be sophisticated, a sophisticated system. This is actually as unsophisticated as you could imagine. It’s just people’s own words, writing things up. There are no format requirements. You can use bullet points, you can use your paragraph. You can do it every few days. You do it every day. Some people do it every day. Some people write extensively, some people write a little bit. There’s nothing sophisticated about this. It’s a simple question and you’re expected to answer it here and there to fill everybody in here and there on what you’re doing. And you can’t bullshit because we can tell anyway and there’s some backstops with this time thing with the cycles. This is not a hard thing, which is why I think everyone’s confused by it because they’re like, well, but is there an automatic system that tells you if someone hasn’t responded to the question?

(09:16): No, there isn’t. This is still about paying attention and being involved and at a certain point you go, I haven’t heard from that person for a while. Let me go check it out versus like alarm bells go off because you built a sophisticated system that has alarm bells on it. I think it’s very important for people to dial back the degree of sophistication they require, they think they require and just make things a lot simpler and they’ll find out that that’s more than adequate and actually better. In general, I think software systems, all these things are too sophisticated. There’s too much going on that’s unnecessary, and I think what happens is this stuff builds up a patina and then eventually someone washes it off and goes, yeah, we don’t need all that stuff anymore. Let’s just get back to the bare metal here. And that’s what I think what we’re trying to explain here, which is it’s not that hard. Don’t make it hard. Don’t build a whole thing that’s hard. People aren’t going to do it also, then you’re not going to find out the things you need to know, so just keep it simple and to your point, that’s why people are surprised.

Kimberly (10:14): Okay. Let’s go to the second part of Nestor’s question, which is “What about people who aren’t workaholics? There are folks on the team who already work fewer hours and don’t have that same internal drive. I worry that reducing overall work hours might make them less productive. How do we balance that?” It’s interesting because we say 40 hours a week, but we’re not measuring people’s hours of like she worked 42, she worked 39.

Jason (10:38): What I’m hearing is worry.

(10:41): About things that haven’t happened yet that aren’t necessarily real. There’s a lot of this, like what happens if we do this? The answer is, I don’t know. Why don’t you try it and find out and then you’ll know? There’s no other way to figure this stuff out than to try some of this stuff, so I wouldn’t worry about people slacking off if… people are going to do the work they’re going to do because they want to do the work, the work’s interesting, whatever or there’s work they have to do because that’s the requirement, whatever it is. Beyond that, I think you’re just kind of guessing as to what really matters. I don’t think a lot of it does, whether it’s 38 hours or 44 hours or whatever it is, it’s not going to make the difference. Those four hours aren’t going to make the difference. It’s like you’re basically going to see someone doing anything? Are they slacking off completely no matter how many hours they have? Are they doing work that doesn’t matter no matter how many hours they have? Are they making things hard on other people? Are they putting a lot of other work on other people’s plates no matter how many hours they have? That’s the core problem. It’s not like 38, 42, 48, 34. It’s like what are they actually contributing and how are they doing it and are they making it hard for others or easier for others? If you look for anything, I would look for that.

David (11:44): I’m going to say something that’s a little harsh and I don’t know you, so don’t take it that harsh. It’s just a word. I’m just going to put it out there. This sounds to me like it’s covering up for being a coward.

(11:56): For being a coward at addressing issues with employees that aren’t quite right and you feel uncomfortable doing that and you wish there was a magic system that would just make all that discomfort go away because it would just deal with it. It would be objective in some ways and you wouldn’t have to have the uncomfortable conversation with someone who’s not pulling their weight, who’s not doing what they’re supposed to do, who’s not just… they’re trying maybe. In some cases they are trying, in other cases they’re not trying, but there are cases too where they try and that attempt is simply not good enough and I mean, I say that in jest and I’m calling myself out in times in my career when I’ve been a coward and haven’t had the hard conversation with someone who really needed a hard conversation because I knew there was something wrong and I just thought I could wish it away, or I thought a system could package away or would just nudge him to the right direction.

(12:50): I’ve always found that whenever I start getting the urge to have a system or metric deal with a problem for me, it’s because I’m a coward and the best way to solve that is just to sum it up a bit of courage and say like, you know what? This is going to suck. It’s going to be uncomfortable conversation, but we got to have it. And I always feel better afterwards. It usually sucks up to it, but then afterwards, yeah, this was obviously a problem. Why didn’t we talk about this three weeks ago or some cases even a couple of months ago? You have to do this. This is management. You don’t get to shove it into some automated system. There’s nothing that’s going to bail you out from those conversations when someone’s not pulling their weight. Now, you can try to be upfront about what the expectations are, but you know what?

(13:40): That’s also a bit of cover your ass. Usually the expectations are quite obvious. They are obvious by the pace and the tone set by the rest of the team, and as long as that’s at a reasonable level, it’s quite clear when someone’s not keeping up and you ought to do something about that. And you’re not being kind to them. This is what I’ve found, and this is a good way to summon some courage if you’re feeling it like a coward in a moment. You’re not doing someone a favor by letting them freeload, by letting them coast, by thinking, ah, maybe they’re just going to figure it out on their own over the next few weeks or months. No, they’re not. That never happens. Literally never happens. They fall into a ditch. They’re not going to dig themselves out. They need a conversation. Sometimes that conversation can bring change about and other times that conversation is the first step towards saying, I wish you a great life working somewhere else.

(14:35): That’s also things that can happen and you can’t run away from it. You got to tackle that head on head. I think we’ve referred to this book many times in the past, but Ruinous Empathy is a wonderful title for going through… not ruinous empathy. That’s the concept. Radical Candor.

Jason (14:51): Yeah

(14:51): That’s the title of the book, Radical Candor, that has the concept of ruinous empathy in it, talks about this, right? Like us trying to be kind objective in all sorts of ways to dance around a lacking performance and everyone just being worse off, including the person who’s struggling.

Kimberly (15:11): Okay. Let’s talk a little bit about, I know we do not believe in being a workaholic. I imagine there are times over the course of a year where we’re working on the final push of a product or launching something new where those hours ramp up a little bit. Talk me through that and how we handle that as a company and just keeping morale up when we do have these spikes in need.

Jason (15:35): David, you’ve been through a few spikes. Why don’t you take that one?

David (15:38): I have been through a few spikes. In fact, I’ve just gone through an absolutely massive spike that I think we have to go back to the launch of HEY to find a parallel in.

Kimberly (15:50): Oh wow.

David (15:51): That was basically a good month worth of Omarchy at the critical phase where we’re trying to get everything stable and we’re dealing with DDoS attacks and all sorts of fires all over the place. I would put out one fire and I’d go to bed at 11 and then the Spidey sense would wake me up at 5:00 AM and I’d think, where the hell am I awake at 5:00 AM, and I’d check my damn phone and something would’ve blown up. There’s some package that’s not quite right. We signed it wrong. The mirror is down, the DDoS is still going on. There was kind of some really long days doing that. That’s not sustainable. Anyone who stays in that zone for months on end or God forbid years on end, they’re going to fry their brain. But you know what? I think even since we wrote that chapter in REWORK about workaholics, I’ve come to appreciate some of it.

(16:44): I’ve come to appreciate that stretching yourself occasionally, rarely, all the way to the limit is actually kind of fun. It’s a little bit like pushing yourself when you’re, maybe you’re working out, not alone, but with a trainer who goes like, no, no, another 20. I’m like, I don’t have another fucking 20, and then you do it and you’re like, oh, shit, I had another 20. How is there another 20 in there? But there was, and pushing through it some of the time is expanding. I mean, literally when it comes to training, you’re breaking your muscles and that’s how they grow. When it comes to your ambition and your resilience, there’s a little bit of that too. I didn’t think we could do this. I didn’t think I could push it so far. I didn’t think we could get to launch, but we did it and the satisfaction you sit with afterwards, you’ve gone through that process and realize, holy shit, we did it or occasionally we didn’t, and that was humbling, and that’s also good. Humble yourself sometimes, but most of the times I’ve found when you really push through it, you can actually make it.

(17:54): It’s really satisfying, and you should make sure that a year includes 1, 2, 3 of those, preferably not for longer than a week or two. That’s about my max. I can feel like when I’ve just been running full throttle for two weeks, I’m actually zonked. I don’t have the same capacity as I did before, just like training. You can’t just work out every day for two weeks and lifting all the weights and no, no, you need some recovery time, but you also need to push time and I think there’s been periods in our own narrative as a company where we’ve leaned too far into everything should just be calm and relaxed all of the time, and there should never be a push moment or that the push movement could only come externally. It could only be if the servers were blowing up and that was being imposed on us.

(18:46): I actually find a little bit of that crunch phase that you’re choosing to make a deadline can be really invigorating and can bring out the best in people. Now, the problem is for most organizations, they seem to be stuck in one mode or the other, right? Either the problem is just stuck wide open all the time and you’re coming up with all these bullshit deadlines that aren’t real at all, and one deadline is being replaced by the next deadline, or one sales target is being replaced by the next sales target, and we just all get so exhausted by constantly chasing. Or, we did as we have done for some periods, you get so calm and so zen and so relaxed that literally no one can get a pulse above 120 for a hot minute before it counts as trauma. Both of those ends are bullshit. It’s the precious end that’s totally brittle bullshit, and it’s the performative, argh all the time, and that’s bullshit. You know what? There is a golden middle line where most of your days are relatively calm and most of your weeks are relatively calm, and then occasionally you go like, all right, let’s do the marathon. I’m using that example because of you Kimberly, like occasionally, did you do a full Ironman?

Kimberly (20:08): Half Ironman, just half

David (20:09): Half Ironman? That to me is already like, what?

Kimberly (20:12): It’s too much.

David (20:13): It’s too much, but isn’t it also kind of too much good, sometimes to have that stretch?

Kimberly (20:19): Yeah, yeah, and it’s also, it’s interesting because there is a parallel in that you can’t, in your training, you have to build up, build up, build up, take a rest for you to actually adapt to the training. You can’t just keep building and building and building and building. You have to have a little down period for that training to take effect.

David (20:36): This is what gets me about the rah rah people, right? Because they fucking love quoting sports metaphors. We had to do the rush. Do you know what?Oftentimes American football in the US when these quotes are coming out, aren’t they off half the season? They don’t fight, they recover, they train, they do all the things, right? Like, they know rest, they know just how important. There’s no athlete in the world who’s just like, yeah, I just work out 365 days a year and doing all that. No, no, no. That’s complete nonsense. If you’re going to use the metaphor, use it correctly. Use it as these moments of push, these moments of breakage and then to cool off.

Kimberly (21:13): Absolutely. Well, that is a great episode. We’re going to wrap it up there. REWORK has been a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube, and if you have a question for Jason or David about a better way to work and run your business just like Nester did, send us a video request, you can do that at 37signals.com/podcastquestion.