SEASON 2 - EPISODE 157 - JUNE 18, 2025

Managing chaos, feature bloat, and other listener questions

In this episode of The REWORK Podcast, 37signals co-founders Jason Fried and David Heinemeier Hansson answer a fresh round of listener questions. They share how they stay focused when new ideas pop up, how structured work periods lead to steady progress, and why they’re careful about adding too much to their products.

Watch the full video episode on YouTube

Key Takeaways

00:18 - Staying grounded by tackling one thing at a time
06:08 - How scheduled work cycles keep the team on track
11:58 - Trimming complexity to keep products lean
20:21 - A preview of what’s in store for Basecamp 5

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 from the 37signals team with Jason Fried and David Heinemeier Hansson, our company co-founders. This week we’re going to knock out a couple of more video submissions that we got to the Rework podcast. So let’s start with one from Jacob.

Listener Jacob (00:18): Hello, Jason, David and Kimberly. My question is about managing order and chaos. How do you create structure at a workplace without creating a bureaucracy? How do you maintain free flow without everything becoming a mess? What have been your strategies for walking this tight rope and how do you personally discern when you’re leaning too much one way or the other? Thank you.

Jason (00:42): There’s probably a lot of ways to answer this. One way I would start with is just compartmentalization. People are assigned to a project for let’s say a few weeks, whatever it might be, and that’s all they have to worry about. So this idea that there’s so much going on and there’s so many things happening. I dunno where the chaos is coming from, but if you’re focused on just one thing, on one project and that’s your responsibility and that’s kind of the only responsibility you have, I feel like that’s kind of enough usually to keep all that noise away. I think if you’re constantly bouncing around, if you’re constantly involved with five or six separate things across the company in different places, it is going to feel like chaos. It is going to be hard. There’s always stuff bubbling up to do. So I think what we try to do is we try to draw some borders around people, give them a project, whatever it might be, give them a timeframe essentially to get it done within and then that’s their only responsibility.

(01:33): I think that’s maybe the best way on an individual level I can think of. At a company level, if you’re changing your direction constantly, if you’re changing your mind all the time on big picture things, that’s going to drip down and affect everybody else. It’s going to feel like there’s chaos everywhere. It’s like this partially it’s just about committing to something and doing the thing and seeing it through versus constantly never quite finishing, getting 80%, 90% done, then moving on to something else that can create a lot of chaos and a lot of loose ends and untied knots that just people start to trip over eventually. I don’t know really where to go with that, but that’s kind of a couple of things that come to mind.

David (02:07): And I think the way we’ve tried to do that in a structured way is by following Shape Up. Shape Up is our software methodology that speaks exactly to this problem of thrashing because I actually think that’s the default state when, especially founders are close to the product team, they get a million ideas all the time. I get a million ideas, a million things I want to do, I’m sure Jason gets 2 million ideas of things that he would like to see happen and if you just let that flow as soon as the idea enters your head and you then go tap someone on the shoulder asking them to do it, it’s going to feel like chaos in no time at all. I’ve worked at companies that were exactly like that, where whoever was in charge would get a new bright idea every fucking five minutes and they’d go interrupt someone about it.

(02:54): So I think Shape Up to me is as much for everyone else as it is for Jason and I to protect the company and what we want long-term from ourselves and from our own impulses. With Shape Up, there’s six weeks of work that is picked before those six weeks start and then you have to sit on your hands. And then on top of that we have two weeks of cool down. So there’s basically two months where you don’t really get to interrupt most of the time, most of the teams, when we are in a Shape Up mode. Sometimes things can get a little different when you’re working on a new product or there are other circumstances involved, but when you’re following Shape Up on the evolution of an existing product or service like we do for Basecamp and we’ve done for HEY for so long, it essentially contains the chaos.

