SEASON 2 - EPISODE 132 - NOVEMBER 20, 2024

AI, Employee Equity, and Other Listener Questions

Every week, we invite listeners to send in their questions for 37signals’ co-founders, Jason Fried and David Heinemeier Hansson. In this episode, they tackle a fresh set of asks, covering topics from managing multiple product lines, the company’s bonus structure, and their thoughts on incorporating AI into their tools.

Watch the full video episode on YouTube

Key Takeaways

00:37 - How 37signals’ looks at AI and using AI while exiting the cloud
03:47 - How to prioritize work when managing multiple product lines
11:33 - Deciding what problems to tackle first
18:49 - The company’s take on equity and the structure of their profit-sharing plan

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. This week I thought we would answer some listener questions that we’ve received by text, voicemail, email. Let’s dive right in. First question is a text message. It says, “Love the Rework podcast and would like to ask Jason and David a question. My company is all in on cloud, driven by the need to support AI tools. How is 37signals managing this as the company moved off the cloud? Thanks.” David, do you want to jump in on that one?

David (00:37): The answer is actually very simple. We don’t have any AI tools in the main products at this time. We use AI to build the tools because we use them in cursor or Visual Studio or code or wherever else people are making our stuff. I use AI a bunch. I just use ChatGPT or Claude and I just paste in code whenever I want a second opinion or I ask it a question, but there’s no AI that summarizes your email in HEY or anything like that. And a little bit of that is us not wanting to jump on a fad. We want to find something that actually helps. I absolutely believe that there are uses of AI that will help. One of the things that Jason and I have been discussing is essentially ways of querying all this data that you put into the tools that we built, like Basecamp for example, and be able to have a conversation about it. This is perhaps the most compelling use case I’ve seen in information products.

(01:37): I haven’t really enjoyed the kind of the summary stuff that often feels very gimmicky. I’ve seen it go wrong a lot and that doesn’t feel like that has value. So when that was the first frontier rush everyone wanted to summarize, they realized, oh, AI can take a long email and can boil it down to three bullet points, so let’s do that. Do you know what that hasn’t been for us? So we don’t have any of those mechanics currently inside the tool, but I think it is actually a very worthwhile use case for cloud. If you have a very spiky use, for example, your training or detailing your model, you’re specializing your model to your domain and that sometimes requires a lot of fancy hardware. You don’t want to buy all that hardware to do a one-time training to come up with a specialized model. Use the cloud.

(02:26): Cloud is great for that kind of stuff. Cloud, in our critique, fails when you’ve found your steady state, when you know, do you know what I just need a hundred, 200 cards? Yeah, you can rent those. You’re going to pay through the nose if you need those cards for a long time, but if a, you don’t need them for a long time, you just need ‘em for a training job and then you need way less after that, rent them. Or if you think you’re not sure, we could for example, come up with some idea, oh, we built this feature that’s going to use AI. I I don’t know if people want to use it. Let’s rent the materials we need to build that and to put it into production so that we don’t end up with a bunch of junk cards we can’t actually put to good use.

(03:09): I think cloud is wonderful for that. And this is where the discussion about moving out of the cloud needs a bit of nuance, that you can move all your steady state out of the cloud and then you can retain your experimental stuff in the cloud or your spiky stuff in the cloud. It’s not like it’s a one-way door. You can totally mix and match and at the end of the day, just run the math. Do you need the thing all the time? Don’t rent it for years at a time. That doesn’t make any sense. Buy it. If you need it occasionally, rent it. Don’t buy a thing that’s going to sit in your closet 360 days out of the year just for the five days when you need it. That doesn’t make any sense either.

Kimberly (03:47): Okay. Next is an email from Andre. He’s the head of engineering and they currently have three different products. He said, “We have three products under our umbrella, much in resemblance with you. We’ve been having a few issues in terms of prioritizing and speeding up development on all fronts, and I was wondering what is your take on dealing with multiple products? More specifically, being a small company makes me feel that it’s a waste to separate the workforce into separate teams since that will require a significant growth of the teams. However, having the whole team dedicated to all products leads to a lack of focus and it’s harder to prioritize across different products, both in maintenance work, new features, and longer term strategy. I’d love to hear your thoughts on managing multiple products in a lean setup. Thanks in advance, Andre.” I mean this is like right up your alley.

