DHH

I remember when it was cool to root for Apple. Back when they were the underdog crawling back from the brink of bankruptcy and fighting to give the world an alternative to Wintel. Those days are long, long gone. It is categorically uncool to root for Apple these days.

And that’s fair. They’re not an underdog any more. They don’t need anyone to cheer their lead. In fact, the opposite is true. Now that they’re the 600 billion gorilla, they need scrutiny and competition, not blind admiration.

But that doesn’t mean you can’t be impressed. Or even in awe. And I am most certainly in awe of Apple. It’s like watching Serena Williams over the years. Her domination in the sport hasn’t always made for cliffhanging action, but it’s been a marvel none the less.

There’s just something deeply inspiring about seeing what companies, teams, and people can accomplish at the peak of their ability. Especially when it’s happening not just for a single season, but as a reign of excellence.

That’s what we’re still watching: A reign of excellence. That doesn’t make the company, its products, or its people infallible. And various moments throughout this reign might have had more sparkles of innovation and disruption than what we’re seeing now, but there’s no denying what a juggernaut of impact it still is.

Also doesn’t guarantee it will continue tomorrow and certainly that it won’t forever. Nobody gets to reign forever (thank god!). But we shouldn’t be so proud not to recognize and applaud when it’s happening.

So Apple, I applaud you. We’re on the cusp of a decade since the first release of the iPhone. It’s astounding just how well you’ve been able to improve, iterate, and stay the champ for so long.

---

Perhaps no company has provided more direct inspiration for Basecamp than Apple. For a while it was so overwhelming that we banned all comparisons, just out of how common and trite they had become. But I’m getting more at ease with just surrendering to that towering shadow and be fine with it.

When I first began making applications for the web, getting started was hard. Just figuring out which components to download, how to configure them, and getting Hello World through it all was a daunting affair. Frameworks like Ruby on Rails changed that, and now it really is possible to animate a complete database-backed web application in 15 minutes or less.

That means these days you can go from (almost) zero prerequisites to a (sorta) working software prototype in a bootcamp’s worth of introduction material. That’s amazing. Basic proficiency has never been more attainable or approachable.

Given this leap, it’s no wonder that people mistake the beginning for the end. That getting started is the same thing as knowing it all. But it remains a completely unrealistic expectation, and thus a mistake. Building a complete information system, like, say, your Basecamp or Shopify or GitHub or Zendesk remains real work that requires deep skill. It’s foolish to pretend otherwise.

And perhaps we have pretended otherwise at times. I’m certainly guilty of focusing on just how easy we made getting started that the conversation often didn’t extend to the work it takes to finish. Simply because that’s what felt like the main obstacle to getting more people onto the path of learning at the time.

Now that this obstacle is mostly cleared away, it’s time to focus on the latter part of the discussion: Becoming really good at anything takes time. Web development is no different, not even with Rails. We’ve changed the game from “hard to learn, hard to master” to “easy to learn, hard to master”. Yes, the second part remains the same.

I’m still learning. I’m still getting better. And I’ve been at this web development game for damn close to twenty years (if you count when I started dabbling with HTML/CSS). That doesn’t at all mean it’ll take you twenty years to become good at it, but it probably does mean that you should have realistic expectations about what you can learn in three or six months.

And it’s not so much about how long it’ll take you to learn your way around the framework or the language or the ecosystem. It’s as much as how long it’ll take you to become an expert. It’s one thing knowing there are 10 different ways to do a thing; it’s another to know which is a better fit and when.

This is part of why I like to compare writing software with writing prose. Most people in the developed world will have basic proficiency writing their native tongue by the time they finish high school. But how long does it take to become a great writer? Longer than that. Much longer, in most cases. Few find that surprising.

Yet plenty of people do seem to be genuinely surprised that a developer who just picked up Ruby on Rails, or any other extensive framework, language, or ecosystem, doesn’t make all the right choices the first time they’re faced with them. And that’s just plain silly.

Let’s continue to celebrate how easy we’ve made getting started, but let’s also set a realistic timeline for mastery. Not to scare anyone off the journey, but to prepare them for it. A glorious, years-long journey of learning. It’s a lot of fun if you know what you’re in for.

