SEASON 2 - EPISODE 0108 - MAY 8, 2024

A Matter of Ambition

In this episode of REWORK, host Kimberly Rhodes alongside 37signals co-founders, Jason Fried and David Heinemeier Hansson, talk about the company’s renewed sense of ambition and excitement for upcoming projects. They highlight the importance of keeping things fresh, while emphasizing the balance between ambition and practicality.

Watch the full video episode on YouTube

Key Takeaways

00:41 - The source of the company’s ambition explained.
02:18 - Sticking to fundamentals and simplicity can still have a major impact.
06:09 - A hefty price tag on software doesn’t mean it’s good.
11:29 - How 37signals structures teams for new product development.
18:17 - Uncertainty can serve as adventure the exact path to success is not known.
22:32 - A change in priorities is often necessary to fuel ambition.
24:59 - The motivation is to make products better.

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 your host, Kimberly Rhodes, and I’m joined as always by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. In last week’s podcast episode talking about Summer Fridays, Jason and David both mentioned a renewed sense of ambition that they have several projects coming up and since then, since we recorded that the company has been let in on the three products that we’ll be launching sometime this year to be determined. Jason, do you want to jump in? You guys are excited about some new things and have a lot of ambition. That word has keeps coming up. Where is this coming from?

Jason (00:41): Well, first of all, no promises that we’re, I don’t want to establish expectations, but we are doing some things, many things at once. The ambition comes from the fact that we’re been doing this for 25 years. And frankly it gets boring without doing new things, that we’re not a startup anymore. We’re not in that exciting early phase that every company goes through regardless just because they’re new. We’ve been around for a while and so in some ways we have to manufacture our own degree of excitement and keep the fires burning essentially. And ambition to me is a bit of a season in a sense that it kind of comes and it goes. And right now we’re just kind of falling into it. We’ve got a bunch of ideas, we’ve got a great team. The company is sort of at the right size and we’ve proven over the past few months that we can build things rapidly again.

(01:35): For a while it felt like we’d sort of slowed down in a sense that we weren’t able to make new things as quickly as we used to when we had eight people and with ONCE, which is the new pay once service or collection of products, we built Campfire and we’re about to release maybe in eight weeks or so, our next ONCE product. And that only took a couple cycles to make. We’re like, we can make more things, we can get back to making more things with small teams, with the two programmers and one designer is sort of the original, that was the original configuration. And so we’re ready to go. We’ve got ideas, we’ve got people, we’ve got practice now, and why the hell not really is sort of the way I’m looking at it.

David (02:18): I’d say this sense of ambition to me is also the challenge of how much can you do with little. Sometimes, oftentimes, ambition is equated with more and more, more. Can we build a bigger team? Can we build a bigger company? Can we have more revenue? Can we expand, expand, expand. Where I look at ambition as how can we become more efficient? How can we get more leverage both out of our tools and out of our teams and out of our ideas and to some sense almost like our meta ambition, how can we be really ambitious about impact or an idea without being ambitious about it being enormous? How can we actually take something rather small, rather simple, rather basic, but is just the kind of stuff that people need, that they wish they had. And we attack that both on how we work, the tools we work with.

(03:11): We’ve had a big drive over quite a while now to really simplify things. I think there’s these seasons, as Jason says, ambition is a season and there’s also seasonality to expansion and contraction. So the technology world, especially within web, has been in the expansion mode for quite a long time, at least a decade. We just kept on coming up with more and more and more, and became more and more complicated, more and more convoluted, and you need more people, more thinly, sliced pieces of expertise and then you would put it all together. And I think now we’re in the season of consolidation. All of these gains that we’ve had from the more, more, more, we’re now at a stage where we can compress it yet get the same, not volume but density out of it. You can take a lot of stuff and then you can squeeze it, squeeze it, squeeze it, and it takes a far less room.

(04:05): But there’s the same good stuff in it. And I think that’s what’s so fascinating and invigorating about tech right now, especially within web, that some of the fundamentals have just gotten so good that squeeze, that wrench has improved in efficiency. This is why we’ve been able to push out something like Campfire very quickly. We relied on some fundamental advances in technology. This is why we go no-build as we save for JavaScript and CSS that we don’t have convoluted long tool chains. This is why just yesterday I wrote about how we’re pulling continuous integration, some of these processes we have home from the cloud. How can we constantly just trying to shrink it just that one individual or small team, our ideal team size really as Jason says, two programmer, one designer, how can we make it such that the things they work with cuts so sharply that they can make the whole thing happen?