(03:41): It contains it in a way where you have to keep it either inside your head or write it down in your little notebook and then you get to bring it up every two months and that’s a great cadence. Because as you say, the opposite of chaos can sometimes also just be bureaucracy. Too much structure. Oh, we have a roadmap. We’ve decided 18 months in advance what we’re going to work on in what May of 2026. I mean, just shoot me now. I mean I don’t want to be me in May 2026. If I got to work on what me 2025 June decided to do, I already know that movie. No, I’m not interested in a part in that. I want to work on my best ideas within a couple months. You can’t do everything all the time and sometimes you have a bright idea and you can’t do it that second, so you wait a little bit.

(04:29): Sometimes you wait even two cycles, in our parlor here, you’re waiting four months. That’s enough. Do you know what most ideas can actually stomach to sit on the shelves for that long. The inspiration in them is perishable and they’ll go out a date. But alternating between that, having just that bit of structure like a thing ShapeUp can give you, I think actually is a really positive thing to protect you against yourself. The other fact of that is it’s just more efficient. Humans are terrible at multitasking. They don’t actually multitask, they just thrash, especially creatives need long stretches of uninterrupted time to really crack the hard problems that they’re wrestling with. If you are constantly hopping them between multiple projects, multiple new ideas, you’re just going to get far less than the sum of their parts out of them. And this just seemed wasteful to me.

(05:19): So Jason says, if we can tell someone, hey, do you know what next two weeks, next three weeks, whatever it is, go off, just focus on this one thing. Don’t pay attention to everyone else. You can come up for air. That’s a way of talking that we sometimes use. Did you come up for air? You come up to check around. I do that on a daily basis. I might start the day checking things around and then I’ll go deep on something and then four hours later like a whale, I come up and go, alright, lemme take in some information from other people, but there’s not this constant bombardment of micro interruptions. That’s a great way to manufacture chaos.

Kimberly (05:56): Okay, well you guys brought up Shape Up, so I’m going to skip to this voicemail from Mystery Caller.

Mystery Caller (06:01): Yeah, just listen to the episode on picking priorities and really enjoyed listening to it. The host mentioned the idea of, I think it was Jason who mentioned that many of the people listening are developing software, software developers, software companies, and really just wanted to ask what sort of relevance the six week cycle formula as it were has for non software companies. So say marketing companies. I run a marketing agency and yeah, definitely have really struggled at times with the idea of implementing that six week cycle when some cases like the client wants to have a plan, had a call actually earlier today where they talked about the idea of a framework because they did want the plan to have some ability for us to be agile. But just really curious to hear, could the six week cycle that you’re referring to, could it be applied in the case of a marketing agency or the use cases other than software development? So if you wouldn’t mind commenting on that, but this particular topic is just so, so important for us picking priority. So thanks so much for doing it and thanks for all you guys do. Just big fans, longtime customers of Basecamp and yeah, I’m looking forward to the next episode. Thanks so much.

Jason (07:22): Yeah, I wouldn’t get too hung up on the six number. People get hung up on that all the time. Six work weeks works for us. It feels like the right amount of time. I think you do want to find something that’s not super long and also super short. Super short means you can’t get something actually done and shipped too long means you sit on something for too long. So for us, six weeks, or maybe it’s eight weeks for you, maybe it’s 11, I don’t even know. The point is is that you want to time box this, you want to have an end and you usually want to be able to see the end from the beginning. As far as the projects go, I don’t really think it matters unless look, if you’re building airplanes, you’re going to run a different process. But if you’re working on projects, things that kind of have a start and an end that are sort of independent of one another in a sense, it’s good practice generally to know when something’s going to end.

(08:08): It forces you to make decisions, it forces you to think about what’s really valuable, what isn’t valuable. It forces you to think about what matters and what doesn’t. These are the right pressures you want on you regardless of whatever it is that you’re doing, but exactly what number and how long. I don’t care so much about that within reason. I do think that the questions and pressures that it applies, that’s the key. That’s the idea here. Because we’ve all been involved in something that just takes forever to finish or never finishes. That’s not a good method. If you use other methods where it’s like two week sprints in perpetuity, that’s not very useful because there’s no end. Perpetuity is not helpful. So this final end boundary is what’s helpful, and you don’t want it too far, you don’t want it too close. And for us, six weeks seems to be about right.