I think Noah Lorang is exactly right on the data-nutritional value of real-time dashboards. It’s all empty calories. Like a bag of M&Ms or a serving of McD french fries. Salt, fat, and sugar. If that’s the main diet of information you’re using to grow your business, you’re not going to end up in a healthy place.

But there’s another way to use real-time dashboards. That is to realize that, yes, they are indeed empty calories, and, no, they shouldn’t supplant a properly prepared, slow-data analysis of what’s really going on, BUT. BUT.

SOMETIMES YOU JUST WANT A DAMN CHEESEBURGER!

Sometimes, intentionally being unhealthy feels so good it’s worth it. Especially if you’re just in need of a little spike because the going is tough or you’re trying something new that’s hard. That doesn’t for a moment mean you’re giving up on the virtues of #SlowData, merely that you accept your the existence as flawed and succumb to the occasional vice.

My wife occasionally gives me grief about drinking soda. And I know it’s not good for me, but holy fuck a three-degree-Celsius-chilled, cane-sugar Coke served in a glass bottle is just damn delicious. The way I justify this indulgence is with hyperbole: Everyone needs a vice. It’s either this or hookers and blow!

I kinda think the same of real-time dashboards. They’re a vice, but vices are fun. They don’t give me deep insights, but cheap highs to keep going. They’re quick and early, and sometimes wrong. But if we’re trying something new to attempt to move the needle, I’ll accept the risk of the early indicators being wrong before they’re statistically significant in trade for the snappy feedback.

It’s possible to like Mozart’s Symphony №4 and Justin Bieber at the same time. It’s possible to accept both your virtues and vices. Just as long as you know which is which and keep the ratio between them right.

---

I’d like to think that we drive most consequential decisions at Basecamp through reasoned logic, statistically signicant empirical findings, but I’ve also come to accept that some times we Just Wing It. Some times we just go on gut or on belief. You be the judge of whether we got that balance right, if you give Basecamp 3 a try.

One of the real delights of programming is picking great variable, method, and class names. But an even greater treat is when you can name pairs, or even whole narratives, that fit just right. And the very best of those is when you’re forced to trade off multiple forces pulling in different directions. This is the story of one such case.

It started with a simple refactoring. We allow people to post arbitrary URLs in Basecamp 3’s chat, which we’ll attempt to fetch and display inline, if its an image, movie, or a Twitter URL. There’s a security concern where we don’t want to allow internal IPs in those URLs, like 127.0.0.1, and then have our Downloader class attempt to trigger an internal request that may sidestep other security precautions.

The specific policy isn’t as important as the fact that this precondition was originally just part of the Downloader class, but now I also needed it in our forthcoming webhooks API. Because just like with previewable chat URLs, webhooks allow users to set URLs that our system then calls. Same underlying security issue to deal with.

No problemo: Just extract the protection into its own module and call it from both spots. First attempt at naming this new module gave me PrivateNetworkProtector, which seemed like a fine choice until I considered the method names that’d work with it:

• PrivateNetworkProtector.protect_against_internal_ip_address(ip)
• PrivateNetworkProtector.verify_ip_address_isnt_private(ip)

Hmm. I didn’t like any of those choices. Both are a little too wordy and both include a negative. And come to think of it, I wasn’t even that thrilled with the word Protector. It implies something like surge protection, where it just negates the effects of an outlier input. That’s not really what’s going on here. We’re on the lookout for malicious attempts, so a better word would be more forceful. More focused on a threat, not just a risk.

Let’s see what the programmer’s best friend, the thesaurus, had to offer:

Lots of possibilities there, but the one that really spoke to me was Guard as in PrivateNetworkGuard. Nice. Now I can imagine some big burly fellow checking credentials with an attitude. Just the right image. So back to the right method name. Let’s try the two choices similar to what we had earlier:

• PrivateNetworkGuard.guard_against_internal_ip_address(url)
• PrivateNetworkGuard.verify_ip_address_isnt_private(url)

Hmm, neither of those are right either. I mean, you could use guard again, but the double confetti of this repetition just annoyed my sensibilities. What if we thought of the Guard as something like a prefilter, like before_action in Action Controller? That’s promising:

