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