David (08:50): I think what’s also interesting is that we actually run the Shape Up cadence for every single team at 37signals. We have Support chiming in every six weeks with what they’ve worked on and what kind of projects they intend to take on next. The same with Operations, the same with fFnance, the same with People Ops, the same with Marketing. So we have everyone on the same clock frequency, but part of that is a communication trick, that we want to let everyone inside the company have a rough idea what’s going on in every other department, but not all the time. You don’t need to know on a day-to-day basis what someone who works on a completely different part of the business does. You maybe follow along with their check-ins if you really care about something, but otherwise we have these Heartbeats that summarizes the last six weeks of work and the Kickoffs that summarize the next six weeks of work.

(09:44): So just that alone is really helpful. And then the cadence of making decisions that Jason said is also quite helpful. Regardless of what you work on, there’s always kind of projects to tackle, and you have to think about are we doing it now or are we doing it later. And having a moment every six to eight weeks to ponder that is just a very nice invitation. Now, it’s also true that not every department runs mostly in project mode. It’s not every department that’s mostly in charge of their own time. At 37signals, for example, Operations. They have to keep the lights on, they have to keep the servers running. There are things happening all the time outside of their control. Maybe some hardware breaks, maybe we get DDOSed, maybe there’s a bad deploy. There’s a million things that just suddenly appear on their plate and they can’t do anything about it.

(10:33): So what we try to do is kind of size the appetite and for Operations it’s somewhere around 50-50. We’ll take about half the time and think about the longer term projects we want to work on in that time and then we’ll reserve the other half for reactive work, as we call it. Things that just happen onto your plate you don’t have control about, but you have to deal with right now, and we have the same thing in other departments. Everything from Finance to People Ops have some ratio of how much of their schedule they get to plan in advance and how much of their schedule they have to leave open to the normal operations of things. So think about it in that way too, that the six weeks is not just about I’m going to map out every day. For you it may just be, hey, in the next six weeks we’re going to try to set the three weeks apart and we’re going to work on that. Or Jason says, maybe for you the right number is 12 weeks and four of the weeks really plan in detail and the other eight leave open.

Kimberly (11:29): I feel like we get this question so often from people who are not in software and are like, I don’t understand using Shape Up and really it’s like just setting goals and breaking down big projects into smaller pieces. Last question we’re going to take is a video from Daniel. Jason, it says it’s for you.

Jason (11:46): Okay.

Daniel (11:47): Hi Jason. A lot of people talk about over engineering, but I want to ask about different angle of that problem specifically over featuring. Many modern product companies over the years keep adding features even though it’s unclear whether the end users really benefits from those. These companies have software engineers, product managers, designers that needs work, right? They all need work. And in the end, products become over bloated. That happened to Jira and now it’s happening to Linear, it’s new shiny competitor. Do you think it’s a people problem, mainly corporate metrics problem or methodology problem? Is it possible to come up with some kind of scalable methodology which would make somehow these feature bloats self-evident for everyone? Thank you very much.

Jason (12:47): It’s a good question. I mean, look, this is the natural trajectory of software unfortunately, is that it tends to get more and more complex over time. There’s a lot of pressures, especially SaaS software where there’s a subscription that you’re paying and you expect more out of this thing that you’re paying for, new customers come in, bigger customers demand more things, could be a part of your business model, could be encouraging people to speak up and request things that you have to do otherwise they’re going to leave, and then people have to stay busy, so people have to work on something. Products it seems like are rarely done, right? You just kind of keep improving and keep adding. This is just what happens and it’s happened to Basecamp, it happens to everything. However, I do think that there is an opportunity at some point in a product’s life cycle to say, wait a second, can we go backwards a little bit?