• PrivateNetworkGuard.ensure_public_ip_address(url)
• PrivateNetworkGuard.ensure_no_private_ip_address(url)

Still not quite right. The ensure verb just doesn’t quite fit with the forceful idea of a Guard. It’s too meek. This isn’t a casual checking of credentials. This is IF THIS HAPPENS, I’M RAISING AN EXCEPTION AND BUSTING THE REQUEST!

That lead me to think of the programming language Eiffel and the concept of design by contract. So I browsed the Wikipedia entry to see if I could mine it for a good word. Eiffel uses require to state preconditions, which is what we’re doing here, but that also didn’t see right: PrivateNetworkGuard.require_public_ip. That’s more like something you’d write in a specification to tell well-meaning actors what they’re supposed to do. This wasn’t about well-meaning type, but rather the nefarious kind.

So I tried the thesaurus again, going off ensure for alternatives:

No great candidates here. I mean, they’d all work, but they don’t feel quite right. And that’s really what this whole expedition is about. Not just finding something that could work, but something where you go: Yes! That’s perfect! How about something in the realm of Guard then?

Nope. That doesn’t do it either. But one word stood out as an idea: Police. The Guard is policing the incoming ip addresses to make sure that an internal one doesn’t slip through. That’s interesting. Let’s keep pulling on that thread:

ENFORCE! That’s it. Let’s try it out:

• PrivateNetworkGuard#enforce_public_ip(url)
• PrivateNetworkGuard#enforce_no_private_ip(url)

In some ways I like the negative version better, since it strikes to the heart of the responsibility: This is about catching those malicious URLs with private IPs more than its about vetting that something is public. Two sides of the same coin, perhaps, but still an important distinction.

In the end, though, I went with PrivateNetworkGuard#enforce_public_ip(url) because I liked keeping a positive method name more than the slightly more apt negative version. Weighing those two subtle trade offs and picking the concern that mattered more.

Now this might seem like a lot of effort to expend searching for a slightly better name, but it goes straight to the heart of programming with a smile. I ventured out to find a great name, not just a passable one. And besides, this whole exercise might have taken five minutes at the most. So not exactly blowing the budget, but definitely lifting my spirit. Isn’t programming great?

---

Basecamp 3 was laboured over with tons of this kind of excessive/obsessive care. You’ll never be able to tell, but you can trust that we put this sort of consideration into the product in all sorts of other ways that are visible. It’s fun to bother with quality that can’t be seen.

Maybe if you fire a hundred people, you’ll eventually get used to it. But I doubt it. Firing people is horrible. Nothing has stressed me out more in the past twelve years of running Basecamp.

Of course, however hard it is to be the one to fire someone, it’s endlessly worse to be the one fired. I’ve only really been fired once in my life, but the experience scarred me just the same.

Twenty years later, I remember almost everything — the number of steps up to the entry, the messy desk, the half-empty coffee mug. Stronger still, I remember running the full range of emotions: Shocked, angry, disappointed, sad. The utter humiliation of having to go back into the office because I forgot my goddamn bus card, as I couldn’t get home without it.

It’s not a stretch to say that experience helped shape the desire to run my own business. To have partners, but not bosses. All this, solely from being fired from a manual labour job at a relatively young age, which had basically zero practical consequences for my life (beyond the emotional anguish!)

Yet while I can extrapolate from that dreadful day, and imagine what it might feel like to lose my job if it was my career, if I had real bills to pay and maybe a family to feed, it really is just that: A mental image.

But it’s exactly that mental image that makes contemplating firing someone so haunting. Telling an employee that their time at your company is up is the ultimate power of the boss. It’s not to be taken lightly. It won’t be felt lightly.

And still, sometimes firing an employee is just what needs to be done. There are all sorts of good reasons this person in that job at our company just isn’t working out.

That’s no verdict on what that very same person might do at a different company or in a different job. Excellence is highly situational. You can completely suck in one environment and be an ace in another. It’s incredibly important for both parties to remember that.