(04:53): Just the three of them, just the three of them that produces the kind of products that people actually want to buy that solves real problems that isn’t bloated and whatever. In some ways, it’s a real throwback to a term we used to talk about a lot and haven’t talked about so much — less software. How can we just have fewer features, fewer things without giving up on modernity, without giving up on the idea that it should be nice, it should be fast and it should be functional and all these things? And I think all of those things have been kind of coming together to a point where we can now think of developing a new product in the same way we used to do in 2005, 2006, 2007. In the early age stages of 37signals as a software company, we made one major product every year. We released Basecamp and then Backpack and then Highrise and then Campfire. And all of these major businesses really, which is what they were businesses in and of themselves were produced by these tiny teams working with far less in many ways than we even had today. Computers were so much slower, bandwidth was so much more expensive. You had all of these constraints, yet we were able to do it. And I think we’re finding our way back to that embrasive constraints, that giving rise to that kind of ambition.

Jason (06:08): One other thing I want to add is that, so I just joined the board of our homeowners association in the neighborhood I live in. And so I was looking at the budget for the amount of money that the homeowners association spends on road repair and whatever, and there’s this line item for software. It was 10,000 bucks a year for this license, for this piece of software that essentially lets you log guests who come in the front gates of this area, whatever. And it pissed me off. I was literally just so frustrated. This is not $10,000 good. This software sucks and I’m not going to say what it’s called, but it’s terrible. And frankly it got me back in that mode of saying we can make, I feel like we have something to prove. We can make really, really good software here. We’re really good at making good products and we can charge barely anything for these things because we have a company that can sort of survive on charging barely anything for these things.

(07:09): And I just want to prove that we can make extraordinarily good stuff that’s simple and straightforward and solves a few things and hits a few angles and sort of leaves the rest alone that is almost embarrassingly affordable. High quality and embarrassingly affordable prices is something that just kind of fires me up, frankly. And seeing this huge bill for this piece of shit product just really got me going again. So I think we’ve been very good at this over the years and it’s actually one of the strange in some ways, hurdles we have to get over, which I think a lot of people look at something like Basecamp and they’re like 15 bucks a user or 300 bucks unlimited users, that’s too cheap. That can’t be any good. And okay, we’re not going to charge you more for it to prove the point. But I like the fact that we can surprise on the upside in that way. And so anyway, that’s another thing that sort of is working its way into this. I think renewed ambition. The world should not be full of crappy software that costs $10,000.

David (08:12): And I think along those lines, what fires me up just the same is to see that the vast majority of the world revolving around communication, collaboration, all the things that we are passionate about, do you know what that runs on? It runs with fucking email and WhatsApp. That’s it. That is literally 97% of everyone I interact with in the world as we try to do projects or I’m involved in raising or this, that and the other thing. Those two things and those two things are so basic that they actually do kind of suck for a lot of things. I mean the initial inception motivation for Basecamp was that email kind of sucks as soon as you have three people collaborating on something for more than two weeks. That’s about the limit of when email is a great fit and nothing can beat it. And then beyond that, you often want something just slightly more, but it’s the slightly part that’s actually the important part. That given the fact that 97% of the world is organized just on email or just on WhatsApp, we need just a little more, just a little more.

(09:13): You don’t need the fucking world more. You need just a little more. And the proof to me that that level of ambition is the right level of ambition is just to watch how Normies, normal people who are not in technology are not making software themselves, look at the world and what they use and what they default to. They default to really simple things that do just a tiny number of tasks exceptionally well. And then they just stretch that. I mean it’s like the joke we always have. Whenever you have a text field for any feature we ever do that has a text field, people would put whatever into it. It’s the open text field, that’s where the tasks go. That’s where the calendar go. That’s where the writeup goes, just goes into the text field. So I think software makers in general vastly overestimate how interested most people are in all the stuff.

(10:10): All the stuff. They just want… again, they’re choosing email. I mean, I dunno if it’s an indictment, but it’s certainly a reflection for us every time we put something into Basecamp is that, do you know what? Most of the time most people just choose email or WhatsApp group. Those are the benchmarks. That’s not whatever the fuck whatever Click Down does or Asuna or whatever else that’s out there. That’s not what we should be focusing on. We should be focusing on, do you know what? It’s email, it’s WhatsApp. And we see that again and again when we do these surveys, which is something I find actually remarkable. You’d think at this point enough alternatives would’ve been out there that most people would come to Basecamp from a competitor. They don’t. Literally half, the last survey I saw, and it’s not that far or long ago, literally half just come straight off email. What did you use before? Oh just email? Yeah, right, exactly.

