Small teams

`2:32:33`

Can we just linger on that advice that you've given that small teams are better? I think that's really less. Less is more. What did you say before? Worse is better. Okay, I'm sorry. — Worse better on adoption with technology a lot of times. And I think actually comes out at the same thing. It comes out of the fact that many of the great breakthroughs are created by not even just tiny teams but individuals. Individuals writing something. And an individual writing something on some parameter, what they do is worse. Of course it's worse when one person has to make something that a huge company have hundreds if not thousands of developers that they can have work on that problem. But in so many other parameters that worseness is the value, that less is the value. In getting real, which we wrote back in 2006. We talk about this notion of less software. When we first got started with Basecamp back in 2004, people would ask us all the time, aren't you petrified of Microsoft?

`2:33:35`

They have so many more resources. They have so many more programmers. What if they take a liking to your little niche here and they show up and they just throw a thousand programmers at the problem? And my answer perhaps partly because I was like 24 was first of all, no, no care in the world. But the real answer was they're not gonna produce the same thing. You cannot produce the kind of software that Basecamp is with a team of a thousand people. You will build the kind of software that a thousand people builds. And that's not the same thing at all. So much of the main breakthrough in both end user systems but also in open source systems and fundamental systems, they're done by individuals or very small teams. Even all these classical histories of Apple has always been like, well it was a big organization but then you had the team that was actually working on the breakthrough. It was four people. It was eight people. It was never 200. — And large teams seems to slow things down.

`2:34:36`

— Yes. — It's so fascinating and part of it's the manager thing. — Because humans don't scale. Communication between humans certainly don't scale. You basically get the network cost effect every time you add a new node, it goes up exponentially. This is perhaps the key thing of why I get to be so fond of having no managers at Basecamp, because our default team size is two. One programmer, one designer, one feature. When you're operating at that level of scale, you don't need sophistication. You don't need advanced methodologies. You don't need multiple layers of management because you can just do. The magic of small teams is that they just do. They don't have to argue because we don't have to set direction, we don't have to worry about the roadmap. We can just sit down and make something and then see if it's good. When you can get away with just making things, you don't have to plan. And if you can get out of planning, you can follow the truth

`2:35:38`

that emerges from the code, from the product, from the thing you're working on in the moment. You know far more about what the great next step is, when you're one step behind rather than if you try 18 months in advance to map out all the steps. How do we get from here to very far away? You know what? That's difficult to imagine in advance because humans are very poor at that. Maybe AI one day will be much better than us, but humans can take one foot or put one foot in front of each other. That's not that hard and that allows you to get away with all that sophistication. So the process has become much simpler. You need far fewer people, it compounds. You need much less process. You need to waste less time in meetings. You can just spend these long glorious days and weeks of uninterrupted time solving real problems you care about and that are valuable and you're gonna find that's what the market actually wants. No one is buying something because there's a huge company behind it. Most of the time.