Because while it’s possible that someone is blissfully and utterly unaware that things aren’t going well, that’s usually not the case. Most of the time, there’s at the very least some sense that things aren’t great. It may still be a shock that “things aren’t great” turns into a person getting fired, but at least the seed is there.

The best case scenario is when the employee and the boss are in total sync about where the relationship is going, and, despite best efforts on both sides, it just isn’t. So termination becomes the natural conclusion with no drama.

That scenario is probably as likely as the blissfully unaware one is. Yes, it does happen, and when it does, that’s great. But don’t plan on it. Expect that this is going to be traumatic and be positively surprised if it isn’t.

Here are some of the key considerations we’ve been taking the few times we’ve had to fire someone:

Minimize the time for fake smiles

There’s never a great time to fire someone, but delaying the execution only makes it worse. Every interaction between when the final decision has been made and until its carried out is a painful charade. Humans leak emotions like sieves, so the longer you have to carry on the fake pleasantries, the worse the sense of humiliation or even betrayal will be.

The best timing is the uncomfortable right now. Don’t drag and dread it out.

Come prepared

Since this is generally a really stressful situation, come prepared. It might not seem as natural to read an opening statement that clearly spells out a) you’re fired, b) these are the terms we’re offering, and c) this is why, but it’ll ensure you considered and covered all the important bits.

Give the person a separation agreement that includes all the details, as it’s not unlikely that the shock will deafen their memory. Tell them to read it thoroughly, to consider a lawyer’s assistance (they are usually giving up certain rights to take the severance payments and should understand all the terms), and to return it signed only after they’ve considered everything.

Be so generous it stings

If you’re firing someone because the company is in poor repair, you might not have a choice but to send someone packing with the bare minimum. But if you’re firing someone because you’ve decided that things aren’t working out, you should be so generous that it stings.

It doesn’t matter what you think this person could or should have done while there was still time. Unless they’re going out on gross negligence or malice, it’s mostly on you. It’s on you for not vetting better, for not following up better, for not directing better. The buck stops with the boss. Every personnel failure is ultimately your fault. Just own that.

Then consider severance consummate with that responsibility. At Basecamp, our general rule has been one month of pay for every year of hire. So if someone has been with the company for three years, that’s three months’ worth of pay, with a minimal number of strings attached in the separation agreement.

Don’t leave the door open

It’s a natural reaction for someone getting fired to see if there’s a way to prevent it from actually happening. Don’t invite hope where there is none. If you’re not sure whether someone should be fired, then don’t fire them! Find another way to give a second or third or fourth chance.

Only call that meeting to fire someone if the decision has been made and it is final. Then make that astoundingly clear right away. When someone is getting fired, it’s not a place for casual conversation. Treat the moment with clarity and dignity. Don’t set a false sense of security by opening up with small talk or a smile.

Decency of trust

Just because you fired someone doesn’t mean they’re instantly untrustworthy. They clearly earned your trust enough to be hired and they were working under that trust until minutes before they were fired. So the corporate trope of having their desk cleared out, access to all systems immediately revoked, and someone escort them out of the building is not only unnecessary, but antagonistic.

Again, yes, sometimes people are fired for cause where precautions should be taken. But most of the time that isn’t the case. Treating someone with instant mistrust because they no longer work for you is just needless salt in the wound.

Be amicable, be decent.

Inform everyone else

When people just disappear from the company with no warning and no explanation, everyone else is just going to assume the worst. Am I next? Are we going out of business? Was this because of that one time where that person said or did this?

If you leave a void by keeping the reason private, it’ll quickly be filled with uninformed stories. How is that going to help anyone? It’s better to be reasonably honest without any needless dwelling on the personal. But the rest of the company should know, and quickly, that their colleague is out.

That’ll surely be an uncomfortable thing to write, but firing people isn’t supposed to be easy! It’s supposed to be hard and dreadful, lest you lose the respect for how traumatic it often is on the other side. Which is why you shouldn’t try to excessively euphemize it either. Don’t tell others that someone just fucking graduated when they really got fired.

Learn from it

You did someone wrong for it to come to this. The company did something wrong. Something could surely have gone and should have gone better, and if it had, maybe you wouldn’t be in this situation. It’s critical that you and the company learn from every, hopefully rare, instance where someone gets fired.