(13:35): Not in terms of function necessarily, but in terms of the approach and the way you access things and the way things feel and look. I think one of the advantages of building new products is that sometimes it encourages you to start from scratch and you have a new interface idea or a new layout idea or a new something idea and you realize that maybe we could bring this simple thing back into our more complex thing. And so I think something we’re going to be exploring with Basecamp 5, which is something we’re starting to work on, is we have this thing that’s 20 years old now in a sense. I mean it’s fresh and that it’s been redone a few times and there’s new ideas, but the trajectory is going to be just more and more and more unless we push back to some degree. What we’re going to be experimenting with is simplifying some things, making things more direct.

(14:18): This is also work that can be done is what I’m trying to get at, is that, typically you got to keep people busy and they’re doing more work. Work that can be done can also be simplifying, clarifying, being more direct, revisiting things that you’re already doing and seeing if there’s a way to make it simpler, shorter, better, or even unnecessary. There’s some things we’re looking at in Basecamp 5, where we’re going to maybe combine two features back into one, things like that. But yes, the natural pressures are expansion and one of the main reasons for this too, I’ll finish with this, is that software, because it’s virtual, it doesn’t push back naturally. If software was a physical object, there’d be a point in which you’d go, this is too big, I can’t carry this anymore. There’s too many spikes on it. You get these obvious pushbacks from physics from just reality.

(15:06): You don’t get that in software. Software can ever expand and that’s why it typically does. So it’s on somebody, somewhere, at some point to say, enough, let’s tighten this up. Let’s go in the opposite direction perhaps. Or you could leave it alone for longer than you think, maybe you could. You can, and maybe set that aside and do something else for a while. There’s other ways to handle this, but yeah, naturally things do tend to get bigger and it’s a problem. And this is also why you end up having new entrants into the market. I’m not familiar with the one that this person talked about, but Jira is a perfect example of a product that most people would say has gotten out of control. You hear this about Trello as well. Originally really tight idea become way too much now and so you open space below and this is also the natural way. This is what happens. This is the going up market, getting bigger and bigger and bigger. New opportunity opens up down below. Someone fills that and everyone finds their niche and maybe the big people get pushed out eventually. This is all just how it works, but I think you can be conscious of it and try to use your energy and redirect it towards making something simpler over time if possible.

David (16:15): I like to think of this as the hockey stick curse. This is what happens to VC funded companies when they encounter their hockey stick moment and they find the product market fit and the thing takes off. What happens? They raise bigger and bigger rounds. What are rounds spent on? They’re spent on people and before you know it, you’ve gone from this tight little team of 20, now you’re 200, now you’re 500, now you’re 2000. I mean, I’m even trying to envision in my head what it would look like to have 2000 people work on Basecamp. I guarantee you Basecamp would turn to shit in exactly the same way as every other piece of enterprise software that has ever attracted 2000 people to work on it has turned to shit, because this is a resource curse. When you have too much time, too many people, too many PMs, too many folks listening, too many salespeople taking input from customers, they all want their little stamp on it.

(17:15): They all want their little say. They all want to show up and do great work for 40 hours a week. At least. Some of the dilutional ones thinks they add more value when they show up for 60 hours or 80 hours. There’s got to be twice as good. No, it’s twice as bad because more hours means more shit. The best of what you put into something, it’s not at that tail end, not the last 20 hours out of 80, it’s the first 10. We built all of Basecamp, the first version, on 10 hours a week of my time and Jason and Ryan and Matt treating it on the side too. Now we are a little bit in that curse, but we try to be mindful of the fact that worst thing we can do to Basecamp is to throw 20 people at it.

(17:57): When we’ve been at our highest in terms of people on it, we’ve usually had like three teams on it, and for us, three teams means six people — three programmers, three designers. That’s for us firing on all cylinders and I think it requires that discipline to at least slow down the rate of inshittification because it’s a universal law. It is simply the law of entropy restated. This is what happens to everything. You throw enough people at it and it will get bloated. There will be too much. Now as Jason says, you can actually try to fight back. Most companies don’t get that opportunity because more seems like more. Well, if we had a little more we could get another marginal customer, and this is where I think even on purely economic sense, which is not at all the only thing we operate after, but even on purely economic sense, it’s actually not a good idea to continuously chase the marginal customer, the marginal demand, because you are listening to one surly customer says, I’m not going to buy unless you add a, b, c, and d. And then you do it and you land that customer.

