David Heinemeier Hansson co-founded Basecamp (originally known as 37Signals) over two decades ago alongside Jason Fried. Basecamp caters to all sized companies, big and small, and remains popular for businesses of all niches. Hansson and the Basecamp team believe in keeping everything simple and efficient, both in work ethic and in the product delivered to the customer. His product helps businesses organize and manage projects as well as enhance company communication. In 2006, Jeff Bezos bought a small portion of the company, the only person besides Hansson and Fried. Bezos advised Basecamp to invest heavily in evergreen things and concepts, which is now why Basecamp doesn’t chase trends or fads but focuses on long-term importance. The SaaS company has grown since its founding days of four employees. The team now has roughly 50 employees consisting of designers, programmers, and others. Basecamp is headquartered in Chicago, yet employees live and work wherever they please, something Hansson talks about in this article and has written extensively on. Hansson now holds the position of CTO within the company. Fried, Hansson’s co-partner, writes for Inc, has spoken for TED, and is currently CEO of Basecamp.
Hansson was also the founder of Ruby on Rails, which grew to be one of the most impactful coding languages in the tech world—giants like Shopify chose it for its ease of development. Hansson originally used Ruby, the then-obscure language, to build Basecamp, and the released Ruby on Rails as a separate project in 2004. Soon after in 2005, Hansson and Rails were recognized by major sources such as Google and O’Reilly for their contribution to coding infrastructure. The framework reached a huge milestone when Apple announced it would ship Rails with Mac OS X v10.5 “Leopard”, which was released in October 2007. Rails is an MVC, meaning it provides users with a framework for structures for their web pages, databases, or web service. The language has become one of the most popular in the world and is employed by tech giants such as Twitter, Hulu, Shopify, Airbnb, and thousands of others. Hansson and the team at Basecamp still utilize Rails within their own walls—the latest version of which was just released and is available for use now.
Aside from his professional life, Hansson is a best-selling author, race car driver, and self-described family man. “It Doesn’t Have to Be Crazy at Work”, which we discuss in the interview, is his latest published book written with Jason Fried about how to run a calm yet successful company by not subscribing to the model of excessive growth. The book details Hansson and Fried’s rejection of the increasingly accepted principals that long hours, aggression, fast growth, and the “whatever it takes” mentality as the only way to run a successful business. “It Doesn’t Have to Be Crazy at Work” uses Basecamp’s success to prove their point and explain a far more conducive to longevity strategy to managing the workplace and a company. In our interview with Hansson, he discusses the ideals and the success of his mentality when running Basecamp and inspiring the newly published book.
Hansson also authored “REWORK”, a New York Times, Sunday Times, and Wall Street Journal bestseller. It focuses on running, founding, and managing businesses in a better, more effective, and humane way. Rework delves into how the traditional “business plan” model can actually be detrimental to company growth and atmosphere. It functions as a manual and playbook for a founder looking to make it on their own, entrepreneurs who don’t want to succumb to the boring day jobs and the aggressive hustle. His third book, “REMOTE: Office Not Required”, details all Hansson has learned in terms of working remotely. As a race car driver, Hansson has raced in the FIA World Endurance Championship for seven consecutive years. He won in his class in the 24 hours of Le Mans, the largest global endurance race, in 2014. He also was champion in the GTE-Am sector of the WEC championship in 2014. He is married and has two kids. His dedication to his family is a large factor of what drives the atmosphere he encourages at Basecamp.
We sat down with David to talk about his opinions on recent SaaS companies IPO-ing, as well as his outlook for the management of Basecamp and his tips for how to run the most effective and efficient SaaS company.
You have spoken previously about the importance of enjoying the day to day of your job. How has this factored into the building of your career?
I have been working at Basecamp for more than fifteen years now and in that time the work hasn’t changed that much. We have grown from four people in the beginning to more than 50 people now, but during that transition, we have retained the love of doing the work itself. I still do a lot of direct work, which for me is programming and light. Those are two of the major tasks I spend my time on, and then, of course, I also do some management, but we like to think of management at Basecamp as something that’s more of a part-time endeavor. We also don’t have any full-time managers. Everyone is part-time to some extent, and that includes Jason and I as the CEO and CTO at the company. Jason spends quite a bit of his time doing design and I spend my time doing a lot of programming.
Now, not all weeks line up so that I get to do my favorite things all the time. Lots of weeks include some other tasks that aren’t necessarily my favorite but which just need to be done. There is always something that needs to happen when you have six employees, millions of users and hundreds of thousands of customers. We do all that work and we do it diligently, but we try to approach it in such a way that doesn’t allow it to count for the majority part of our work. So, I spend a lot of time writing blog posts, writing internally at the company, or writing books. (We released a new book called It Doesn’t Have to Be Crazy at Work in November of last year.)
I spend a lot of my time programming as well. What a typical day looks like is hard to pin down, because some days look like eight hours of glorious time just programming or writing, and some days look like zero time programming or writing, but dealing with perhaps a crisis that pops up—thankfully that’s relatively rare most of the time—or just some routine admin that comes up as you run a business.
Can you share specifically how you manage the work to make it as much of the rewarding tasks as possible, and maybe how Basecamp can help do that?
Absolutely. We actually use Basecamp at Basecamp to run the company, to run the product, to run pretty much everything. It’s really instrumental in allowing us to spend the least amount of time on the things that fall under that umbrella of management and coordination. For example, we don’t do daily stand up meetings; we don’t do a lot of meetings in general. The vast majority of coordination that we do at the company, especially at the top level of the company, is done through messages on Basecamp. When there is a new project that kicks off, that starts with a message on Basecamp. When there’s a new policy that we institute, it’s a message on Basecamp. The follow-up and feedback to that is usually processed in Basecamp. It’s comments on a message or something else like that.
For example, right now I’m sitting in Spain where I work 11-7, so I have about 4 hours of overlap and about 4 glorious hours almost entirely to myself. That really only works when you have a culture of instant communication and coordination. That’s an aspect that can really help because when I check-in in the morning at 11, I can just read up on all the stuff that’s happened after I checked out last night. I didn’t miss anything because it didn’t all just happen in a conveyor belt of chat. It didn’t just happen in a number of in-person meetings or somewhere untrackable. We have such a written culture at Basecamp, and Basecamp really helps keep it all in one place, because it’s not spread over fifteen different apps.
We really use quite a few apps at Basecamp, and the Basecamp product itself accounts for probably 95% of all communication and coordination that happens at the company. This approach makes it really easy to maintain a distributive workforce, allowing specific people to stay in touch without being in touch by way of a physical connection, or a line of sight that when you’re either in the same time zone or in the same office, you kind fall into the habit of saying, “Eh, let’s just talk it out.” Okay, that’s maybe great for the 3 people who happen to be in that conference room. It’s a little less great for the other forty-seven who might have gotten something out of being privy to the discussion or deliberation or opportunity to have their say. By having this remote, asynchronous messages, written words approach that we have at Basecamp, we really happened to sidestep a lot of that.
Then, I can bundle the amount of time that I spend on all the admin and distraction stuff into more discreet periods of time, so that it’s not just doled out over the 8 hours in the office where someone comes to bother me after thirty-seven minutes and then an hour and a half, and then my entire workday has just been chopped up into these little work moments because I was just interrupted during the whole day with all the stuff that happens to come up when you run a company. No, I can catch up on all of that perhaps at the end of the day, perhaps right after my lunch break, perhaps early in the morning. I can cluster the amount of work and coordination that we do, allowing times that make sense for me. Then I can say, “Oh four hours here in the morning, or four hours in the afternoon.” I have those continuous times that I can invest in design or programming or something that requires deep focus to do deep work.
It sounds like it has created a unique remote culture wherein you are able to streamline the time that you spend on deep work. You mentioned that 95% of communication happens through Basecamp. Do you guys use Slack or an internal messaging system, and if not, do you feel at all that it impacts culture to not have those little chats?
It’s funny because ten years before Slack was even a thing, we basically made Slack. We were early in the market with a product called Campfire in 2005 that was completed in the vein of Slack. And now, we have built Campfire into Basecamp. Part of Basecamp’s product is a chat tool much in the same vein as Slack. It is because we have used chat in this way at Basecamp for almost 15 years now, we have really come to realize where it can be beneficial and where it can actually be harmful.
I think more and more over the years, we came to the conclusion that chat is an improvement in some ways: it can take care of certain email chains that just feel like such a drag, it can provide some cultural connection between people who aren’t in the same place (like sharing gifs or sharing just other fun things in spite of the day), but when it’s really the focus of your company’s coordination it also wreaks unbelievable havoc on the productivity and cohesion of people’s time because they constantly feel like they have to have half an eye on chat. If chat is where all the important decisions and announcements are made, you don’t want to miss out. We pretty much have to have half an eye on it and check in on it all the time and this mode of partial attention is not conducive to deep work.
People say to us all the time when we critique using chat, “Well that’s up to the users. They can just use it differently, or just log off.” Yeah, technically that is possible but it’s just not what people do. Certain packages of software encourage certain behavior, and if your company has basically decided Slack is where you make decisions and coordinate, you are also communicating to your team that this is where the important things happen, and you better be there if you want your say. Otherwise, that discussion might have scrolled off if you went away for two hours, and who wants to be left out of the loop?
At Basecamp, we posted a conclusion that nothing, it sounds harsh, but nothing important should happen in chat. Anything that’s really important that requires serious deliberations and major decisions and major points of information should be in a format where someone can catch up on their own time. It also helps to encourage everyone and allows them to think things through. When you’re thinking one line at a time, you’re not really thinking things through. Instead, you have a tendency to come up with knee jerk reactions, and some of those times, those knee jerk reactions are well-received, which can be great, but it’s not real feedback.
A lot of the major decisions and project pick-ups take more deliberation than what you can do while the chat line is scrolling. Sometimes they take a day noodling it over and then you chime in, and that’s just very hard to do in chat.
At Basecamp we have chat rooms for all the projects as well as major chat rooms for the company itself, and I think it works best for discussing what isn’t capital. It can be highly beneficial for the cohesion of the team, especially if you work with other teams if you have some fun together in a chat room. It’s more like meeting around the kitchen sink in a physical office. It’s not where the work happens, it’s where the social cohesion happens, and that’s why it’s an important part of Basecamp. We built it into a product that it works really well, but we demoted its importance within Basecamp. We suggest that others do the same. A lot of companies are used to such archaic ways of working; for instance, perhaps everything went through email and when anything other than a continuous email thread comes along, like everyone hitting “reply all” 15 times, it can feel like anything would be an improvement. However, I feel that there is a growing awareness amongst more and more companies that if your solution was just to switch over to chat, you may not have made things better—in fact in many important ways, you ended up making things worse.
We actually work with a team in London on Basecamp and I didn’t even realize that there was a chat function because they had set it up for me and we got the project done so smoothly without one, just through having those records of communication.
That’s awesome. I think chat is another one of those things that can make it difficult to be a remote company. If you’re sitting in the US and you have a team that’s in the UK, there can be a sense that chat is the way to coordinate. Everyone has to be online at the same time because that’s really how chat works. Theoretically, you can leave something in the chat and someone can come back to scroll through this endless backlog and catch up on it, but that’s not really a nice way to work.
That’s not a productive way to get a good summary of anything important that has transpired while you were away. I think a lot of people end up realizing that if you structure your thoughts just a little bit and put them into coherent pieces of writing with lines, paragraphs, headings and other tools that we provide with long-form writing, it is actually better. I think we have an unfortunate tendency to see all new technology as simple progress. “Well of course this is better, it’s new.” This is something people started doing years ago. The reality is usually more nuanced than “new is better.”
Something new comes into the marketplace like FlaX or TOPFLY. For a lot of businesses, this is the first time they ever used group chat, and the initial reaction is hype where the reaction is “Ah, man, this is amazing, look it solves all of these things!” Only after you’ve been using it six months or a year, you start becoming aware of where the drawbacks are. As I said, we have been using chat for nearly 15 years, so we have experience as to how chat just isn’t the best way to manage work.
It is important, however, to note that there are sometimes two sides to the coin. If you are just two or three people, it might feel onerous to write everything up. When the team grows to five or six people, then it is far more important that everyone gets on the same page and are pointed in the same direction through these focal points you can point to. For example, something as simple as “Hey what exactly is the definition of this project, why are we doing it, what are the major objectives?” someone can reply: “Oh, just look up the message from July 1st,” versus having to scroll back through chat fourteen days. That’s just not a thing.
Ultimately, I think for a lot of companies, unfortunately, when they choose chat first, they revert into almost an oral tradition. It’s similar to how things were when people were just in an office and everything was done in conference meetings. It may feel like you are including more people, but you’re not.
I want to talk a little bit about the specifics of project management. You mentioned you have a team of fifty people. Is everyone at Basecamp to some extent a project manager? What do you think the role of a project manager in a SaaS company should be?
That’s a great question and I think Basecamp is in many ways unique on that question. We have an aspiration that everyone at Basecamp can be a manager once, or should be developing towards being a manager once. That’s not the same as to say that there’s no need for project management, but just that on a day-to-day basis, people don’t need to have tasks served up to them. They can individually and independently carve up part of the project that they’re on, turn that into tasks and complete them independently. We also have a concept of what we like to call point. We don’t have any full-time project managers, but we do have people with the top-level responsibility of pushing the team forward and being accountable for progress.
At Basecamp, it is often the designers who ‘wear the point hat’ as we call it, although not always because in our world there is much to be done that isn’t customer-facing. Basecamp is not a person, it’s a hat, and the hat can get passed around, and it can go to different people. It is never a full-time hat. No one is just doing project management forty hours a week at Basecamp.
If a designer has the point hat, or the project manager hat, they may spend anywhere from a couple of hours to perhaps 10+ hours a week on the project management side of things. From time to time, Jason or I will step in to share some of the project management burden, help make decisions and push things forward, but we don’t have any full-time project managers, and part of it is because we don’t have long-running projects.
The longer a project is, and the more people it involves, the bigger the burden of the project management. If you’re running a year-long project that involves thirty people, it’s very difficult to get around having someone who is solely dedicated to the job of management. Well, at Basecamp, the vast majority of projects we work on are six weeks or less, and they involve two to three people. When you are at that scale, you are only providing coordination between two to three people. It’s just not a full-time job to project manage that. The six-week cycle also puts a circuit breaker on just how bad things can go. If things go astray—people didn’t pay enough attention to the project management—the worst thing that happens is that after the six weeks, we say, “Eh that didn’t turn out so well. Let’s try something else.”
Really, this is very rare because when you scope your project so that it can be done with two to three people within the scope of six weeks, it is not that sophisticated. That is an important aspect of how we try to approach problems. The questions is, how can we take very hard problems such as, “How do you coordinate fifty people for a year on a major project?” and step aside to not try to solve it with more clever technology or more clever approaches, but simply try to ‘judo’ the problem in such way that it ends up being an easy problem. It’s relatively easy to project manage those two to three people for six weeks. It is relatively hard, if not very difficult, to project manage fifty people for a year.
If possible, I would like to get into the specifics of managing the project. In Basecamp, you start by setting up a project, and then how does it continue from there? Is it a Gantt system, where someone knows everything they need to be doing for every single day of the next six weeks?
This question could not be more perfectly timed. We have literally just released a new book on the web called Shape Up. The book explains our entire method of work but I will give you the short gist of it. When we start a new project at Basecamp, often it is one of those 6-week projects. For example, we want to do a major new product feature. A new project gets launched on the platform, so we spin off a new Basecamp floor, invite the people who are going to work on it, a couple of other stakeholders who might give feedback on it—maybe someone from design, maybe someone from support, maybe someone from data—and then usually also Jason and I, as the executives at the company. Then we start with what we like to call ‘Shape Work’. We have this rough outline of what the project is supposed to be, but it details out a very coarse level so that it is roughly defined. We don’t like to line things up and estimate how long we think the project is going to take. A lot of people used to start off projects based on estimates. They ask programmers, they ask designers, “Oh how long do you think this is going to take?”
That is a universally flawed model that we find no one is able to consistently pull off. You can pretty much count on any estimate anyone giving you to be wrong, because humans are notoriously bad at estimating anything. It leaves you with this constant conflict between, “You said it was going to be two weeks but now it is taking three and we are nowhere near done.” Right? That is basically the crying call of every software company in the world. We like to splice up that larger problem because estimating entire projects upfront is very, very difficult.
I’d actually go as far as to say it is impossible if you’re working in the domain where you’re not repeating simple work. The only time estimates can work is when you’ve literally done the job before and there’s very little variation in it. Software is not like that; the vast majority of software is novel, it is creation, it is unknown. We approach new projects with what we like to call appetite success. We will pick up a new project, and they are usually scoped by the top level of appetite we have, which is six weeks. We will not say “How long do you think it will take to build a feature to invite new users?” We will say, “Our appetite for building this new feature is four weeks, or six weeks. Let’s build the best version of that idea we can within six weeks.” which basically means that the budget is six weeks, but the scope is flexible.
We are not detailing in precision what exactly inviting new users means, because virtually every feature you build in a piece of software, there’s a version of that you can do in two weeks and there’s a version that you can do in nine months. The magic is how you design it in such a way that it fits within your appetite. For us at Basecamp, we just decided that the maximum appetite that we will dedicate to almost any project is 6 weeks. There are rare exceptions of projects that have a larger appetite than six weeks but we will try to carve those up into two bits, where each bit has independent value if we ship independently, even if we may not announce it to the customers until we have done both parts.
“At Basecamp, the vast majority of projects we work on are six weeks or less, and they involve two to three people. It’s just not a full-time job to project manage that. The six-week cycle also puts a circuit breaker on just how bad things can go. If things go astray people didn’t pay enough attention to the project management—the worst thing that happens is that after the six weeks, we say, “Eh that didn’t turn out so well. Let’s try something else.”
Those are very rare. The vast majority of features at Basecamp have a good version that can be done in six weeks. We meet with teams, which are usually comprised of one or two programmers and one designer, and set them loose within those boundaries. Usually, we require about six weeks to do a great version of a feature. Now, that comes with a lot of constraints. You can’t do everything you wanted, obviously, because you only have six weeks, and as you move through the weeks, you get to cut the scope (we call that scope hammering).
You start moving through, spend two or three weeks building it and you’ve got some good stuff done, but now you realize you only have three weeks left. What are the most important parts that need to be done? The to-do list is always supposed to be longer; there’s always going to be more work, things you could add into it, so unless you have a constraint, you may very well come to the end of six weeks, find that you are 90% done and you have another 90% to go before you can ship. You end up not actually shipping anything at six weeks and the project just drags on and on and on and you take two months or three months and the major problem with that is the scope tends not to be fixed, but to keep growing.
The longer a project runs, the more everyone feels like they have to jam in everything they can think of because if it doesn’t make the shipping point, it’s never going to happen. That’s one of the benefits of using six weeks as a maximum boundary for your appetite—all the stakeholders know, “Okay, we decided we are going to work on it for six weeks but after those six weeks are over, I get to choose again.” When most executives kick off projects, they get nervous when things start taking a long time because they don’t know when they get to make choices again, and it’s awkward in most businesses to have to react on a timeline shorter than three months, six months, nine months. You have customers telling you things, you have competitive pressures, as well as your own ideas. If you want a sustainable profit, you need to have regular intervals where you can set direction for where the thing should go.
“A breakthrough that we have had, especially in software, is that you have the opportunity to make dramatic progress by having key creative insight at the right moment. You can take one approach over the course of two months and then through creative thinking, you can come up with something you can implement in a week.”
The unfortunate consequence of long-running projects is that no one ever gets to work on one project the whole time. They get pulled in five different directions because there are three different projects that people really want progress on and then they keep constantly switching back and forth.
What you realize is that doers are not built to multitask. They simply stop what they’re doing and then they start something else and the time between stopping and starting something else is surprisingly long. It’s just not very efficient to constantly jump back and forth between three projects. So, our promise to our development team is that we give you six weeks to work on this and in those six weeks, you have that time to yourself; we are not going to interrupt you, set you in a different direction or send you somewhere else. That really brings a whole lot of calm to the workplace. I think it makes quite a difference because one of the key diagnoses to why software companies are really crazy is that they have so many concurrently-running projects.
Having lots of long-running projects that never seem to wrap up lends itself to a lot of anxious stakeholders, project managers, and executives who are constantly pulling people in five different directions at the same time.
It sounds like you’ve identified that this is how humans are at their most productive. Was that the thesis of “It Doesn’t Have to Be Crazy at Work?”
Yes, absolutely. “I think It Doesn’t Have to Be Crazy at Work” is really focused around two major topics. One is time, and the other is ambition.
If we take time first, our early constraint at Basecamp was to decide we are not going to throw more hours at the problem. We started out Basecamp with a pledge—initially just an informal pledge, and eventually a very formal pledge—that we work forty hours a week. We don’t work 50. We don’t work 60. We don’t work 80. We don’t work 100. We work 40 hours a week. That is our boundary. We have to do great work within those 40 hours a week. What we realized was when you don’t have the option of just throwing more hours at the problem, you start caring more about the hours you actually have, and begin turning those hours into quality time. The sad reality is that most people who do throw in 60 or 80 hours a week at work throw in crap time that doesn’t really count for anything. They spend it being incredibly busy while virtually making no progress.
Our realization was it is not necessarily the number of hours you spend, it is how you spend them. It is the notion of complete-time: getting four hours in a row is sometimes more productive than spending an entire week at work where you never get more than 45 minutes to yourself, ultimately meaning you can never make the necessary decisions or true progress on the key issues. So, it’s so easy to be busy at work without getting anything done. That is not to say that we always produce perfect work, but I think we are an example of how this model can work pretty well, not just as a theory but truly in practice over 15, 20 years of running a business.
A lot of times, people will come to me with an exasperated question, like “How do you fit it all in?!” and I look at them in some ways puzzled, because I very rarely feel like we’re running. It’s one of those things—the secret to going fast is to go slow and to go smooth, not because you don’t want to go fast, but because chasing being busy ends up being utterly unproductive.
A breakthrough that we have had, especially in software, is that you have the opportunity to make dramatic progress by having key creative insight at the right moment. You can take one approach over the course of two months and then through creative thinking, you can come up with something you can implement in a week. It is about having the mind space with time and to some extent also the desire to invest in the human conditions that allow good creative work to happen.
That’s one of the reasons we’re so strict on the 40 hours because we want the people who work at Basecamp to get eight, nine hours of sleep. The tragic average in the U.S. today is 6.8 hours of sleep, which is a good hour less than what experts tell us is absolutely crucial to not being sleep deprived. Sleep deprivation is a key way that people end up being unproductive because they just don’t have all their faculties with them. When we’re talking about creative work, proper design, lighting, marketing, or programming, you need your key creative juices available.
It’s another reason why we’re such big fans of promoting work and opposing the open office. The open office is an absolute atrocity in terms of allowing people to do thoughtful work because they are constantly getting interrupted and disturbed either explicitly by someone walking over to their desk, or just because they can’t keep their thoughts in their head due to noise. We try to invest in that human capacity for creative work and when you do so, you realize forty hours is plenty. 40 hours is enough.
Now the other aspect of “It Doesn’t Have to Be Crazy at Work” is a constraint appetite for ambition. We are not chasing unicorn status or trying to be a rocket ship, we are simply trying to build a good, sustainable, fulfilling business that can be around for the next several years. We are happy with it being as it is right now, fifty people. We are not constantly trying to stack up, hire, and expand our company because we’re happy with what we are able to do with the people that we have. I think the atmosphere of calm allows people to do great work in a way that unfortunately just very often isn’t possible at a lot of companies. Many successful companies are just constantly stressed out about meeting quarterly goals because everyone is jammed into an open office with complete disruption. People are forced to work fifty or eighty hours a week either obligatory or implicitly because that’s what the boss is doing. They never end up getting enough sleep.
Everyone looks to Silicon Valley for tips and tricks for how to run companies and I would go as far as to say that that is the last place that you should look for how to run a productive, healthy company. We try to provide an alternative to that; put ourselves out there as an example of how you can have success doing it a different way. That’s why we wrote, “It Doesn’t Have to Be Crazy at Work” because all you hear, especially in the software world, is “hustlemania”, Silicon Valley, grinding it, crushing it, blah, blah, blah, blah.
We need an alternative model, voice, and example out there. There are other companies out there who work as we do; most of them just don’t talk that loudly about it. At Basecamp, we feel that because we do speak out about it, there’s so much compensation we have to do. The echo chamber emanating from Silicon Valley is so loud that it almost feels like a moral obligation. Now that we have an alternative way to work that delivers better life outcomes for both ourselves, our employees, and our customers, we need to share that.
Who could argue with promising your workers a maximum of 40 hours a week for a good life, and in return, they make those hours count? Sounds like a good trade.
What I say on that point is not only is it a good trade in the short term, it is an excellent trade in the long term. The average retention rate in the world is eighteen months. I don’t even comprehend how a company constantly turning over people at that rate can get anything done. It takes six-to-nine months just to ramp up on what we’re doing here, how we’re doing it, and then imagine all of a sudden nine months later that person is gone.
At Basecamp, we have an exceptionally long retention rate. On several teams, the average retention rate is five years or longer. When people have been working together for years and years on end, they develop a shorthand way of working together that is intensely productive, meaning all of a sudden those 40 hours a week count for so much more. The punch of every hour is double, triple, quadruple the punch you would get out of one hour from a bunch of people who barely work together and don’t really know how it is and how things function. I think that the pure math of it, on top of the fact that this is just a humanistic way of working that’s better for people, caters to it being better for business.
Let’s talk about that a little bit because the public SaaS company stocks are doing exceptionally well. They have reached near-record highs. Now, Basecamp hasn’t taken on any funding, right?
We have not taken any venture capital; we have not put any money from external sources into growing the company. What Jason and I did was sell the minority stake of our own stock to get Jeff Bezos as an investor in 2006 through a no control stakes where none of the proceeds went into funding the company. The company has been profitable since day one. We have been able to fund all growth and operations through those profits. In 2006 when Basecamp had been around for just two years, we had been approached by, I think, 45 venture capital firms, at least three different acquisition teams from larger companies, but we didn’t want any of that. All the things we want out of a business are scarcely compatible with how venture capital influences companies to operate. It is certainly incompatible with how small teams end up being devoured by large companies once they get acquired.
We wanted a different path and we didn’t see a way of combining that different path with venture capital, or even investment in a traditional sense. Although we did see that we have a product which was really taking off, creating a lot of waves, but really wasn’t that big of a business at that point. Jason and I took a small amount of ownership off the table that gave us the confidence to go the distance. That confidence played over the next 15 years where Jeff got to be along for the ride but had no say in how we ran the company or what we should do with it—it was a no control stake with no board seats. We got to learn from someone with an entirely different perspective—you almost couldn’t find a more diametrically opposed growth approach. That is another reason why we were interested, because if you just get someone who already shares all of your values, already thinks the same thing about everything, what are you going to learn from that person?
We wanted to, in part, learn from someone else. Even more to the point, we wanted to take risks and, in essence, the con of the price, right? When you are at the helm of a hot, glowing software company, you are in no want for offers from investors and acquirers to hand your business over. Both Jason and I didn’t come from rich backgrounds, so when someone came dangling millions in front of our faces, that was tempting, and we wanted to take that temptation off the table. We did that by doing a minority deal that just filled up our bank accounts enough to feel like if this whole thing blew up 9 months later, we at least wouldn’t be left with nothing.
It’s one of those things that I’ve talked about many times over the year: that I wish that opportunity was available for more founders. An opportunity to raise money on non-ventured terms where you’re signing up to become the next unicorn but you’re not signing up for the life that comes with it. What’s really interesting is that just weeks ago some progress has been made. There are new funds (Editor’s note: see the article on The Best SaaS Funds in 2019 for more information on funds) that bring in new models where you can raise the money and you have the opportunity to pay it back. It doesn’t have to be that you get put on this rocketship ride.
That’s how we did it in Basecamp. Today we have 3 people with stakes in the company. That’s Jason, me and Jeff. He still has his minority stake (even though we have paid it off 5 times over). We have delivered there, so it still turned out well (even if it is a rounding error in the math on his ledger).
That’s a funny juxtaposition. Is there anything that you still implement today that you have learned from the time being mentored by Jeff Bezos?
Absolutely. We used to meet with Jeff about once a year, but we haven’t for a long time. When Jeff made his investment in 2006 he was thinking “Oh man Amazon is a large company” but I think they had 15,000 employees. Today they employ around half a million people. Jeff is literally the richest man in the world. He has a lot of other concerns other than advising our fifty-person software company today. So, we really haven’t talked to him for a long time; but when we did, he imparted some really good lessons. One of the ones that stand out that we still talk about and we still reference is investing in the long term; investing in things that don’t change.
The more you invest in distribution, the more it’s going to pay off over the long term. That’s the kind of investment we like to make, things that will pay off over 10 years. For example, investing in how we run our company and how we develop our method of working (which we have recently published in the form of the Shape Up book) is just one of those things that keeps paying off. Investing in the humanity of our employees, making it sustainable enough that they can work for five, seven, 10, years without burning out, is something worth doing. Investing in our legacy. We still have some customers who signed up that first month in 2003 who want to have that original version of the software, even though we have since released two additional versions of the software, Basecamp 2 and Basecamp 3. We still run the original version because that’s what some customers like. No one likes getting pushed into a new version, having their cheese moved around, to get a complete reorganization of their workflow on someone else’s schedule.
So that’s one of the things we have chosen to invest in. It is so common on the internet today—and Google perhaps is the biggest perpetrator of this—to launch something, get people to sign up, collect all their data and then 18 months later find that you kind of lost customer attention, lose interest in it or you just shut it down, and then have to tell people “Hey you have X weeks to get your digital stuff and get out.”
We didn’t want to be that company, so we invested in longevity.
Do you share revenue stats or KPIs publicly or do you keep that under wraps?
We keep that private. We share loose stats like the fact that we have over a hundred thousand paying customers. Basecamp has been profitable since day one, and we are profitable to the tune of many millions of dollars every year. I think part of that is that is not why we are in it; we are not chasing becoming a billion-dollar company thinking all our hopes and dreams will be fulfilled. No, we have perhaps simpler goals and simpler KPIs. Run a kind company, one that is reasonable to employees and to customers, and that often is incompatible with the steepest growth curve. Most of what’s called growth hacking today is seriously unsavoriness, dark patterns, and greasy marketing approaches. We wanted none of that. For example, we declare Basecamp to be a Facebook free business. We don’t have a presence on Facebook, WhatsApp, and we don’t buy advertisements with any of those platforms.
In fact, the whole surveillance capitalism is seriously unappealing to us, so we don’t buy into it. There are a bunch of things we have said we’re not going to do even though it is going to cost us money, because our principles and the passion we have for running a conscientious company is worth more. Jason and I have already reached the point that we may have made enough money, and we know we are not making money for someone else. No one else is standing behind us breathing down our necks telling us “Hey why didn’t you grow 10% this quarter?” “What are you going to do for the year?” “I need a hundred X return on my investment”. So, when you don’t have the pressure, you can be more human and less of a robot in how you choose to run your company. That has been a defining characteristic of how we wanted to run our company. We wanted to run the company on our terms, and a lot of those terms were humanistic and almost uncapitalistic in their approach. Another example of this was we set our salaries at Basecamp at the top 10% of San Francisco level. We don’t have anybody from San Francisco, we are not based in San Francisco, and yet we chose to make that our benchmark for pay at Basecamp because that felt like the right thing to do.
It happened that we were a profitable company for a long time, who could have gotten away with paying employees simply the least you can get away with, but that never was an appealing prospect. We actually even went one step further this year and have raised the minimum pay at Basecamp to $70,000, including everyone who works in customer support and other areas. Even if you go to San Francisco, the top ten percent of customer support agencies are not paying $70,000 a year. But we can do that and wouldn’t think it was going to bankrupt the company. Yes, it was going to make us less profitable and perhaps we could hire fewer people if we were constantly trying to hire, but none of those things are optimized for.
“Through a small minority stake in the early days of the company, Jeff Bezos got to be along for the ride, but had no say in how we ran the company or what we should do with it—it was a no control stake with no board seats. We got to learn from someone with an entirely different perspective—you almost couldn’t find a more diametrically opposed growth approach.”
I want your perspective more on the major companies that have IPO’d in the last year, year and a half. We have DocuSign, DropBox, Spotify, Slack. They are all obviously making headlines every day. Do you think that they have any kind of commonalities? We know that many of them are not profitable but that is another story.
Actually, I think that is a key part of the story.
The lack of profitability, the lack of having a business that just works on its own terms and not in terms of just promising tomorrow tells you a lot about that kind of business: when growth is above all else because that is the only way you get valued and founders and investors get paid. They don’t get paid for creating a profitable business. They get paid when they show promise which just means a high growth rate, right?
It really encourages a whole underbelly of very insidious behaviors. We have talked very briefly about growth hacking and I think growth hacking falls out from this idea that if we show these crazy year-to-year growth rates, whether that’s ethical or viable in the long term. There’s a lot of behaviors going on in the market that very short term dominated because in many cases, you just have to last long enough until the bag is sold to someone else. Now this doesn’t mean that these companies never turn out to be good companies or they never turn out to be profitable, but a lot of them don’t, right? A lot of them will make it all the way through, whether that’s benefits or any of these other software companies of yesteryear that we can think of, billions of dollars, and never came out on the other side showing any profits and yen. It’s not just about profits because that gives it such a negative connotation. For me, showing profits is part of showing good stewardship for more stakeholders for more than just your investors.
The investors are optimizing for growth rates because that’s how you get the big multiple and that’s how you get the biggest bang for an IPO. I’m not a big fan of these methods, because most of the time, the large valuations are based on the premise and promise that these companies will dominate the market that they’re in, capture a monopoly and then one day, once they have eradicated every competitor and become the top dog that dominates everyone, they can raise prices because customers will have nowhere to go and that’s when they make money. Is that an aspirational place for us to be, that we should be cheering on monopolists who are cornering markets and then when we have eradicated all competitors, they raise rents? That’s not a very appealing prospect to me. I’d much rather see healthy marketplaces where there’s lots of different providers.
You must compete for the customer on the merits of the product and on the merits of the company, not just on the basis of buying out or running everyone else out of business. There is an unfortunate strain of Silicon Valley that dates all the way back to the nineties (and even earlier). Facebook and Google are capturing almost all online ad revenue to the detriment of journalism and newspapers everywhere and I’m left thinking, “Really? Is that what we want the smartest brains in the country doing? Just optimizing new clever ways to get us to click on ads?” I don’t know; it doesn’t seem very inspiring to me.
Now that’s what some of these newer generation companies do. They are influenced by the thinking that growth is above all else. I think that’s not a healthy place to be. I’d rather see a much broader set of companies that are medium-sized rather than these behemoths—these unicorns that just end up trampling on everyone else.
Since you don’t advertise on social media, what is your top customer acquisition channel? Word of mouth?
Great question. Yes, word of mouth is our number one channel. Since we got started with Basecamp fifteen years ago, we have never had a full-time dedicated marketing person or a full-time dedicated salesperson. Marketing is what we do when we speak, when we write, when we promote these alternative ways of working. It’s funny, over fifteen years you have a lot of ideas and principles about how you run your business, but you also need to revisit them. One of the things we have revisited weekly is the wisdom of whether relying solely and exclusively on certain practices is wise.
Actually, we have just listed an opening for a head of marketing person at Basecamp, and they would be the first person ever to have that role at Basecamp. We want to do some more traditional marketing, not surveillance capitalism, but brand marketing where we can activate some of that goodwill we have been creating over the last two decades. We have found ourselves in the scenario where someone will read our book or I’ll do an interview with you and they will read that but then fail to draw the connection to the fact that we actually sell a wonderful product that could probably help them. We have been neglecting that work for a long time and relying on having it happen automatically. I think that that’s not actually a sustainable practice once the marketplace gets more crowded, which it certainly has. We had almost none of the competitors we have now when we started fifteen years ago. That’s one area where we’re trying something new—well, new for us obviously. This is what the vast majority of companies do in the world. They’re marketing in other channels, and we haven’t, so we’re going to try and see how that goes.
The other side of that is putting some money back into an ecosystem where you recognize that quite a bit of it is going to be a waste. If we are going to waste half the money, we are making sure that it doesn’t go to Google or Facebook. It goes to, let’s say, a podcast advertisement on NPR. Even if that ends up producing no additional customers at Basecamp, and I would hope it does if we did the advertisement, we still sponsored NPR and that’s not a bad thing. There are plenty of opportunities to do this in this industry. We put money into sponsoring events or podcasts, or whatever else it is where even if it doesn’t work, it still feels good.
Whereas with a lot of traditional pay per click advertising, it doesn’t feel as good to give money to these companies. If you advertise with Facebook, maybe it works, maybe it doesn’t work. But whether it works or not, it never feels good. Putting more money into the pockets of Mark Zuckerberg is never something that makes people go, “Oh man, that was good. That was really what I built my company for.” Right?
Would Basecamp ever want to be an example of a company to go public on this type of moral model?
I think in some ways I have this pipe dream, like “Wouldn’t it be nice to set an alternative example?” But then I also know that it’s a pipe dream. Once you sell your company—and you do sell your company once you go public—they have a say in how it’s run. In fact, I’d go as far as to say I think it’s immoral how Facebook’s stock structure is made, where Mark Zuckerberg gets 51% of the voting rights in a company he owns 14% of (or whatever is left of his stake). That’s an immoral construction to me. I understand reasonable people can disagree about that or not, but to me, that is a key point. If we went public, and we sold our company to other people, they would get to call the shots and I don’t have a lot of faith that they would keep things how we keep things. We have a tendency to operate in ways that are different from most people, and if we have to suddenly run our business and dictate our day on how a bunch of investors saw things, I don’t think I’d be interested in working at the company for the next twenty years.
Subscribe for free to read the full SaaS Mag including other interviews with Asana COO Chris Farinacci, SaaStock Founder Alex Thuema, Tomasz Tunguz, and more…
