We recently deleted over three million accounts across all our apps. This was the answer to a question we asked ourselves last year: what should we do about accounts that weren’t cancelled, but weren’t used either? Should we keep hold of their data forever? That felt wrong – we promise to delete data when you cancel your account. Keeping so much data around felt like we weren’t living up to that promise, and felt like a liability, so we decided to do something about it.

We’ve been teaching people how to do remote work well for the better part of two decades. We wrote a whole book about the topic in 2013, called REMOTE: Office Not Required. Basecamp has been a remote company since day one, and our software is sold as an all-in-one toolkit for remote work. Yeah, we’re big on remote work! So now that COVID-19 has forced a lot of companies to move to remote work, it’s doubly important that we do our part to help those new to the practice settle in.

There’s no perfect process for hiring great programmers, but there are plenty of terrible ways to screw it up. We’ve rejected the industry stables of grilling candidates in front of a whiteboard or needling them with brain teasers since the start at Basecamp. But you’re not getting around showing real code when applying for a job here. In the early days of the company, we hired programmers almost exclusively from the open source community.

Basecamp’s newest product HEY has lived on Kubernetes since development first began. While our applications are majestic monoliths, a product like HEY has numerous supporting services that run along-side the main app like our mail pipeline (Postfix and friends), Resque (and Resque Scheduler), and nginx, making Kubernetes a great orchestration option for us.

The vast majority of web applications should start life as a Majestic Monolith: A single codebase that does everything the application needs to do. This is in contrast to a constellation of services, whether micro or macro, that tries to carve up the application into little islands each doing a piece of the overall work. And the vast majority of web applications will continue to be served well by The Majestic Monolith for their entire lifespan.

For many, moving from everyone’s-working-from-the-office to everyone’s-working-at-home isn’t so much a transition as it is a scramble. A very how the fuck? moment. That’s natural. And people need time to figure it out. So if you’re in a leadership position, bake in time. You can’t expect people to hit the ground running when everything’s different. Yes, the scheduled show must go on, but for now it’s live TV and it’s running long.

Since the beginning, Basecamp has been marketed as a project management and collaboration tool for small businesses (or small teams inside larger businesses). However, over the years we’ve also heard from thousands of people who use Basecamp outside of work. They’ve gone off-label and turned to Basecamp to help them manage all sorts of personal projects too. No surprise there – it really works!

Here’s a common question that’s coming up about Shape Up, our new book on product development: People in my book club love all the principles, but they had one question: How did they build Basecamp 3 doing this? It seems like all the practices are for adding features to an existing product. There’s a new appendix in the book now to answer this question: How to Begin to Shape Up: New versus existing products.

I’ll be shocked if you’re shocked: Building social connection in a remote team is the hardest part of managing a remote team. According to a survey we ran this past fall with 297 remote managers and employees, “fostering a sense of connection without a shared location” was seen as the #1 most difficult part of being a remote manager – and the #1 most difficult part of working remotely, in general.

The #1 piece of information you should be focused on as a leader is sharing company vision. Here’s exactly how to do it.