(19:06): Yeah, but you turn off another five who never told you anything. What we hear most with Basecamp for example, why do people pick Basecamp? They pick Basecamp because it’s simple, because it doesn’t require instruction, because there’s not too much to learn, because someone can just dump a new person into Basecamp and they’re going to figure it out. That’s the fragile thing that no one articulates a great defense for. No one’s going to ask like, hey, could you please remove some features? There’s like these four, they’re too much, can you take ‘em away? No, no, no. It’s always, can I have some more please, can you add some more over there? Can you add some more over here? And you have to be the voice of all the customers who never tell you shit, of all the customers, who’s never going to buy if you glob all these things on the side of it, if you don’t keep it simple, they’re simply not going to be there. I think that is actually one of the finest jobs that a product manager can have is to be the voice of customers who are never going to talk to you.

Kimberly (20:05): Okay. Just a follow up question, based on Daniel’s, Jason, you mentioned Basecamp 5. Where are you thinking about in terms of simplifying and adding? Because obviously that’s like a continuous conversation, adding new features but also keeping it simple. Is there any kind of thing you’re using to make those judgment calls?

Jason (20:23): Yeah, I mean there is this just general idea of directness is what I’m actually, that’s the word I’m using in my own head.

Kimberly (20:32): Sure.

Jason (20:33): And out loud to some degree. I dunno if anyone understands what I’m trying to say, but how can we make things more direct? For example, there are oftentimes things that are buried, two menus deep that might be useful. Can we make that more direct? Can we surface that? Can we push other things back, perhaps? Can content that’s living in a tool somewhere in a folder deep nested somewhere, if I want to bring that forward, can I do that today? Maybe I can’t. Maybe tomorrow I should be able to. Things like that. And then also I think just in general navigation. With HEY, when we launched HEY we sort of introduced this idea of these trays at the bottom of the screen, reply later and set aside, which was a very novel interface idea, which no one else has really picked up on. I think it’s something we’ve got in HEY, now we introduced it, we’re introducing it into Fizzy, which is a new product we’re working on now.

(21:17): And I think that idea might make its way to Basecamp as well, and that starts to free up some things. So those things used to be maybe in the nav. Maybe the nav can get simpler now too. In HEY we introduced a single menu. There’s one menu in the middle of the screen that has everything in it. Basecamp has four or five different things at the top. Maybe we can make that one menu. Maybe there’s some different ways to get to things without having to go back. It’s that kind of stuff on top of new ideas that we want to do that are brand new. But I do think it’s important to look at structural decisions we’ve made and go, why does it have to work that way? Is there a better way to get to something? For example, your list of projects is on your home screen and there’s also a little hidden Command J thing, which lets you jump to things.

(21:56): The Command J thing is pretty power user in that people probably a lot of people just don’t know it’s there. So if you want to get to a project, you have to go home and then look at your list of projects. Shouldn’t the list of projects be available everywhere all the time so you don’t have to go home first to get to that thing? That’s kind of an example of adding something, but actually making things simpler in a sense in that you don’t have to backtrack all the time and feel like you’re chasing something. You can just get to the things you want to. So that’s one of the ways I’m thinking about when I think about the word directness. It all makes sense. I’m talking abstractly because I’m trying to explain something that doesn’t exist yet and something that’s visual that I’m trying to put in words as we get further and hopefully we can share some stuff, but that’s how I’m thinking about it.

Kimberly (22:37): I love the little sneak peek. Well, with that we’re going to wrap it up. Rework is a production of 37signals. You can find show notes in transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube and if you have a question for Jason or David, send us a video request. You can do that at 37signals.com/podcastquestion.