Kimberly (11:04): Well now that everyone is betting that we’re making an HOA software, Jason, we’ll see what the over under is on that. I do have a question for you guys. You both mentioned these small teams of two developers and one designer. We’ve said for a while, we work in teams of two and now y’all are talking about teams of three. So kind of talk me through that and how that has kind of changed with new projects coming up.

Jason (11:29): So we work in teams of two for feature development for an existing product. And we have worked in teams of two for new product development, but to really get it out there, it seems like it needs another programmer typically. But for new product development from scratch, we’re talking about a team of three essentially max. So we can start with a team of two and layer one more person in or we can just start with three and say this is the team. And that’s sort of the plan here, which is to build a few more products simultaneously, in fact, with two teams of three, so a team of three on each. But yeah, when we’re building a new feature in Basecamp for example, or HEY or Campfire or something, it’s typically going to be two people, one programmer, one designer.

David (12:17): And the difference is whether you already have an architecture, a harness, a framing done, that’s usually the stuff where you need the extra programmer. If you look at something like a Campfire, we had to create a ton of auxiliary technology to be able to make that happen. The distribution of the software that wasn’t particular to Campfire, it was particular to O nce if you will. And I think that’s often where that additional programmer comes in. And then once you have that, once you have the harness and you’re just basically filling in inside the existing framing, you can get away with just two people. I mean what’s interesting is actually the original version of Basecamp also had a team of three in terms of feature development, but it was one program or two designers. It was me on programming and Jason and Ryan doing the design at the time.

(13:03): I think that ratio has just held really well over time for new feature development that three is not just a sufficient model, sufficient team size, but it’s a wonderful one. There’s just such a immediacy when you’re working on such small teams. There’s essentially no coordination overhead, which is one of the things I enjoy the most about working with small teams is you just don’t need a lot of process. You don’t need a lot of formalized rigor around how you work. And I find that that’s better. It’s not something you can always do. When we are trying to push, for example, HEY Calendar, the last bits of that, we had quite a few people. That was a very large complicated endeavor because dealing with calendars is large and complicated and therefore it needed more rigor and more coordination and more whatever in the end. And it’s satisfying to see some of those things come out.

(13:58): But as my default state, I prefer to work with the absolute minimal amount of required rigor, required process. Shape Up in some ways is a answer to how do you deal when you have a larger number of teams? You wouldn’t run Shape Up if you just have three people. And in fact, we don’t run very much Shape Up infused thinking when it’s new product development in the early phases and it’s just the three people and they’re all… all the decisions can be made within that group. Shape Up is very much about how do you solve the problem When you have four of those teams, they all work on the same product and you have someone overseeing that and so forth. So the joy of working with tiny teams is very directly correlated with the lack of network communication overhead that comes with just three people. It’s just a bliss when there’s nothing but just get to it and let’s make it work.

Kimberly (14:55): Okay, so the ambition is coming from the two of you and recently, Jason, you wrote a writeup for the entire company about what’s coming down the pike. I’m curious because you don’t write a lot of company-wide announcements for us. So I’m curious where this came from, your desire to rally the troops or your feel for a need to rally the troops. That’s kind of how I read it, but tell me if you feel differently.

Jason (15:21): I would say that whenever we run a company announcement, it’s because there’s some fire that’s burning in usually in a good way. Fires may be the wrong term. Everyone thinks when there’s a fire it’s bad, but this is more of the ambition fire. And so we’re just excited to do this and we’re doing something we haven’t done before. And we talked a little bit about this at the meetup when we got together a few weeks ago. The whole company was in Atlanta, obviously. Well, you know, but for listeners don’t know. And we talked a bit about doing some more stuff this year and in fact at the meetup I announced we were going to do one more product. And it turned out at the meetup itself, the design team had gotten together to talk about some other stuff and we came up with another product idea. And seeing how much ground we’ve been able to cover with ONCE products, it just made me think we could do both of these at the same time.

(16:16): Why not do two products at once? We can handle that. We built our company up. We have more people than we’ve ever had before. We’ve got an exceptionally talented team. We’ve had some real, I’d say early risers, new employees who have really stepped up and are really hungry to take on real big challenges. Got a great design team, we’ve got a great support team. Great ops, we’re ready to go. So let’s do something we’ve never done before, which is make two things at once. And I won’t share any more details beyond that with the public, but we’re going to try to build two, not try. We are going to build two products at the same time. And that felt worthy of an announcement. I mean, because had I just announced each one individually, people would put it together like, wait a second, aren’t we doing this other thing and aren’t we doing this?

