Below you'll find a collection of general principles we try to keep in mind at Basecamp when communicating with teammates, within departments, across the company, and with the public. They aren't requirements, but they serve to create boundaries and shared practices to draw upon when we do the one thing that affects everything else we do: communicate.
This section includes specific examples of how we apply our philosophy day-to-day across the company. Since communication often interrupts, valuing each other's time and attention is a critical considersation. Keeping people in the loop is important, but asking them to follow along with everything is a distraction. That's why we follow reliable, predictable methods to share the right kind of information at the right time in the right place.
98% of our internal communication happens inside Basecamp. That means all company-wide discussions, all social chatter, all project-related work, all sharing of ideas, all internal debates, all policy updates, and all official decisions and announcements all happen in Basecamp. A single centralized tool keeps everything together and creates a single source of truth for everyone across the company. We don’t use email internally (we do externally), we don’t use separate chat tools like Slack or Teams, and we rarely have in-person meetings. We do use Zoom or Skype for the occasional video conference between two or three people. And we occasionally discuss a pull request in Github.
Every workday at 16:30, Basecamp (the product) automatically asks every employee âWhat did you work on today?â Whatever people write up is shared with everyone in the company. Everyoneâs responses are displayed on a single page, grouped by date, so anyone whoâs curious about whatâs happening across the company can simply read from top to bottom. And if you have a question about anything, you can comment on anyoneâs âwhat did you work on today?â check-in to keep the conversation in context.
This routine is about loose accountability and strong reflection. Writing up what you did every day is a great way to think back about what you accomplished and how you spent your time.
Some people just jot down a few bullets. Others write multi-paragraph stories to share - and document - the thinking behind their work. There are no requirements here. We just ask everyone to write in their own style.
Every Monday morning, Basecamp automatically asks everyone âWhat will you be working on this week?â This is a chance for everyone to lay out the big picture of their week. Itâs not about regurgitating individual tasks, or diving headlong into the minutia of the week. Itâs generally just your 10,000 foot view of the week ahead. The big picture items, the general themes. It sets your mind up for the work ahead, and, collectively, it gives everyone a good sense of what happening across the company this week.
Every few weeks, or once a month, Basecamp will automatically ask everyone a social-style question. âWhat books are you reading?â Or âTry anything new lately?â Or âAnything inspire you lately?â Or âSeen any great design recently?â Or âWhat did you do this weekend?â These entirely options questions are meant to shake loose some stuff that youâd love to share with everyone else, but you hadnât had an opportunity to do so. This kind of internal communication helps grease the social gears. This is especially useful for remote teams, like ours. When we know each other a little better, we work a little better together.
Heartbeats summarize the last ~6-weeks of work for a given team, department, or individual (if that person is a department of one). They’re written by the lead of the group, and they’re meant for everyone in the company to read. They summarize the big picture accomplishments, they detail the little things that mattered, and they generally highlight the importance of the work. They’ll also shine a light on challenges and difficulties along the way. They’re a good reminder that it’s not all sunshine all the time. On balance, Heartbeats are wonderful to write, fun to read, and they help everyone - including those not directly involved with the work - reflect on jobs well done and progress well made.
Kickoffs are essentially the opposites of Heartbeats. Rather than reflect, they project. They’re all about what the team plans on taking on over the next 6 weeks. Projects, initiatives, revamps, whatever it might be, if it’s on the slate, it gets summarized in the Kickoff. While Kickoffs detail specific work for a specific group, they’re also meant for full-company consumption. Like Heartbeats, they’re written by the team lead. Kickoffs are broad in scope, so they don’t cover all the details in the work ahead - the teams doing the work are the ones that wade into those weeds. We don’t want to overwhelm everyone with details that don’t matter. If anyone’s curious about something included in a Kickoff, they’re free to post a comment and ask a question.
Occasionally we update an internal policy. Something about vacation time, or a new benefit, or reiterating that 40 hour weeks means 40 hour weeks. When we have something to announce company-wide, we don’t send an email. Email is decentralized and there’s no permanent record in a permanent place everyone can see. Instead, we post it either to the Basecamp HQ message board or as a comment on an existing policy document stored in Basecamp. This means everyone sees the same thing, everyone hears the same thing, and everyone knows the same thing - including future employees who are yet to join Basecamp. We now have a shared truth.
Efective communication requires context. Saying the right thing in the wrong place, or without proper detail, leads to double work and messages being missed. That’s why we spin up a separate Basecamp project for every project we work on. Everything related to that project is communicated inside that project. All the tasks, all the discussions, all the documents, all the debates, and all the decisions happen inside those walls. Everyone who needs access, has access. Every Basecamp project is a capsule of everything someone needs to know about that work project.
Further, we take spacial context seriously. If we're discussing a specific task, we discuss it in the comment section below the task itself. If we're talking about a specific document, we discuss it in the comments attached to the document. Communications stay attached to the thing we're discussing. This provides the full story in one reliable place. The alternative is terrible - communication detached from the original source material, discussions all over the place, fragmented conversations missing entire chunks of time and detail, etc. Basecamp's "everything is commentable" feature is what makes this possible for us.
We've detailed the pros and cons of chat vs. long form writing in our infamous "Group Chat: Group Stress" guide. We definitely recommend checking it out.
You'll also find a detailed explanation of how our teams work day-to-day on software projects in "Shape Up: Stop Running in Circles and Ship Work that Matters".
The Basecamp Company Handbook is also worth checking out. It explaines how we're structured, how we define titles and roles, our full benefits package, our company values, the responsibilities of individual contributors, managers, and executives, and other essential bits.
We hope this guide was useful, but we’re sure we’re missing something. What questions do you still have? What did you hope to learn that you didn’t? Was anything more confusing than clarifying? What would have made this guide more helpful? It’s a work in progress, and we’ll update as necessary based on your feedback. Please send questions, suggestions, and thoughts directly to the author, Jason Fried, at email@example.com. Thanks!