Jason (04:36): Yeah, part of it depends on the company size. So when we first started 37signals over the first handful of years, we built four different products and the way we did it, we had a really small team, eight people or something, we moved between the products. So we had everyone was all in on Basecamp for a while. We put that aside, worked on Backpack for a while, put that aside, worked on Campfire, worked on Highrise. We would move between the products and let some of them rest for a while, but we worked on other things. We didn’t split. It was a very, very small team across four things. I think if you try to do that, you are probably going to lose focus and it’s going to be very difficult to make real progress anywhere. So you’ll be working a lot, but nothing will really move forward.

(05:14): Now when you get to a certain size, I don’t know what that’ll be for you. For us, basically what we do now is we have two-person teams. So we have a designer and a program or working on a feature in a product. It takes a maximum of six weeks. This is called the six week cycle based on the Shape Up methodology, and we have teams of two. And on some products we might have two teams of two, so there might be four people working on Basecamp, two people working on HEY or four people working on HEY, and then a team of two and another team of two working on two other products. So in that math would be eight people, four designers, four programmers. We can work on four different products depending on how you do the math. If we did two and two and two and two and two and two and two and two, it’s of course bigger than eight, but you could also have a team of 2, 2, 2, 2.

(05:57): So cover four products with four teams of two and make a lot of progress, if you have very efficient teams, if you have established products that are already out there in the market and you work on a Shape Up style thing, I think I messed up the math there somewhere, but you get the point. So as you get more people, you can build more teams and those teams can then be dedicated to different products. But initially I would say if you’re working on three different products and you have a very small company of, I don’t even know what you have, let’s say you have 12, I’m just guessing because you didn’t tell us probably too few people to work on three distinctly different products, especially if they’re not all out there in the market. So what I don’t also know about your question is are your products already out?

(06:36): Have you reached V1 on all of them? Are you working on them simultaneously to try to release them together? Hard to say. One thing we did learn is that things can sit for a while. There’s a tendency to feel like everything needs to always be updated all the time, and in some cases at some phases of the product, it is important to show some momentum, but when you get to a certain steady state, you can let something sit for a while and shift your attention somewhere else. So it’s about moving these resources and marshaling them depending on how big you are, what you need, where the products stand. But I would not spread yourself too thin is the bottom line.

David (07:10): I think the key here is there are switching costs. Every single time you jump from one product to the other product, you’re going to have to reacclimate to that product. You’re going to have to get that back into your head, not just from a design and programmer perspective, but also from a product management perspective. I’ve actually seen for us sometimes our limiting factor has been can Jason and Brian keep the evolution of these products in their head at the same time? How many lanes can we manage and manage them well? You can always start a bunch of things. That’s not the hard part. The hard part is keeping a tail on it and making sure that those things actually matter, that these are the things that both customers want, but also that’s providing cohesion to the product. And I think what we found over many years was that to do it sequentially is much easier than to try to do it all in parallel at the same time.

(08:06): And I think when I look back at that phase of the company where we had at one point, I think four or five products and we had a tiny team, less than 10 people, it was all about that. It looked crazy actually from the outside. I remember getting feedback and I don’t even understand how you do all of this stuff all at the same time. And my answer would always be, we don’t. We don’t do all of it at the same time. I think both Jason and I often get the question on a personal level too. How do you do all of these things? You write books, you do podcasts, you do all these things. No we don’t. We do one of the things quite dedicated, quite intently and intensely for some period of time and then we put it away. When Jason and I write a book together, we usually spend three months in that high energy, high intensity phase.

(08:55): Then that’s it, then that is done. Then you move on to something else. We move on to some new product development and we really focused on that product. When we were in the thick of it with HEY for example, the email product we put out, Basecamp got 2% attention from Jason and I for quite a long period of time. We were confident just going like, you know what? Basecamp is mostly going to continue on with some work, we don’t need to be heavily involved with because we can’t do that. Even at that level, just between Jason and I running the company, we can’t constantly keep an eye on everything at the same time. So start thinking sequentially. Can we dedicate six weeks at least to this thing and then that’s all we think about. Or even three months. I think when we were doing these products with a tiny, tiny team and we had a lot of them, we would let things sit for six months, nine months, maybe even a year sometimes, and not only was that fine, I think it was actually good.

