How 37signals Stays Lean

`0:06:11`

and get rid of all the things that get in the way of making good stuff. And I actually think too many people get in the way oftentimes, and you actually end up making worse stuff the more people who are involved. So, we just try to keep the team small. Any team we have making something is usually two people, like two people are working on a feature, one programmer, one designer. That's pretty much it. Sometimes someone else will come in here and there, but for the most part, it's two people. And it also keeps us honest. It prevents us from making things that we can't make with two people. So, it just keeps everything tight and simple and clear. And you just keep parlaying that, keep adding that stuff up, and you end up with a very tight product with a small surface area. You can see the whole thing, you can hold the whole thing, you know how it all works. Your customers can see the whole thing and hold the whole thing and know how it works, and that's all people want.

`0:06:56`

People don't want complicated stuff. They don't want software that's full of things they don't use. People will sometimes buy things like that because they're sold things like that, but when it really comes down to it, that's not what they actually want. And people who buy our software are the people who use the product. A lot of enterprise companies sell software to a buyer who then makes other people use the product, and everyone hates those products. But people who use our products buy our products, and it's the same person, so they're looking for stuff that just works really well. And I've just found there's no better way to do that than to keep the company small and tight. And that goes everywhere. Like, we don't have any middle management. We tried a little bit. That's why we had 83 people at one point. We hired a few more people to build out a little bit of a team and then pulled back from that and go, "That wasn't helpful." — What did you not like about that? — But there's two people on the executive team, me and David, my business partner.

`0:07:44`

That's it. We've had a COO for a while. They were fine. They were good people. There wasn't enough work for them, frankly, to do the work, so they're just doing things that they didn't need to really do. And then when you do stuff you don't really need to do, you feel bad for them in a sense, because they're wasting their professional life doing things they don't really want to do, that doesn't need to get done. So, that doesn't feel good. We've had engineering managers, and we found out again that there was too many levels in between David, who's the CTO, and the people doing the work. He had to talk to someone else, who talked to someone else, and it's like a game of telephone. Things are lost in translation along the way. We tried those things. We had some thoughts that maybe this would be a better thing for us to do, and it turned out not to be a better thing to do. — How long does it take you to realize? — A year.

`0:08:30`

— Okay. — Basically. COO roles were longer. They were three years. We tried it twice. For the most part, we give everybody about a year to prove themselves at 37signals. And so, we hire somebody, and they have about a year until we decide if we're going to hire them again. That's how I think of the second year. It's a rehire. It's not like a performance review, where we look at numbers. It's like one simple question. If I can, I always try to boil everything down to a question that answers all the other questions. So, the question we ask after the first year with any new employee is, knowing what I know now, would I hire them again? And that answers pretty much every question. It answers every question about performance, about attitude, culture fit, all the stuff. If I know what I know now, would I hire them again?

`0:09:16`

And so, it turned out with the management stuff, we're like, it wasn't even about the people. It was more like, now that we know what we know now, would we create this position again? And the answer was no. So, we eliminated those positions and never rehired for them. So, that's how we kind of got back a little bit to a smaller size. — Does that work with products too, or features of products? — It can. It's harder. — You've rolled back people. — Yes. — You've rolled back entire products. — Yes. — Do you ever roll back features? — We have done that in some ways. Typically, so every five, six years, we kind of reinvent Basecamp, which is our main product, our biggest product. — Do you write it from scratch? — We have in the past. So, from Basecamp 1 to Basecamp 2 was a total rewrite. From 2 to 3 was a total rewrite, 3 to 4 was not, and 4 to 5, which we're working on now, is not. But it's a chance to revisit a lot of fundamental assumptions