It’s hard to collectively learn something if you don’t diligently try. So please try. Have a proper retrospective. Accept the blame, or at least the bulk of it. It’s so fucking easy to just lay it on the employee, and it’s almost always the easy, wrong way out of a hard look at yourself, your policies, and your company.

Again, it’s okay to feel like a failure to some extent because of this. Firing people should be expensive, stressful, and at least a bit personally embarrassing, if not outright humiliating. You want the scars to remind yourself of how to hire and be better the next time.

I’m a sucker for controversial trade-offs. Companies that dare say “this one thing is more important than this entire set of other things people usually consider must-haves” take a shortcut to my wallet.

Apple is the oft-heralded example. When the first MacBook Air came out, it garnered a hilarious amount of scorn and disbelief from the technorati. How could anyone live without an optical drive?! With just one USB port?! A processor slower than the fastest one on the market?! All toward the mere pursuit of slimness? PSH!

Turns out lots of people could. Most people even. I certainly could. Jason Fried as well. We both adopted the MacBook Air right from its release and used it as our primary machines. (The same disbelief/acceptance cycle is now playing out with the latest USB-C MacBook).

But this isn’t really the interesting example of extreme trade-offs, just one of the more publicized. A far more interesting example is the recently released Leica M-D 262 camera. It’s a digital camera without any settings and without a screen on the back! You can’t even format an SD card in-camera. Oh the humanity!

Most of the camera world is up in arms about the sheer arrogance of Leica to release something with so much less that even costs more. Yes, that’s right. The version of the 262 without the screen on the back is about 10% more expensive than the one with the screen. I love it.

I love it for the same reason that I love driving manual transmission cars. It’s inefficient, it’s more work, it’s less accessible, and it’s completely wonderful in the right setting. Leica is trading off technological progress to allow a small niche of purists to have more fun and a stronger connection to their camera, just like Porsche is bringing back the manual transmission to their top-tier 911, the R.

It reminds me of the Ruby programming language. Do things that are worse for the machine, that make programs run slower, but widen the smile on a programmer’s face. Make things objectively worse to make them subjectively better.

Of course, it’s this conflict that’s at the source of all the controversy. It’s easy for everyone to cheer when the computer is upgraded from 2GHz to 3GHz. That’s progress everyone can easily get behind. But the progress that says “to make something 10mm slimmer and 300grams lighter, we’re going to cut out these things that some people really like” — now that’s courage.

Deciding to cut out useful, table-stake features from a camera, like the back screen, to tickle the emotions of a small niche of photographers? That’s German balls of steel.

Vorsprung Durch Emotionen!

Running a large, long-running open source project like Ruby on Rails is very rewarding but can also be exhausting. The glimmers of glamour usually only sparkle around release time, but the grunt of the grind is daily.

The grind is an endless stream of bug reports, requests, demands, questions, and occasional inquisitions. To avoid getting stuck in the mud, you need to travel as a team, not solo on a lonely road. Without the backing of stable, friendly faces, you simply aren’t likely to go the distance. It’ll be thanks for the fish and adios muchachos!

A big part of this feeling is that co-chairing a popular open source project means you’re always ON in the public space. Every reply to every ticket, every comment to every discussion is fair game for dissection, scrutiny, applause, or ridicule.

Doing the work of justifying choices, presenting arguments, and collaborating on code in public is great for transparency, but also at the heart of why the work is so draining. Everyone needs a place and a time to retreat. To step out of the spotlight and loosen the guard.

We’ve embraced that need on the Ruby on Rails team through a series of contracting circles of intimacy and privacy. There’s the community at large, where all the interactions happen in public on GitHub or the mailing lists or wherever. But then there’s also a Rails Community Basecamp, a Rails Contributors Basecamp, and finally a Rails Core Basecamp.

I appreciate that the standard response from the open source gospel is that this is somehow sacrilegious. That total and complete transparency into all matters of an open source project is more important than the mental well-being of its long-term, key contributors.

I’m sympathetic to that ideal. Surely Rails would be worse off if everything happened behind closed doors, the community at-large wasn’t involved in anything, and releases just dropped from the sky. But there’s a nuanced world of grey beyond those extremes where healthy, happy people live and work.