(09:51): Sometimes the separation is what’s going to give you the inspiration for something novel, some breakthrough. When you are just in the minds and you’re working on the feature treadmill on one product, just no end in sight, you can kind of get a little myopic. If you take that product and you put it on the shelf and you don’t kind of think about it for six months, when you come back, first of all, you’ve learned a lot of things from whatever else you were working on. That will always influence you and you will always see that old product through that new lens and it’ll give you new ideas. Oftentimes those are the ideas that really move the needle, and it’ll also just allow you to sort of take a rest. I think one of the ways Jason and I have managed to still stay in love with Basecamp for 20 years is to not sit on its lap 24/7 all the time thinking only about Basecamp, only about Basecamp’s business model, only about its features and its customers all the time.

(10:49): We take a break. We take a vacation. We go do new product development, and then when we come back to Basecamp, there’s always such a joy. You go travel and you travel for a while and then you appreciate, you know what, I kind of miss home a little bit. And then you come home and you’re like, oh, I’m so glad to be home. You don’t wake up if you’re just in the same house, I mean most people don’t. I don’t wake up after being in one place for just months and months or years just like, oh, I’m so glad to be home. Right? You need a little bit of separation to appreciate that, and I think that goes in relationship. It goes with where you live and it certainly also goes with products. You have more longevity to stay in contact with a problem you enjoy working on if it’s not everything all the time.

Kimberly (11:33): Relationship advice from David Heinemeier Hansson. The next question is actually a voicemail. It’s similar about prioritization, so you guys tell me if you have anything to add. So this is a mystery caller.

Caller (11:45): Hey, Jason and big listener of the pod. I have a question. You now have a bandwidth to work on different projects. I know you’re releasing two different products this year, but if you were to go back and give advice to your earlier self, if someone’s trying to build a company with ownership, optionality, with everything you talk about, with that in mind, how would you decide what problem to tackle first? I face a problem with having a lot of different ideas. Don’t know which one to tackle. What advice would you give to your younger self, just starting out and what problems to tackle?

Jason (12:30): Well, just to be clear, the two things we’re working on will be next year. So 2025, not this year. I want to set that up. I don’t want us to go Yeah, yeah, yeah. This year. Okay, well, there’s a few different ways to answer this. One is just fucking pick one. That’s one way to answer it. The other way to answer is, well, which one is bugging you the most? Because I think you’ll be most motivated to work on the thing that’s really bugging you the most. So I’ve got a lot of ideas. David has a lot of ideas. Kimberly, you have a lot of ideas. I’m sure we can come up with five more podcasts right now if we wanted to, but this is the one we’re doing and these are the products we’re working on and because we chose to work on these things, so you have to choose to do something if you want to start getting on it.

(13:09): And the best way is to go, what’s the thing that’s just driving me the most crazy? Or what’s the thing? Now there’s a problem with that of course, which is that that thing might not be as commercially viable perhaps as something else that’s driving you crazy. So you may have to do a few plays here and play one thing off another and go, this is the second most annoying thing, but it’s probably the most commercially viable thing. So I’ll put aside the thing that’s really the most annoying thing, so I can do this other almost most annoying thing, but it’ll probably do better. So there’s some things to calculate there essentially, but it’s probably highly unlikely that the five ideas you have are all equally viable and annoying. So I would just look at yourself again, try not to imagine what other people want or what other people want you to make or what you think other people need. What is it that you want to see exist in this world first before anything else? I would probably pick that one. As long as you think it’s not so esoteric that no one else will buy it.

David (14:08): Yeah, I wouldn’t even hedge it as much as Jason’s doing, which is, I mean of course the sound thing to do, but the power of motivation is vastly underrated. We talk all the time about how many hours do you work? To me, it’s such a dull conversation because the band goes from 40 to 80, what a narrow range versus the range of how motivated are you to see this problem solved. That range goes from negative 10,000 to plus 2 billion. That is such a dynamic range and it really gives you the superpower that you kind of sorta need when you’re starting something new. You need to do something kind of fantastical. If you’re starting something that does not exist and you’re bringing it into being under heavy constraints of not enough money, not enough time, too small of a team, you need an X factor. And that X factor is motivation.

