AI, Employee Equity, and Other Listener Questions
25:38 Share

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 Freed and David Heinemeier-Hansen. 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 Rebirth 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?

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 Cloud and I just

paste in code whenever I want a second opinion or ask it a question. But there's no AI that summarizes your email in hate.

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've 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. 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, I 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, you're 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. 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 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 them 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 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. 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 spiking stuff in the cloud. It's not like it's a one-way door. You can totally mix and match everything.

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. Okay. Next is an email from Andre. He is the head of engineering and they currently have three different products. He said, we have three products.

Under an 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. 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. 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 High Rise. We would move between the products and let some of them rest for a while. We worked on other things. So we didn't split 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'd be working a lot, but nothing will really move forward.

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 programmer 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. 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 Hay, or four people working on Hay, and then a team of two and another team of two working on two other products. So 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

a team of two, two, two, two. 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? 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 marshalling 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.

And 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.

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 like, 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. Like when Jason and I write a book together, we usually spend like three months in that high energy, high intensity phase. 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 focus on that product. When we were in the thick of it with Hay, for example, the email product we put out, Basecamp got 2%.

attention from Jason or 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 or 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. Sometimes the separation is what's going to give you the inspiration for something novel, some breakthrough. When you're just in the mind 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.

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, right?

I think one of the ways Jason and I have managed to still stay in love with Basecamp for 20 years is to like 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.

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, right? 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 forever.

I mean, most people don't. I 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 to 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. Relationship advice from David Heinemar Hansen.

The next question is actually of voicemail. It's similar about prioritizations. And you guys tell me if you have anything to add. So this is a mystery caller. Hey, Jason and David, big listener of the pod. I have a question. You now have the 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, with optionality, with everything that you talk about, with that being in mind, how would you decide what problem to tackle? For example, I face the problem of having

A lot of different ideas. Don't know which ones to tackle. What advice would you give to your younger self just starting out in what problems to tackle? Thank you so much. Hope to hear it on the next episode of The Pod. 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 one we're doing. And these are the products we're working on because we chose to work on these things. So you have to choose to do something if you want to start getting going on it.

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 most 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 yeah, 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.

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 like, how many hours do you work?

To me, it's such a dull conversation because the band goes from like 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

sort of 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. And I think of it sometimes like in historic war terms, right? 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 pass there, 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 Spartans, 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? 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 first.

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 do 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 2,000 people in 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, the little...

I don't know if it's skittish, but they were certainly paying attention. 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 2,000 programmers with 3,000 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. We wouldn't look silly to our clients, right? That had all those heavy motivation stuffs. And that's how you end up being able to create something that goes from like 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. Yeah, I want to add to that. I think you're absolutely right, obviously, 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 like,

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.

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 like the reasoning, how you came up with this policy. This is an email from Raphael who said question for Jason and David at 37 signals. 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.

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, if someone else has been here for seven years or eight years or nine years.

regardless of what their salary is, base pay, 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. 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, time 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, on 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

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 like 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'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.

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 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 a risk, but our business had way less than a lot of other contemporary options people could have. 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 below.

That kind of took a big part of the risk factor. We weren't asking folks to join this company and say on a tail, 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're 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. 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 $100 billion.

Like 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 BC money into a fantastical unicorn sum. And we're like, no, you know what? One of the parallels we've given something like a nice Italian restaurant here. Like we just 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 a hundred thousand like 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 congruent is that this is why we pay what we pay. Like,

Like 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, like it's been kicking out and a bunch of people have made a bunch of money off that. And it's perhaps less flashy for the big numbers in terms of whatever startup this year, you could say like, um, Nvidia, I think is a good example. Uh,

They've been going for a long time. And do you know what? For whatever, they've been around for 30 years. For like 27 of those years, if you look at the stock price, like, you know what? 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, two trillion, something like that. You know what? That's great. Those stories that 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.

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 708-628-7850. You can also text that number. We've made it really easy. Or send us an email to rework at 37signals.com. Rework is production of 37 Signals. You'll find show notes and transcripts on our website at 37signals.com slash podcast. Full video episodes are on YouTube and Twitter.