We’ve long since accepted how pivotal our individual idiosyncrasies are to the art of programming. That much of the work in programming tools and languages reside in tickling the interface between code and our all-too human emotions. It’s well past due that we recognize the same fallibilities are present at the group-level of development, and that we find ways of working to accommodate these.

I’ve worked on Ruby on Rails for more than thirteen years now. The only way that’s been sustainable and enjoyable has been to protect my sanity and motivation in dealing with the encouragement and discouragement, judgment and praise from thousands of strangers over the years.

Letting smaller groups do some of the work and shoulder some of the exhaustion in private has been a key strategy. It’s a small trade-off to complete transparency for the well-being of the most active participants. I’m not going to feel bad about that.

---

When we started the Ruby on Rails core group back in 2004, it was just a private IRC channel. We then leveled-up to Campfire in 2006. Most recently we’ve leveled-up again to a full-fledged Basecamp 3 account that doesn’t trap us in chat. It’s been liberating!

I waste a lot of time sweating small details of code. Stuff that has absolutely zero impact on anything quantifiable. It took me a long time to stop feeling bad about this.

I’m not talking about turning awful code into great code, but polishing code that’s already plenty shiny over and over. Fretting over the length of a line, fussing over the proper indention, questioning the right number of returns. Superficial stuff. Pedantic stuff.

The payback isn’t that the piece of code will run faster, be easier to maintain, or even read clearer to other programmers. It’s purely a selfish act. It’s indulgent. And I’ve come to find it totally worth it.

For me, the limiting factor in writing code is rarely the number of hours in a day. I can’t program for shit after eight hours anyway. No, the trick is to feel motivated to do ever-longer stretches of work without letting interruptions tuck at my sleeve. To ride the high of the zone.

Sometimes the work itself is just so damn appealing that finding the zone is quick and easy. Those are the easy days. But other times it takes more effort, and I’ve found that effort goes down a lot easier when it’s not just the value of the output that has to drag the donkey to the trough. Spiking the motivation with sugary treats that tickle my idiosyncrasies along the way has proven a worthwhile mental hack time and time again.

It’s easy to feel guilty about such creative wankery, but foolish too. Accepting that you, as a human, are a deeply irrational beast of habit and motivation is liberating. It sets you free to find whatever hacks you need to deal with procrastination and distractions.

It’s not silly if it works.

---

You wouldn’t believe the number of hours I’ve poured into the Basecamp 3 codebase fretting over inconsequential details. But I hope you will believe that greasing my motivation with such fluff also resulted in a great piece of software. If you run a small business and want to regain control of it, now is a great time to signup.

This interview was conducted by Ritika Puri for Startups.co under the title of Build a Kick-Ass Startup (on your own terms).

Q: Why do early stage founders, particularly bootstrappers, need to hear your story? What are the things that have made you proudest as an entrepreneur?

I think Basecamp has become a role model to some because we offer a counter narrative. In a technology world obsessed with funding rounds and exits, we not only thrive on the opposite waves, but we dare to flaunt it! There a plenty of companies like Basecamp out there, but many of them just bow their heads and speak too softly. Partly because they are rocking what they’re doing and don’t need anyone else’s attention, but I think, also partly because shouting against the wind is exhausting for most.

Oddly enough, I take a perverse enjoyment to shouting in the wind. To speak against the predominant story lines. So that gives people of like mind a public flag to point to. And I’m proud of that. I’m proud of being used as an example for people who wish to bootstrap, become profitable, stay small, or any of the other motivations for being in business that have little commercial and industrial backing.

Q: In your Medium post Reconsider, you criticized startup cultures in which founders “have to fucking own the universe.” You also mentioned that a better approach would be to leave a dent instead. What dent are you trying to leave, and how have you been able to stick with it for 12 years?

I’m very proud and content with the dents I’ve already left in the universe through the work on Basecamp and Ruby on Rails. We’ve helped so many people make progress together through both systems. It warms me when I talk to customers of Basecamp who’ve been with us for 5 or even 10 years and they explain how they consider the software an integral part of how they’re able to do what they do. Helping others help themselves is gratifying work.