(15:05): And I think of it sometimes in historic war terms. You hear about these famous battles where the 300 Spartans held off 10,000 men somewhere in some little, do you know what? They were heavily motivated. They knew that if they got through that little passer, it would be pretty bad for Sparta. So they fought with 10 times the effectiveness. Again, I sort of hate war metaphors, but also I do love Spartan, so I’m allowing that one in. But the idea that the motivational factor can be that not 20% more, not 30% more, but like 2x 5x, 10x is vastly underappreciated. And all this focus about how much time you’re dedicated to it just pales in my experience from how much motivation do you step in the door with? And if you have all of it, you’re going to go so much further, so much faster that you’re going to know really quickly as to does this have economic legs?

(16:05): Is this viable? Because you’re going to arrive at something that does something that solves something so much quicker because that’s your motivation. That’s where it’s coming from. Your will to see this exist and that will has this rocket fuel that you just move faster, but it also provides the tunnel vision. You know exactly where to go next. We need to hit this and we need to hit this, otherwise it doesn’t solve the problem yet. We’ve talked about that in other episodes and I think that tunnel vision together with that rocket fuel, that’s how you end up doing things where people afterwards think, how the hell did a gang of four take on 2000 people at Microsoft? I actually remember the early days of Basecamp, the number one public enemy we painted was Microsoft Project, and Jason and I have since learned that that public depiction of Microsoft actually had some people inside Microsoft a little, I don’t know if it’s skittish, but they were certainly paying attention.

(17:05): And I can just imagine that room, someone going like, how the fuck are these four people even making us talk about this? We have 2000 programmers with 3000 QA people. We should smash them into smithereens, but that’s not how it works. Microsoft was unable to produce the kind of products we were able to produce with only four people. It was inherent in that motivation. We had to solve our own problem of bringing Basecamp into this world system so we wouldn’t look silly to our clients. That had all those heavy motivation stuffs. And that’s how you end up being able to create something that goes from this tiny little thing and suddenly it’s literally worrying like a company the size of Microsoft. I think that’s just such a cool asymmetry and you need to embrace that with all your heart. And I would say if ever in doubt, pick the thing you’re most fired up about.

Jason (18:01): Yeah, I want to add to that. I think you’re absolutely right bviously with that. And the way to think about it for me is like, there’s a path from here to there and what are you going to pave that path with? Are you going to pave that path with a list of features you want to build? Are you going to pave that path with the amount of money you think you’re going to make? Or are you going to pave that path with motivation? If you pave that path with motivation, you are going to get to the other end of that. You just will. The other ones are going to run out. You’re going to be on dirt before you know it. There is nothing as progress oriented as being motivated to get something done, especially if it’s for yourself. So you’ll almost always be more motivated to build something for you than for someone else for a million different reasons. But I would think of your path as being paved by motivation and you’ll always make it to the end if you remain motivated.

Kimberly (18:49): Okay, our last question before we wrap up. This one is actually answered in our employee manual, which I’ll link in our show notes, but I’d love for you guys to talk about it and even the reasoning how you came up with this policy. This is an email from Raphael who said, “Question for Jason and David. At 37signals, how do you give, if you have ever given, equity to some of the workers? How do you manage the reward for persons who deserve it more than others?” So a bonuses kind of discussion for you guys.

Jason (19:16): Great question. So we don’t offer equity. We never have offered equity, but what we do is we have a profit sharing plan. And the profit sharing plan rewards basically how long you’ve been here. So however long your tenure is, you will make more on the profit sharing plan. So it doesn’t matter if your salary is X and someone else’s salary is XX or whatever, you’re still going to make the same in the profit sharing plan if you’ve been here for seven years or eight years or nine years as someone else has been here for seven years or eight years or nine years, regardless of what their salary is, base pay is, anything like that. So if you’ve contributed to this company for that long and you’ve been able to stay at this company for that long, you are highly valuable. So this idea that someone is more valuable than somebody else, I mean, look, there are market pressures which make that true in terms of salary for sure.