(16:59): Then there’s questions. So might as well just kind of explain it right up front and get people either fired up or a little bit afraid. There’s a little bit of fear in this and I think this is healthy for the organization. We need to be able to challenge ourselves to do things that we maybe haven’t done before that I’m perfectly confident we can pull off. But it sounds like a lot to do and it is. And good. And that’s good for us. We need to do that. We need to do some harder things again. So it just felt like one of those things that there’s some inspiration here, some motivation, some reality check, some admission that this is going to be hard. And in my mind I wanted to amp up the people who were amped up by that. And I do want to scare people who aren’t ready for that in a way that gets them good, nervous energy. I don’t mean scared is probably the wrong, fear is not what I meant. I don’t mean I want to scare people out of here, but there should be some nervous energy because I think we can harness it for the better. And so some people are eager, some people are nervous. Good, let’s just roll with that. And we need both kinds of fuel, I think, to make this happen.

Kimberly (18:09): I mean it was very much a “yes, we can” kind of message. Like, we can do this.

Jason (18:12): Well, we’re going to do it. Yeah, go ahead David.

David (18:16): I think this connects directly to the definition of ambition. What is ambition? It is a leap of faith. It is chasing something, pursuing something where you aren’t entirely sure that A, you can do it. You got to go on faith, you got to go on confidence that it’s possible, but you don’t exactly know how we’re going to get there. That’s why it’s fun. That’s why it’s an adventure. That’s why it’s worth signing up for. If we knew every single step of the way and we could clarify it all, we could lay out the plans, I’d be snoozing off already. That just does not get me excited to know everything before we set out on the adventure already. And I think this is why as Jason started with, we have to choose our ambition. We have to choose our adventure. We have to essentially make it interesting to be here after 20 plus years.

(19:09): And not just for Jason and I to be interesting, but for anyone else who’s here. As Jason says, we have a fair number of folks who joined the company in the last few years who are really hungry and eager to go on their adventure. Their adventure was not the initial version of Basecamp where Jason or I or Ryan and Matt kind of came together to make some stuff like that’s in the past. We owe them an adventure. The worst thing you can possibly do, in my opinion, to employees at your company is to give them not enough, too little, be unambitious on their behalf, be hesitant on their behalf, make sure that everyone knows that they can do everything upfront in advance already. What a snooze fest. So the nervous energy, the “can we do it?” is actually the prerequisite for it being an adventure. Otherwise there is no adventure.

(20:02): If there’s no uncertainty, there’s no adventure. So we have to have a degree of uncertainty and then we have to fuse that with a confidence of, do you know what? Okay, yeah, I don’t know exactly how we’re going to get there, but look at all these other things we’ve done over 20 years. We didn’t know how we were going to get there either. And we did and we made it happen. And could we fail? Yes. If there’s no chance of failure, if there’s no chance that we can’t launch both things at the same time, we won’t hit technical challenges or product challenges, whatever. Again, it wouldn’t be an adventure. You have to have the risk of danger, the risk of uncertainty, the risk of failure to kind of just spice it up. This is one of the earliest things, this is perhaps an odd anecdote here, but I remember when I first started playing video games and I would love playing these hard video games, and then I would always have these urge, can I find a cheat code?

(20:53): Can I get unlimited lives? Can I get unlimited guns? And I’d be so excited that I would find this cheat code and we would put in the cheat codes and then as soon as I had unlimited weapons, unlimited life, the game would lose all meaning. There’d be no challenge. It’d be too easy, it wouldn’t be fun. It’d stop being fun. And the hard part of that is as humans, I think we’re constantly looking for cheat code. We’re constantly looking for certainty and are we sure we can get there and so on because we think that’s what we want. But then if we get it, we hate it, absolutely hate it. We get bored out of our minds. We say we want things to be calm and smooth all the time. We talk a lot about the calm company, and the calm company is about setting up a processes that you can do ambitious things. It’s not an end in itself. It’s not like what we want to arrive at is just perfectly level flat mode of being for eight hours a day in eternity. No, it’s to have a baseline that’s not constantly on fire so that you can go to like, alright, let’s fucking go there. Let’s take the adventure, let’s do something else. Because we choose to, not because things just combust every five minutes because we’ve built something shit, but because we choose to go somewhere far and interesting and uncertain.