Ruby on Rails took Ruby into to the limelight and helped set a different course for a whole industry. Popularizing an outlook on programming as, in part, the pursuit of happiness for programmers themselves. Not just about getting performant software done with the most features for the lowest cost. It’s a craftsman’s journey with an unusual high degree of care for the tools and their impact on the not just the productivity but psyche of the practitioners.

I think that’s really the key to longevity in business. Escaping the need to declare finish lines, goal posts, and other sources of external validation or success. I’ve chosen to define success as doing what I do every day with a smile. The act of programming, and getting better at it. The refinement and occasional redefinition of what we already have. There’s such tranquility possible when you stop being on the run from one thing to the next and accept your settlement as the place to be.

Q: Along those lines, can you share examples of good decisions you’ve made? What stories would you share with founders who are scared to make big judgment calls?

I think the best decisions we made at Basecamp were the million small ones that were easy to change. Steering the boat by a thousand tiny inputs rather than big, sweeping, grand gestures. Having a habit of making efficient progress by those small, reversible decisions. Resisting the lure of Betting It All on a few big moves.

That being said, we have made a couple of big moves that I’ve come to enjoy because they made sense at the time. Funnily enough, two that stand out are in direct opposition, but both made sense because of when they were made.

The first decision was to diversify from just Basecamp to other products back in the mid-2000s. We launched Campfire, a chat program from before chat was cool. Highrise, a CRM that’s still going strong, and stronger still since we spun it off. And finally Backpack, a personal information management tool. So we ran a suite of four products for many years that gave us options in case any of them, especially Basecamp should peter out. Positioning our odds for the greatest chance of survival and thrive.

The second decision was to become Basecamp. The realization that our diversification strategy was no longer necessary, Basecamp had long since reached escape velocity, but actually hurting the other goals of the company. Which included staying small and making the best things we possibly could. Basecamp’s continued and compounding growth simply meant that either we gave it our full attention or we would have to become a much different (and larger) company to properly service and do justice to all the other products as well.

Q: As you’ve built Basecamp and grown your team, you’ve been very vocal about resisting the temptation of unicorn culture. Was this an understanding that you had off-the-bat as an entrepreneur? How have your perspectives changed?

It wasn’t without temptation or struggle to stay like this, though. Especially in the early years, before our bombastic views on venture capital, the IPO rat-race, and other ills of funding were known. We had, I think, close to 50 different VCs get in contact. A couple of large companies doing the acquisition sniff as well.

Ironically, part of what did give us the confidence to turn down that whole world was a — by startup standards — small sale of equity to Jeff Bezos. Our company had been profitable all along, and we weren’t interested in adding rocket fuel to propel growth faster than it already was (which was plenty fast, thank you very much!). But Bezos bought a small, no-control stake from Jason and I personally, which gave our personal bank accounts just enough ballast that the big numbers touted by VCs and acquisition hunters lost their lure.

I really wish that model would see greater providence. That founders who are on to something find ways to diversify their accounts just enough to dare go the distance. Because once you let in the VCs or the private equity folks, there are only three options: Implosion, acquisition, or IPO. That’s a sadly narrow band and I believe the world is poorer for it.

Far better would it be if we could have more companies operate independently of the 5–7 year investment timelines of the funds. Bezos has now owned that small slice of Basecamp for almost a decade, and he’s been paid back in full and then some through profits. So it worked out for him. And it’s working out great for Jason and I, as well as the employees and customers of Basecamp who are still here some 12 years later.

Q: What about the entrepreneurs (perhaps folks in NYC or Silicon Valley) who can’t escape unicorn culture, no matter where they turn?

It’s very hard to ignore of the drums of the unicorn if you’re standing right next to them. Physical separation can be a healthy membrane to put things in perspective. So if you’re a founder and think you might not want to play Who Wants A Shitty Chance of Making VCs Even Richer, then I suggest you get the hell out of San Francisco and surrounding areas. Tune out that echo chamber both physically and mentally. Stop spending so much time reading startup lore and literature.

