davidbgk
/
larlet-fr-david-cache

<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Guide to Internal Communication, the Basecamp Way (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-04-25.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://basecamp.com/guides/how-we-communicate">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>Guide to Internal Communication, the Basecamp Way</h1>
<h2><a href="https://basecamp.com/guides/how-we-communicate">Source originale du contenu</a></h2>
<h2>Rules of thumb, and general philosophy</h2>

<p>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.</p>

<ol class="stacked-list">
    <li>You can not not communicate. Not discussing the elephant in the room is communicating. Few things are as important to study, practice, and perfect as clear communication.</li>
    <li>Real-time sometimes, asynchronous most of the time.</li>
    <li>Internal communication based on long-form writing, rather than a verbal tradition of meetings, speaking, and chatting, leads to a welcomed reduction in meetings, video conferences, calls, or other real-time opportunities to interrupt and be interrupted.</li>
    <li>Give meaningful discussions a meaningful amount of time to develop and unfold. Rushing to judgement, or demanding immediate responses, only serves to increase the odds of poor decision making.</li>
    <li>Meetings are the last resort, not the first option.</li>
    <li>Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it's important, critical, or fundamental, write it up, don't chat it down.</li>
    <li>Speaking only helps whoâs in the room, writing helps everyone. This includes people who's couldn't make it, or future employees who join years from now.</li>
    <li>If your words can be perceived in different ways, they'll be understood in the way which does the most harm.</li>
    <li>Never expect or require someone to get back to you immediately unless itâs a true emergency. The expectation of immediate response is toxic.</li>
    <li>If you have to repeat yourself, you werenât clear enough the first time. However, if you're talking about something brand new, you may have to repeat yourself for years before you're heard. Pick your repeats wisely.</li>
    <li>Poor communication creates more work.</li>
    <li>Companies don't have communication problems, they have miscommunication problems. The smaller the company, group, or team, the fewer opportunities for miscommunication.</li>
    <li>Five people in a room for an hour isn't a one hour meeting, it's a five hour meeting. Be mindful of the tradeoffs.</li>
    <li>Be proactive about "wait, what?" questions by providing factual context and spacial context. Factual are the things people also need to know. Spacial is where the communication happens (for example, if it's about a specific to-do, discuss it right under the to-do, not somewhere else).</li>
    <li>Communication shouldn't require schedule synchronization. Calendars have nothing to do with communication. Writing, rather than speaking or meeting, is independent of schedule and far more direct.</li>
    <li>"Now" is often the wrong time to say what just popped into your head. It's better to let it filter it through the sieve of time. What's left is the part worth saying.</li>
    <li>Ask yourself if others will feel compelled to rush their response if you rush your approach.</li>
    <li>The end of the day has a way of convincing you what youâve done is good, but the next morning has a way of telling the you truth. If you aren't sure, sleep on it before saying it.</li>
    <li>If you want an answer, you have to ask a question. People typically have a lot to say, but they'll volunteer little. Automatic questions on a regular schedule help people practice sharing, writing, and communicating.</li>
    <li>Occasionally pick random words, sentences, or paragraphs and hit delete. Did it matter?</li>
    <li>Urgency is overrated, ASAP is poison.</li>
    <li>If something's going to be difficult to hear or share, invite questions at the end. Ending without the invitation will lead to public silence but private conjecture. This is where rumors breed.</li>
    <li>Where you put something, and what you call it, matters. When titling something, lead with the most important information. Keep in mind that many technical systems truncate long text or titles.</li>
    <li>Write at the right time. Sharing something at 5pm may keep someone at work longer. You may have some spare time on a Sunday afternoon to write something, but putting it out there on Sunday may pull people back into work on the weekends. Early Monday morning communication may be buried by other things. There may not be a perfect time, but there's certainly a wrong time. Keep that in mind when you hit send.</li>
    <li>Great news delivered on the heels of bad news makes both bits worse. The bad news feels like it's being buried, the good news feels like it's being injected to change the mood. Be honest with each by giving them adequate space.</li>
    <li>Time is on your side, rushing makes conversations worse.</li>
    <li>Communication is lossy, especially verbal communication. Every  hearsay hop adds static and chips at fidelity. Whenever possible, communicate directly with those you're addressing rather than passing the message through intermediaries.</li>
    <li>Ask if things are clear. Ask what you left out. Ask if there was anything someone was expecting that you didn't cover. Address the gaps before they widen with time.</li>
    <li>Consider where you put things. The right communication in the wrong place might as well not exist at all. When someone relies on search to find something itâs often because it wasnât where they expected something to be.</li>
    <li>Communication often interrupts, so good communication is often about saying the right thing at the right time in the right way with the fewest side effects.</li>
</ol>

<hr/>

<h2>Communicating day-to-day</h2>

<p>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.</p>

<h3>Basic toolset</h3>

<p>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.</p>

<h3>Automatic daily: "What did you work on today?</h3>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h3>Automatic weekly: "What will you be working on this week?"</h3>

<p>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.</p>

<h3>Automatic occasionally: "Social questions"</h3>

<p>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.</p>

<h3>← Reflect every 6 weeks: Heartbeats</h3>

<p>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.</p>

<h3>→ Project every 6 weeks: Kickoffs</h3>

<p>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.</p>

<h3>Whenever relevant: Announcements</h3>

<p>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.</p>

<h3>Day-to-day project work: In context</h3>

<p>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.</p>

<p>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.</p>

<hr/>

<h2>Other resources</h2>

<p>We've detailed the pros and cons of chat vs. long form writing in our infamous "<a href="https://basecamp.com/guides/group-chat-problems">Group Chat: Group Stress</a>" guide. We definitely recommend checking it out.</p>

<p>You'll also find a detailed explanation of how our teams work day-to-day on software projects in "<a href="http://basecamp.com./shapeup">Shape Up: Stop Running in Circles and Ship Work that Matters</a>".</p>

<p>The <a href="https://basecamp.com/handbook">Basecamp Company Handbook</a> 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.</p>

<hr/>

<h3>Anything else?</h3>

<p>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 <a href="mailto:jason@basecamp.com">jason@basecamp.com</a>. Thanks!</p>
</article>


<hr>

<footer>
  <p>
    <a href="/david/" title="Aller à l’accueil">🏠</a> •
    <a href="/david/log/" title="Accès au flux RSS">🤖</a> •
    <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
    <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
    <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
  </p>
</footer>
<script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
</body>
</html>