Subscribe
Share
Share
Embed
Not having enough time, enough people, or enough money is actually a good thing! Embrace it!
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.
Shaun Hildner (00:00):
This week we're starting off with another email from one of our listeners. This is a listener named Judah, who writes, "I finished your book and noticed a common theme throughout, simplicity and efficiency." "As an aspiring starter I need to be reminded of these two short, but important words." "I find it funny how the book is also written very efficiently and quite easy to read." I'm going to try to turn this into a bit of a question. How important is simplicity and efficiency to your work in writing?
Jason Fried (00:25):
I've stopped using the word simple and simplicity, as much as I can. I still use it here and there, but I've tried to cut back on it, I should say. Because really, I think what we're more after is clarity. I think sometimes the problem with the word simplicity is that it's interchanged with minimalism or just less stuff, and less means simple or whatever. But you can overshoot there too. And so I think clear and clarity is the key. And I think we do aim for that in our writing. You don't want to squeeze out all the poetry in it, or all the prose, you want to have some feel to it. David's more of a... I would say a poetic writer than I am. I think our writing styles mix to this place where there's some good character in it, but there's also a good degree of clarity. And we just try to aim for that. I think that's enough basically, is what we're after.
Shaun Hildner (01:14):
Well, fantastic. Thank you, Judah. If you have any comments or questions for Jason or David, leave us a voicemail at 708-628-7850, or better yet record a voice memo on your phone and email it into hello@rework.fm. All right, on to the show.
Jason Fried (01:30):
Shaun, it's a shame people can't see you right now with your mustache and your hunky shirt. You're really pulling it off today. I like it.
Shaun Hildner (01:37):
Thank you. Thank you. It's important to dress for the job you want.
Shaun Hildner (01:44):
Okay. Welcome to Rework a podcast by Basecamp about the better way to work and run your business. I'm your host, Shaun Hildner. This week we're talking about embracing constraints. When you're a new business, you probably have to work under some pretty significant constraints. It can be hard to find the time to do everything you want. You might not have enough employees to do whatever you want. You certainly won't have the money to do everything you want to do. Instead of hanging your head and bemoaning the fact that there's just not enough, embrace those challenges. Constraints like these actually force you to build better products. And this doesn't just happen in the beginning. Even having been in business for 20 years Basecamp imposes constraints on itself all the time. As always here to discuss this with me are the co-founders of Basecamp and the authors of Rework. Jason Fried, how are you this morning?
Jason Fried (02:29):
I'm good, Shaun. Thank you. How are you?
Shaun Hildner (02:31):
Wonderful. And David Heinemeier Hansson, how are you this afternoon where you are?
David Heinemeier Hansson (02:35):
Good. Good.
Shaun Hildner (02:37):
Perfect. In general, what benefits do you find pop up when you're boxed in?
Jason Fried (02:43):
I guess it depends what the box is, but I think it always helps you get to what really matters. If you're running out of time, what really matters? We don't have four weeks. We have two. What really matters here? To be honest time is probably the main constraint. There's also of course, people on a project. We limit ourselves typically to two primary people working on a project, which prevents us from getting too deep into the weeds and making things that are too complicated.
Jason Fried (03:10):
Or making communication complicated. You have three or four or five or six people on a team, someone's out, two people are out one day, you have a discussion about something they have to repeat what happened with them. And so I think that's more a benefit of it. It just allows you to be more direct, allows you to make quicker decisions, prevents you from getting yourself into a complicated situation. And I think all those are significant benefits that come from being constrained.
Jason Fried (03:36):
But fundamentally it's really about what can't we do and what is most important to do. And those are two hard answers to come by typically, if you don't have constraints. And we've been down that road before, "How long is it going to take?" "As long as it takes." That's how we used to work years and years and years ago. And things would take four or five months and six months. Because if you give them that long, they'll take that long. Which is one of the reasons why we do the six week cycles these days, which prevents us from going too long on something that just doesn't deserve to have that much time dedicated to it.
David Heinemeier Hansson (04:09):
I'd go even further and say it forces you to make those cuts. Because once the constraints are in place and you've committed yourself to them, they are boundaries that allow you to do what you deep down want to do, but find so very hard to do when the constraints are not in place. There are always an excuse for why that feature should do more or why you should have more features or why you should explore things from additional angles. If you have constraints in place, you're forced to boil that down to just the stuff that matters. And that process of boiling down, in my optics, is the better part of creativity. So much of creativity is actually that process of, "Well, do you know what, if I had unlimited time and unlimited resources, I could build the unlimited thing." That's not a very interesting space. In fact, it's a very intimidating space for a lot of people. I find that. That usually where I do my best, most efficient, simplest quote unquote work, is when I'm forced to do it quickly. When I have the week or two weeks to do it.
David Heinemeier Hansson (05:21):
And this goes all the way back to our origin story. As a company, when we started working on Basecamp, I had 10 hours a week. And I would tell Jason what I got done in 10 hours. And if we wasted that on something that wasn't essential, nothing happened that week. And then you go like, "Well, you do that twice in a row." And now two weeks have gone by and you haven't made any material progress. You quite quickly learn that you have to make some better choices about what we spend our time on.
David Heinemeier Hansson (05:50):
And the other thing that's so crucial there is that, it's not a linear relationship. If you have 10 times as many people, you don't get 10 times as much done. In many cases you actually end up getting less done, at least less of the important stuff that matters. And then what do you end up with in the end? You end up with too much. When you have all the resources in the world, you end up with something that takes all the resources in the world. This was one of the reasons why in the early days of Basecamp, when we would get the question, "Don't you fear that someone like Microsoft is going to waltz in and they're just going to steal your business because they're going to do more?" And our answer would perhaps be a little glib, but it would be, "No, because Microsoft is going to build a Microsoft product." They are physically incapable of building the Basecamp that we had, because they're not a Basecamp company.
David Heinemeier Hansson (06:42):
You can't do that. Now that cuts both ways. And there are certain things that we've taken on over the years that required a different company than the one we started with. We've talked about Hey a bunch. How Hey was something we had to grow into over a year... or decades worth of experience and growth at the company before we felt comfortable doing it. But it cuts the other way too. And I think that more than anything, the purpose of this essay is to inspire people who already have constraints. They don't get to choose. They're not Microsoft to say, "Well, we could set off a skunkwork project that only have three people on it." No, they just have three people. And they're probably not full time and they probably have other obligations. And they feel bad about that. They feel, "Oh, we're at such a disadvantage." "Oh, we can't do the..." No, no, no, no, no. This is flipping your drawbacks to being your advantages. And you might as well do that because you have no other choice.
Shaun Hildner (07:39):
Right, yeah. There's a big difference between placing constraints on yourself versus, with a young company, the constraints are pushed on you. What were the constraints on a very young 37signals as you were making Basecamp?
David Heinemeier Hansson (07:53):
People.
Jason Fried (07:54):
Yeah, we had four people. Initially, it was me and David, Matt and Ryan. And time. David with us 10 hours a week. And to some degree also overlap. David was in Denmark and we were in Chicago. So we had, I think what... maybe three hours or four hours a day or something, potential overlap. Technology. Rails came out of... There was no Rails. So Rails came out of Basecamp. And so David was using a new language he wasn't totally familiar with. Which I'm guessing... you have to speak to this, but I'm guessing you had to keep things pretty simple. It was new for the first time. There wasn't a lot of other resources around for it probably yet, weren't a lot of other libraries you could... all that stuff.
Jason Fried (08:42):
And also I would say our own experience was a limitation, which was the point. We never really built a product like this before. We built it for ourselves. So we weren't imagining all the different use cases. We were imagining ours, which was a constraint to just build your own thing in a sense. But that was helpful, extremely helpful.
Jason Fried (09:03):
Other things like we couldn't store files at the time. I don't know if we didn't know how David? I don't even know if like... or we just didn't know how much it was going to cost. I don't even know what the reason why was, but you had to hook up your own FTP server. This is way back in the day. We couldn't store files or we chose not to store files for whatever reason, initially. So we had to come up with some other way to do it. There's so many. Pricing, actually pricing was one of the other great ones. I don't know if we've talked about this yet before, but... We have elsewhere, but I don't know if we did on this podcast. We initially wanted to charge annually.
Shaun Hildner (09:36):
Really.
Jason Fried (09:37):
Yeah. At whatever it was per year. I don't know.
David Heinemeier Hansson (09:39):
499.
Jason Fried (09:40):
499 a year, 500 bucks a year. And we went to our bank, who's accepting our credit cards. And they said, you can't do that because that's too much risk for the bank. That a customer could decide a month or two in that they didn't want this anymore. And the bank could be on the hook for the whole amount, because we couldn't refund it or whatever... I forget all the details, but it was about something like too much risk. So they forced us to do monthly payments, which actually... We're not taking credit for kicking this off completely, but we were one of the early, early, early first software as a service models that was billed monthly. And it was because we were constrained. We couldn't do it any other way. And it turned out probably to be a good thing. Although interestingly enough, nowadays we'd prefer to have more annual customers than monthly customers.
David Heinemeier Hansson (10:28):
And those are the constraints. But I think just as important is our embrace of those constraints. We did not show up to work every day crying about those constraints. "Oh, we don't have enough people." "We don't have enough time." "We don't have enough money." "We don't have enough technology." "We don't have enough experience." "We don't have enough good connections with the bank." "We don't have..." No, we looked at all of these things and said like, "Hey, this is all the unique forces that's going to create the Basecamp we are putting out. And that it's going to make it quite the unique product. It's going to be a product unlike anything else at the time. It certainly was. And it was a product like that because it could be no other product. It could not be Microsoft SharePoint, which was one of the major things or Microsoft Project, which was another one.
David Heinemeier Hansson (11:13):
We had no capacity erode to creating a head on competitor with any of those tools. And thank heavens for that. If we had, we would've dived straight into the red ocean of head on head, feature comparison, checkbox competition. What a miserable place to be. Instead we had to be creative. We had to let those constraints force creativity out of us and come up with something novel that we could do with our time, people and skills. And I think that that's the thing that's even more important almost than looking at the constraints you have, is to view those as advantages. Because, as I said, you can't do anything about it anyway. So why walk around feeling sad about something you can't change? That's just a useless emotion that's going to drain your motivation and so forth. And we looked at it and go like, "This is awesome." "Wonderful."
David Heinemeier Hansson (12:11):
In fact, I'd say not only was it a self delusion, I actually believe it is awesome. There are many a days where I think back very fondly on four people, six people, eight people trying to make a product and realizing, "Do you know what we today built different products than we did then." Now in many ways those are better products, on certain parameters. And in other ways they take something away. We used to launch a product every year. That came from the constraints of not having a ton of customers. Now we have a ton of customers, you just can't keep that pace.
David Heinemeier Hansson (12:45):
And that has advantages and it has a bigger company and we make more money, but you know what, there was something awesome about launching Basecamp in 2004, Backpack in 2005, Campfire in 2006 and Highrise in 2007. There was just an immediacy and a punch to it where I think enviously back upon someone being like, "Oh man, you're so lucky you're only six people at your company." "Cherish that." In much the same way as I'm sure someone running a 200, 300 or a thousand person companies think like, "Oh, you're only 60 people at Basecamp right now?" "Cherish that." Let's just embrace where we are anyway. And then make the best of that.
Shaun Hildner (13:26):
Well we're not a six person or four person company anymore. So how do you implement these artificial restraints? You mentioned the small teams, the six week cycles.
Jason Fried (13:37):
Yeah. It's primarily those two things. I think on a regular basis, there's probably a variety of other things as well. But whenever we write up what we're working on over the next six weeks, we typically assign two people to that project. Some things are one person, very rarely are there three or four. And then we assign a time. This is roughly four weeks, this is six weeks. That's what it is. And yeah, sometimes it goes over a few days. Sometimes things bleed into the cool down period, which is after our six weeks when there's some QA things that come up and some stuff happens like that. But for the most part, we stick to these things. And those are the two major constraints, time and people.
Jason Fried (14:17):
And of course there's also ambition around the features themselves. There's a lot of things... you can always have things do more things. And that's the thing about software, software has no physical limits, so it can do anything and you can dream as big as you want. And there's a million things we would love to do that we can't do right now, or that we choose not to do actually is the better thing to say. So you've got to keep yourself in line and recognize that we've got a max of six weeks here and we can always do more next six weeks and do more six weeks after that. But we can't just stick six six week cycles together and release one thing. We have to keep releasing things every six weeks as we go to... and you can improve as you go. But we've got to get something shippable within that period of time.
Jason Fried (15:02):
And so those are some of the fundamental constraints we have, I think. I would say the other thing, just briefly, is just even the way we communicate internally, how it's asynchronous, is a constraint. Because we could require everyone to have meetings. We could do stand ups every day or weekly things. And we say, "No, you have to communicate what you're working on by writing it down." "You've got to focus your thoughts, communicate in a way that everyone can understand." "You can't use certain lingo that only a subset of people would understand." This is communication that happens across the company. The language we use has to be tight and clear and understandable by everybody as well. Those are a few other things I would say.
David Heinemeier Hansson (15:38):
I'd also say the interesting thing about these constraints is, they have a tendency to result in better software. I don't actually trust us either to have built great software if we had unlimited people, unlimited time and whatnot, because you end up gold platening things in ways that make them heavy and cumbersome and brittle and easily scratched. When you are forced to make something simpler with simpler materials in less time, I think that you end up with something better.
David Heinemeier Hansson (16:11):
There are endless examples in history when someone either working on a movie or in a video game or whatever, they came into so much money and so many resources because they had a prior hit that of course their follow up was going to be better. And it wasn't. I think Duke Nukem forever is probably one of my favorites. Duke Nukem was this game back in... I think what, late nineties or early two thousands. And I think the development timeframe for the game was something wild, like 14 months, 16 months or something like that. And it was a huge blowout success. It was such a success that it afforded the company seven years to work on the follow up. And when that follow up finally came out, it was total shit.
Shaun Hildner (16:57):
That's because Doom had had three subsequent games since then [crosstalk 00:17:01].
David Heinemeier Hansson (17:01):
[crosstalk 00:17:01] Five games, I think in the meantime. But it's just that fallacy that, "Oh, I'm so good that if I had more, I'd make better." And usually the opposite is true. There's so many forms of creative endeavor where if you have less to do with you will be more creative and it'll the product will be better. In fact, customers should hope that more companies don't have all the money in the world to work on the things that they can. That they have to embrace those constraints.
Shaun Hildner (17:30):
How do you do that in your own mind? How do you juggle that pretty natural desire to put everything in versus constraining yourself? Because now we are in a place where we are constraining ourselves. It's not necessarily the environment of being a young company that is constraining us.
David Heinemeier Hansson (17:48):
It's all on the scale though. We're extremely constrained compared to an Apple or a Google or a Microsoft or any other of the big tech companies out there. Or even any of the venture companies that are hiring hundreds of people in no time at all, because they have a hundred million to blow. Yes. We have luxurious resources compared to the four of us, when we were started out. But I think that's also why we wrote it down. And writing that down was both this book, in terms of the broad scheme of things. And then shape up, writing down how we want to work and infusing constraints into the methodology of how we develop software. If we stray from that, then we'll actually feel bad. We'll feel bad, not about the constraints, but when we fail to embrace them and impose them on ourselves.
Jason Fried (18:39):
I remember too, when we built Highrise initially, which was our fourth product, but we had this sense that this was our second big product after Basecamp. As we began to work on it, we got ahead of ourselves. We started imagining scenarios. We started to build it for an imaginary customer. And we got to a place where we didn't like the thing we were making. I think it took six months or something to realize that we were going the wrong direction and we threw it away and we started over and simplified it significantly.
Jason Fried (19:09):
And it did become second biggest product. And I think had we not done that, it wouldn't have become that. Because it was cumbersome and complex and imaginary. You fall into these traps. And I'm sure we still fall into them all the time. What's harder, of course, as David alluded to earlier, is as you have more customers, there are greater expectations. Everything you release has an edge case does not work for a certain group. It's impossible now to release something that basically makes everybody happy. It's not that hard when you have maybe 500 customers. When you have a 100,000 customers, even 2% of people who are upset, it's a big number and they can be very vocal. And then you start to dilute things and you start to add...
Jason Fried (19:51):
I was going through some stuff in Basecamp, as we're working through this new idea, this new feature. And as I'm walking through some of these screens, I see some words and instructions that we just dropped in. You could tell to... like acquiesce to a group that doesn't understand how to do something particularly well or whatever it might be in the product or we didn't make it clear enough, whatever it is. But I'm like, "Who wrote those instructions?" "Why are there instructions here?" "And why are there instructions there?" "And why does it work this way?" And you can just see how it begins to build up. As pressure mounts, you begin to just appease essentially. And sometimes it's worth it and sometimes it's not. But oftentimes it's not, it doesn't come with really rethinking the problem and trying to make it better. You just patch. And that ends up happening as you have to deal with more feedback and whatnot. So it becomes a lot harder. In some ways actually having more customers is a constraint, but it's not always the easier one.
David Heinemeier Hansson (20:43):
Yeah, I'd say that it's not just about embracing constraints, but also about enjoying constraints. There is few things as blissful as not being on that huge stage, being able to practice your material and come up with the best version of it on a small stage. I think we have another essay about that. But I think really just enjoying those constraints, enjoying the fact that you don't have all the considerations that come with having over 100,000 customers. I think the speed and the agility we had when we had 5,000 customers, objectively, that was just more fun. Now having 100,000 customers is great. On other parameters it allows us to do other things and we can multitask... has all sorts of good things with it. But it's all a trade off. And that's, I think again that thing I want to impart people is that this is not a stepping stone where you get to a place that's just universally better on all the parameters.
David Heinemeier Hansson (21:40):
No, you should enjoy every phase of it. Just the same way as I think, "You know what?" "I had awesome twenties, do I want to rewind the clock and do those twenties again?" Hell no, I am done with my twenties. I'm actually also done with my thirties. And I'm like, "That was great." "But now I'm onto something else." Enjoy the time as you have it, enjoy it when you're four people. Don't spend your time worrying about like, "Oh, I do all this more if I had more people." You know what? You'll get all those worries when you get to be more... just enjoy it in full and make the best damn product you can do under those constraints. And you will probably... if you should be so fortunate to survive and grow, look back upon that face and think like, "Oh wow, wasn't that easy in some ways." You think of these early days. "Oh, it's so hard because we only have two people." Or Basecamp's... "We were only four people." "It's so hard." As Jason keeps saying, it only gets harder. It doesn't get easier.
Shaun Hildner (22:36):
Yeah. Well, perfect. I think that's a fine place to stop. Next week we are continuing our discussion that pops up every once in a while about MVP. As we discuss the chapter, build half a product, not a half-assed product. That should be fun. I will see both of you next week. Thank you so much for joining me, David Heinemeier Hansson.
David Heinemeier Hansson (22:57):
Anytime.
Shaun Hildner (22:58):
And thank you, Jason Fried.
Jason Fried (22:59):
Thanks Shaun. See you around
Shaun Hildner (23:08):
Rework is a production of Basecamp. Our theme music is by Clipart. We're on the web rework.fm where you can find show notes and transcripts for this and every episode of Rework. We're also on Twitter at Rework podcast. If you're following along in the book next week, we'll be discussing the chapter, build half a product, not a half-assed product. If you like the show, I'd really appreciate it if you would leave a review on Apple podcasts, Spotify, Overcast, or wherever you're listening to this. And if you have any comments or questions for Jason or David, leave us a voicemail at 708-628-7850. Or better yet record a voice memo on your phone and email it to hello@rework.fm.