Kimberly (22:07): Okay, so I’m curious, and particularly Jason, since you said there is maybe some uneasiness or people who are scared, not being right the right word, but what has to give? Like if we’re creating two products at the same time, plus maintaining all the other products, plus building Basecamp, adding features to HEY, tell me what has to give or are we building a team in order to support all of this ambition?

Jason (22:30): No, that’s a very good question. A few things. So this means that we can’t be equally ambitious about everything. So when we’re going to build two new things, we can dial back our ambition on some other things. So for example, Basecamp and HEY can continue to get better, but we can get better in different ways. We can go a bit deeper on them rather than expanding surface area. What I mean by that is we can look at things that Basecamp and HEY already do and make those things themselves better. So there’s not as much invention, but there’s improvement at different levels. And I think that that kind of work is less ambitious in a sense, but it’s very, very important still for the user experience and for the product itself. So we can sort of shift modes, shift gears, essentially high gear, low gear, if we’re talking about in two gears basically.

(23:16): And high gear is kind of the new stuff and low gear is the old stuff. It’s still moving forward though. We’re not neutral, so that’s important. Okay, and then the other thing is we can decide how we want to launch the product. So for example, these two new things we’re doing, do we need to launch with native apps right off the bat? Could we launch with progressive web apps instead or some other version of mobile access to dial back the necessity… basically if you build two products and then you also build two native versions of those, you’re kind of building four products in a sense. So how can we leverage what we’re, well, I hate the word leverage. How can we build what we’re building and not require putting unnecessary pressure on other teams that are already pretty full essentially? So we have, I would say available product teams on the web and fewer available product teams on native.

(24:14): So you kind of do some shifting there in terms of priorities. So you look at all the knobs and the levers and you kind of just tweak 'em a little bit and turn this one down, turn this one up. But you don’t turn 'em to zero, you just kind of slow down in some areas. We also have summer hours coming up, so that’s another thing we just have to be conscious of. But again, this is about seasons too. Things can… products, existing products, established products they can take not a break, but they can slow down in a way that something brand new can’t. So that’s how you ultimately do this. How you actually do it? You figure this out as you go, but that’s the spirit of how we’d be entering this phase. I would say.

David (24:58): And this goes to the heart of what we so often talk about is that the problem definition is constantly up for renegotiation, constantly up for revision. When we set out to build two new products, it’s not because Jason has detailed every single screen, every single button placement, every single everything in minute detail, and that’s it. That’s what you got to build. No, there’s a rough sketch, if you will, of what the product should be and what the problems that you try to solve. And then within that, you fit it to the timeframe, you fit it to the number of people that you have. So we will build whatever version of that idea can be built by three people in the amount of time we allot to it. And then you just keep trading things off. And this is the part of ShapeUp that does very much apply, the idea that you fix the resources, you fix the time, and then you leave the scope open to negotiation, open to reconsideration.

(25:55): And what you find often is that it is in that pressure that you get something better. That if you had tried to level out or spell out the entire scope upfront, you would’ve envisioned a bunch of things that aren’t necessary or they’re convoluted or complicated. But if you leave the scope open for renegotiation, as you go through the product and as you build it, you will come up with all these beautiful trade-offs that are infused by the pressure of the other variables, and that better software comes out the other end. That’s the big motivating factor to me about this type of ambition is that it’s not just like, what can we make do with what kind of adequate shit can we push out of this pressor? No, is that the stuff that gets pushed out of this pressure is better, the software is better, has fewer features that are more honed and tuned to the materials of the web because that’s where the good trade-offs happen, and that customers and people, they like it better.

(26:54): Again, as we started the conversation, what do people fall back to? Email and WhatsApp. Two of the most basic simple pieces of software, at least in terms of what the user interacts with. I mean, it’s complicated to run a service with 2 billion people like WhatsApp, but the user experience, the scrubbing back through the transcript, that kind of stuff. It’s not complicated. It really isn’t. And that’s why it works. That’s why it’s better than the millions of other convoluted, complicated communication apps that have come before, will come after and we’ll be buried by email and WhatsApp and their simplicity until the end of time.

Kimberly (27:29): We’re going to pause this conversation for now and we will pick it back up next week. Until then, REWORK is 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 Twitter. And if you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 7 0 8 6 2 8 7 8 5 0. You can also text that number and we just might answer your question on an upcoming episode.