(20:04): And there are of course in realistic terms, some people that are more valuable than others based on the skill they provide and the service they provide. They might be more limited, more exclusive, whatever it is, more knowledge, whatever. But ultimately for us, we’ve decided that amount of years here, you put in and you’ve been through all the barriers of us deciding you’re not contributing enough. If you’ve made it that long, you will be able to participate on the upside and a large upside, in fact, with the profit sharing plan. Now, that’s sort of our primary situation. We also have a situation where if we ever sell the company or there’s some liquidity event, it’s similarly based on time spent here, not based on anything else. When people sign up, they don’t get a signing bonus with certain options or stock. It’s very complicated. We’ve always steered clear of anything complicated. This is a very simple system. You earn units or points or whatever based on how long you’ve been here. I think it’s every month starting at two years, something that, and it just adds up and then we cap it also, by the way, at 10 years. So this way if somebody, there’s a little bit of a bonus if you’ve hit 10, but if someone who’s been here for 25, 30 years, for example, at some point they don’t just take the whole bonus pool themselves. So there’s a cap there as well.

David (21:13): And I think the reason we’ve designed it in this way is in part because working at 37signals has really never been a high risk proposition. By the time we started hiring people, we’re hiring folks out of the success of the business, not speculative as into we have this runway because we’ve raised this amount of capital and we hope that we gain flight by the end of that runway, otherwise we’re just going to crash straight into the wall. We never really had that. We’ve run this company boringly safe. I would actually say in the regards to our financial management of when we would hire people, when we would take on additional expenses, we always ran with sufficient margin such that the job offers we extended to folks, they weren’t contingent on us raising another round of capital. Now, of course, in all businesses there’s risk, but our business had way less than a lot of other contemporary options people could have.

(22:10): And therefore it also felt like the compensation needed to reflect that. We, for many years now, have indexed our base pay on some really high benchmarks, like top 10% of San Francisco for base pay, and that kind of took a big part of the risk factor. We weren’t asking folks to join this company and say on a tale essentially, you know what? We’re not really going to pay you market rates, but we’re going to give you a lottery coupon and if we make it to Mars, you’re going to be set. That just wasn’t… we were going to stay here in orbit. We were going to stay on Earth. So we were, do you know what? Here’s compensation that’s market based, and therefore you should actually look at that and choose. That’s not right for everyone. We have had, I think in the 20 some years, I remember two individuals who left because they were more interested in having a low base pay and then a lottery coupon.

(23:01): And I’m like, that’s awesome. I think that’s great for you. You should totally pick that choice. And we can’t offer you that. We don’t have the prospects of in 24 months we’re going to be worth a hundred billion. That’s just not in the cards. That’s not how this is going to play out, and therefore we can offer you something quite predictable and something quite stable. And you know what? If you’re putting in your part, you’re going to continue to have a job here. We’re not going to just sort of blow it all up. That risk factor was just much smaller than it was somewhere else, and this needed to reflect that, and we need to have all those options. So we existed at this sort of weird option to some extent, where a lot of our contemporaries were more based on the rocket ship, the hockey stick, the let’s turn a bunch of VC money into a fantastical unicorn sum.

(23:47): And we were like, no. You know what? One of the parallels, we’ve given some sort of nice Italian restaurant here. We like where we’re at. As we’ve said many times, we’re around 60 people now. We’re not going to be 2000. That’s just never going to happen, let alone 20,000, let alone 100,000. That should never going to happen for this kind of company. So I think knowing who you are and where you’re going to go really helps put the offer together in a way where you can congruently say that this is why we pay what we pay. This isn’t a lottery coupon. This doesn’t have those prospects, but also if the company does well, 10% of the profits go into this pool and they’re distributed every year and ever since we’ve had this model, it’s been kicking out and a bunch of people have made a bunch of money off that and is perhaps less flashy for the big numbers in terms of whatever startup this year, you could say, like Nvidia I think is a good example.

(24:39): They’ve gone for a long time and do you know what? For whatever, they’ve been around for 30 years, for like 27 of those years, you should look at the stock price, like you know why it moves, but not that much. And then in the last three years it’s just gone bonkers to what? One and a half trillion, 2 trillion, something like that. Do you know what? That’s great. Those stories, that does not represent most companies. Most companies do not go through that. Do you want a shot of that? Great. There are a lot of coupons out there. Just make sure the odds fit with the lifestyle and what you want out of it and how you want to work and all that stuff.

Kimberly (25:10): Okay, I say this at the end of every single podcast, but I mean it. If you have a question for Jason or David about a better way to work or run your business, leave us a voicemail at 7 0 8 6 2 8 7 8 5 0. You can also text that number. We’ve made it really easy. Or send us an email to rework@37signals.com. Rework is production of 37signals. You’ll find show notes in transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube and Twitter.