Instead, go back to the fundamentals. Study the basics of business and focus on your own work. You don’t have to become a hermit to do this, but some isolation can do you very good. I think that 37signals starting in Chicago and me working from Copenhagen gave us all a very different perspective than the prevalent money train of the Bay Area. One that I’m not sure would have stuck if we too had been trapped there.

There are lots of other materials to read to give you the strength to carry on. Jason and I wrote a number of books on these topics — Getting Real, REWORK, REMOTE, and I recently published a presentation called RECONSIDER. Those all give a very different perspective, but just as importantly, they give kinship to people who already thought like that but feared they were all alone in doing so. You’re not alone. There are many just like you, but most of them just don’t have or desire the megaphones of San Francisco.

Q: Now that you have the power of hindsight, what would you have changed?

I don’t believe in hindsight. If I knew what I know now, I might very well never have started Basecamp. I probably wouldn’t have gotten involved with Ruby on Rails. If someone had said, hey, this is going to take a decade or more from the best years of your life, what about it? Then I could totally have seen turning it all down! Ignorance is sometimes bliss and a beginner’s naivety is sometimes just the catalyst you need for change.

When you know too much, you know all the reasons why it’s not going to work. All those reasons will zap your zest and confine you to the comfortable. Besides, part of the fun of doing this for the first time is the novelty at every stage. I think that’s why many serial entrepreneurs don’t have nearly as much fun the second and the third time at the rodeo. They already went through this. Scrapping with just a couple of people is what you do when you have to, but once you know it all and have it all, it’s unlikely to start like that again. You’ll feel compelled to preempt problems that you might, possibly have in the future based on your experience. Which just adds weight and volume to the endeavor that it doesn’t need at that stage.

That’s part of why I’ve committed myself to sticking with it. To go the distance with Basecamp. That this is my life’s work and it could very well be the work for the rest of my life. I don’t need to go back to square one and try again, because I think in many important ways, I’d do a worse job at it than my ignorant 20-something self.

Q: Any other words of advice that you’d like to share with fellow first-time founders (and bootstrappers, especially)?

My best advice to someone trying to start a new business has been codified in the books and presentations I’ve given, but I will say a few things on motivations of growth. Most small businesses or people just starting out are saddled with lots of self-doubt and inadequacy issues. Oh, I’m just a small company. I’m just a few people. We just do work in this little niche. Stop that. Don’t apologize for being small. Small is wonderful, small is beautiful.

We made Basecamp with four people. I wrote the initial version of Ruby on Rails alone. Jason and I have been blogging on Signal v. Noise for more than a decade with lots of impact, without having some big backer.

Embrace the beginning. Love the beginning. You wouldn’t believe the number of big companies and people working there who’d love to trade their power for your nimbleness. Have confidence in what you do and why you do it. Then, even if things stay small forever, you can still feel great about it. I would be just as happy if Basecamp had not grown beyond what 10 people could have comfortably managed.

---

In addition to being a small business, Basecamp is all about helping other small businesses regain control as the first steps of success happens. Maybe you hired a few more people, maybe you took on a new really important client. Whatever it is, your old system isn’t cutting it any more. That’s when it’s time for Basecamp.

Few management techniques have fallen further from grace than the yearly or bi-yearly employee reviews. The new way is just-in-time feedback. Don’t hold anything back, let it all out, and the sooner the better. The more transparency, the greater frequency, the better!

So drip, drip, drip comes the feedback. Every interaction, every project, every presentation a test to be judged and graded. Did I do well? Does hearing nothing this time when I heard something last time mean it was better or worse?

I’m not sure the new way is better. In fact, I’m pretty sure it’s not. Maybe transparency, honesty, and feedback aren’t all just dials that make the music better if they’re all turned up to 11 at the same time.

Perhaps not every reservation needs to be aired, perhaps not every doubt needs to be discussed. Yes, it will be a longer loop, but one that’s also likely to sift out the one-off bad days, the infrequent misunderstandings, the few missed opportunities. Leftover, the lingering concerns that have shown themselves serious enough to persist as a trend.

We’re all noisy data points. Very few individual incidents matter so much that they single-handedly alter the trajectory of the trend. That’s not a bug, but a feature.