“One of the greatest ways to avoid trouble is to keep it simple. When you make it vastly complicated — and only a few high priests in each department can pretend to understand it — what you’re going to find all too often is that those high priests don’t really understand it at all…. The system often goes out of control.” -Charlie Munger
Many business problems are self-induced. Many wounds self-inflicted. The competition can win, but more often, the competitor loses to themselves.
Entrepreneurs are really good at making things hard on themselves. I talk with a lot of them and I see it everywhere. If they’d only put more energy into avoiding future problems rather than solving present ones they previously created, they’d make significantly more progress in less time.
We’ve built our business on avoiding problems. It’s the fundamental reason we’ve been able to do what we do, and keep doing it — profitably, and with a small team — for 18 years and running. Whenever we make big decisions, we make them in the context of future cost. Basically, how much will things suck later if we do this today?
We don’t see glory in tackling hard problems head on. We’d prefer to take the obvious way out and avoid predictable problems all together.
Here are some examples of things we avoid:
We’ve kept Basecamp intentionally small. We serve well over 100,000 paying customers, and a few million individual users, with a staff of just over 50. Small companies avoid big company problems. Less management is required, fewer layers necessary, less lost in translation, significantly fewer bottlenecks and formal processes that tend to keep people waiting around for permission to move forward with something. Everything’s more direct in smaller companies, and everyone’s closer to our customers, too. Surely some small companies can’t do what big companies can do, but we think that’s a very good thing.
Avoiding large teams
We keep our company intentionally small, and our teams intentionally smaller. Nearly every project we work on at Basecamp is done by a team of three people or less (two programmers, one designer). Many just two (one programmer, one designer), and more than a few with just one (a programmer or a designer). Could we take on bigger problems with bigger teams? Maybe — but we’d also be creating bigger problems with bigger teams. That’s not worth it to us. We’re happy doing many smaller projects with smaller teams. We can still accomplish whatever we want — just in smaller chunks. That allows us to more easily course correct along the way. And, frankly, that’s a better way to do things anyway.
Avoiding long time horizons
Few things are as demoralizing as a long-running project with no end in sight. While occasional infrastructure projects have unknown end dates, nearly everything we do fits into six week cycles, max (I’ve written about this in detail here). Many projects are intentionally small enough to take a few days or a couple weeks. So even if we end up putting 6 weeks into something, and we’re not thrilled with it in the end, all we’ve lost is 6 weeks. We avoid all the complications that come with pushing on when we know it’s probably not a good idea. Compare that with “too big to fail” or “it’s done when it’s ready” projects that take 6, 8, 12+ months… It’s highly unlikely you’ll walk away from all that work by the time it’s done. Long projects are morale graveyards.
Avoiding plans and promises
Similar to the point above, we rarely look beyond 6 weeks. We have some bigger picture ideas of where we want to go in a general sense, but those are held in our heads rarely written down. It’s unofficial oral tradition. We also rarely make promises about the future. Future promises are a huge source of headache and conflict. It’s easy to say yes about something down the road because it takes no work today. But when time comes due, you rarely want to be doing that thing you promised so long ago. Past promises are the genesis of so many problems in business. We avoid those kinds of promises like the plague. I’ve written more about this topic here.
Scale! Scale! Everyone wants to scale! WE DON’T! We try to avoid things that require scale to be successful. We look for things that work at any scale — small or large. For most companies, scaling is synonymous with “the economics don’t work now, but they will eventually”. Don’t get ahead of your skis — grow within your means. Be profitable as soon as possible with as few customers as possible, not with an imaginary many.
We have deadlines. We avoid dreadlines. Dreadlines are deadlines that don’t give a fuck about you. They force you to sprint and rush, but they keep teasing you with a false finish line. They aren’t things you look forward to. What’s worse than not being able to see the end, is not believing the end when you see it. “They’ll just push it again”, “No way in hell will we be done in time…”. Attitudes turn negative, quality suffers, and people become more interested in just wrapping it up, than seeing it done well. The fun is gone when you’re constantly working behind schedule.
Companies don’t have communication problems, they have miscommunication problems. Every additional person you add to a conversation exponentially increases the odds of miscommunication happening. Like Osmo Wiio says, communication usually fails, except by accident. Small companies and small teams inherently have a communication advantage over larger ones. Surely two people can misunderstand each other, but this is about playing the odds — small teams, small groups, small companies have far better odds of information traveling correctly than do their larger brethren.
Big companies come calling for us all the time. They want to set up partnerships. “We were wondering if you wanted to partner on something”… Huge red flag. Early on we followed these leads, and they always ended up in dead ends. Significant wasted time. This is especially true in imbalanced situations where a huge company wants to work with a small company. All things considered, it’s generally a huge amount of work for you (the small company), and a tiny amount of work for one of their many biz dev people who don’t have to do any of the implementation work itself. Avoid!
We avoid things that stop the flow of information and forward progress. We don’t set up management structures or policies that require permission. As long as what you’re about to do won’t destroy the company, just do it. Bottlenecks can take the form of people, process, paperwork, and permission. We’d much rather things run smoothly, than stop and verify at each step. Surely some things can go wrong this way, but few things do, and far more things just go right, frustration-free. Noah wrote more about this here.
This may be a weird metaphor, but I’m going for it anyway… It’s like cleaning the dishes as you go. If you eat and clean up immediately afterward, you never have to clean up later. You’ve avoided a hassle and extra work down the road. If you eat, and leave dirty dishes in a pile to be cleaned later, you’re actually creating a lot more work for yourself — or for someone else. Food dries, it’s caked on, it’s harder to scrub off. You’ve increased the difficulty level of the work that has to be done. Further, a pile is intimidating — piles often become bigger piles because no one wants to deal with them. What’s another dirty plate? I’ll just toss it on here. But if you clean as you go, it’s much faster, it’s part of eating (rather than separately cleaning), and you never have to return to the work later— it’s already done. The future is free and clear.
Don’t leave dirty dishes at work.
Bottlenecked? Is your team playing catch-up all day with unread emails and chats? Bouncing between too many things and unable to find time to focus on the work at hand? Stuff slipping through the cracks? Is the process that used to work starting to crumble? It’s time to graduate to Basecamp 3. It’s free to try — just visit basecamp.com and see what the alternative to “it’s crazy at work” looks like. It’s unlike everything you’ve ever tried before.