Overcommunicate by Default

The Cost Asymmetry

Every communication decision you make at work is a bet. When you post an update, you spend a little of everyone's attention. When you stay quiet, you save that attention — and gamble that nobody needed the information. The reason we overcommunicate at Hireboard is that this bet is wildly asymmetric.

The cost of one extra update is about 30 seconds of someone's reading time. If it turns out nobody needed it, they skim it, move on, and forget it. That is the entire downside.

The cost of one missing update looks very different:

• A teammate spends half a day building something you already built, because they didn't know you were on it.
• A wrong assumption goes uncorrected and compounds for days — someone designs around an API shape you abandoned on Tuesday.
• Your manager, with no signal from you, starts guessing. Guessing takes their time, produces worse conclusions than your 30-second update would have, and slowly erodes trust.
• A deadline slips silently, and the people depending on it find out on the day it was due — when every option for helping you has already expired.

Thirty seconds of reading time versus days of compounding damage. That is the trade. Nobody in the history of Hireboard has been in trouble for sending too many status updates. People have absolutely been in trouble for going dark.

Why "Especially When New"

The standard says especially when you're new, and that's deliberate. When you've worked with someone for a year, they have a mental model of you. If they don't hear from you for two days, they can fill in the blank: "She's heads down on the migration, that's normal for her." Their model does the communicating for you.

When you're new — new to the company, new to a team, or new to a kind of work — nobody has that model yet. Your updates are literally how the model gets built. Every "here's what I understood, here's my plan, here's where I am" teaches your manager and teammates how you think, how fast you move, and where you'll need support.

Silence from a new person doesn't read as "heads down." It forces one of two bad outcomes: either people assume the worst (stuck, lost, checked out), or they interrupt you to check — which costs both of you far more than the update would have. New people sometimes go quiet because they don't want to seem like they need hand-holding. It backfires every time. The quiet new hire is the one people worry about; the loud one is the one people trust.

The Five Moments That Always Get an Update

"Overcommunicate" is not a vibe, it's a checklist. There are five moments in the life of any task where an update is mandatory, not optional. Internalize these and you'll never have to wonder whether to post.

1. When You Start

Before you write a line of code or draft a single doc, say what you understood the task to be and how you plan to attack it. This is the cheapest possible moment to be corrected. A misunderstanding caught at kickoff costs a two-minute reply; the same misunderstanding caught at review costs the whole task.

2. The Moment You're Blocked

This is the one people get wrong most. The instinct is to grind: "I'll figure it out, I don't want to bother anyone." A day later you're still stuck, the task has silently slipped, and now you have to report both the blocker and the lost day.

Hireboard uses a struggle timebox: try to unblock yourself for 30 to 60 minutes. Real trying — read the docs, read the code, search Slack history, form a theory. Then post. The struggle matters because it means you arrive with context ("here's what I tried"), and the timebox matters because past the first hour, your odds of self-rescue drop while the cost of your silence climbs.

3. When You Change Approach

You planned to do X, you learned something, now you're doing Y. Post it. Anyone who read your kickoff message is now operating on stale information — reviewers expecting one shape of change, teammates building against your old plan. A pivot without an update silently converts your teammates' knowledge into misinformation.

4. The Moment You Know a Deadline Will Slip

Not the day it's due. Not when someone asks. The moment you know. A slip reported early is a planning input — people can reshuffle, descope, or send help. A slip reported on the due date is just bad news with zero options attached. The information is identical; the timing determines whether it's useful or merely upsetting.

5. When You Finish

"Done" is not an update; it's a rumor. A real completion update says what shipped, where it lives, and how anyone can verify it. This closes the loop for everyone watching the thread, creates a searchable record of the change, and hands QA and support what they need without a single follow-up question.

Public Channels, As Much As Possible

Where you communicate matters as much as whether you do. The second half of our standard: default to public channels, and treat DMs as the exception that needs a reason.

This isn't a preference; there's a stacked argument behind it:

• Searchability. Every answer given in a DM is knowledge that dies when the conversation scrolls away. Every answer given in a channel is documentation — the next person with the same question finds it in search and never has to ask. A DM answer helps one person once; a channel answer helps everyone, forever.
• Passive context. Teammates absorb an enormous amount from threads they merely skim. Nobody reads everything, but everyone reads something — and that ambient awareness of what's moving, what's broken, and what's decided is what makes a team feel coordinated without meetings.
• No silos, no politics. When information flows through DMs, who-knows-what becomes a function of who-talks-to-whom. That breeds silos at best and politics at worst. Public channels make information a shared resource instead of a currency.
• Onboarding. New Hireboard people read channel history to learn how things actually work — how decisions get made, how incidents get handled, what the team's standards look like in practice. Every public thread you write today is onboarding material for someone you haven't met yet.
• The bus factor. If context lives in your DMs, it's unavailable the day you're sick, on vacation, or gone. Public threads mean anyone can pick up a task cold by reading its history.

What Actually Belongs in DMs

The DM list is short: personal matters, sensitive feedback, compensation and HR topics, and genuinely one-to-one logistics ("running 5 late to our 1:1"). That's about it. Notice what's not on the list: technical questions, status updates, decisions, process questions, and anything about a project. Those are team information wearing a DM costume.

The litmus test: would anyone else ever benefit from seeing this answer? If yes — even hypothetically, even one future person — it goes in a channel.

The Redirect Move

You'll get work questions in DM anyway — it feels safer to ask privately, especially for people who are new. Don't lecture them; just redirect warmly. Answer the question in the relevant channel, then link it back to them. Done consistently, this retrains the whole team's defaults without a single awkward conversation.

Working Out Loud

The five moments cover a task's milestones. Working out loud is the connective tissue between them — the habit of narrating your work in progress so your team never has to wonder what you're doing.

In practice at Hireboard, working out loud looks like:

• A thread per task. Kick off with your starting-a-task message, then append progress to the same thread: findings, dead ends, small wins, the pivot, the ship. The thread becomes the task's living logbook — and its documentation when it's done.
• Start-of-day intent. A one-liner in your team channel: "Today I'm on the export task, aiming to get the S3 path working; interruptible after 2pm." Fifteen seconds to write, and it replaces every "what are you up to?" ping you'd otherwise get.
• Standup notes in the channel. Whether or not there's a standup meeting, the written version goes in the channel — yesterday, today, blockers. Written standups are skimmable, searchable, and timezone-proof.

This is not a Hireboard invention. The strongest distributed companies converged on written, public-by-default communication because it's the only thing that scales: GitLab famously runs all-remote on a public handbook and treats written, public communication as the default; Amazon builds decisions around written narratives instead of slide decks; Basecamp's remote playbook leans on written status over meetings. Different companies, same conclusion — when the team can't see each other, the work has to be visible in writing.

That's the real function of working out loud on a remote team: it replaces hallway visibility. In an office, people passively see that you're at your desk, wrestling with something, heads down before a deadline. Remote, none of that exists — your written narration is your visibility. No narration, no presence.

Overcommunication Is Not Noise

Here's the honest boundary, because every new hire eventually asks it: "if I post this much, aren't I just spamming everyone?" No — because overcommunication means high signal frequency, not high message volume. The goal is more information, delivered in an organized way. Four mechanics keep the signal high:

• Structure your updates. The skeleton is what / so-what / need-from-you: what happened, what it means, and what (if anything) you need from the reader. An update that ends with "nothing needed from you, just keeping you posted" takes five seconds to process. An unstructured brain-dump takes five minutes and a clarifying question.
• Threads, not channel floods. One top-level message per topic; every follow-up lives in its thread. Ten updates in a thread is overcommunication. Ten top-level messages about one task is noise.
• Batch the small stuff. Minor findings and micro-progress don't each need their own message. Collect them and post one solid update at a natural break. Blockers and slips are the exception — those are always real-time.
• @-mention surgically. An @-mention is a demand for someone's attention — spend it only when that specific person needs to act or know now. Most updates need zero mentions: the people who care are reading the thread already. Mention inflation is how teams learn to ignore mentions.

Put together: err on the side of more information, packaged so it's cheap to consume. Volume with structure is transparency. Volume without structure is noise. The fix for noise is never "share less" — it's "organize better."

Bad News Travels First Class

One final rule that sits on top of everything above: at Hireboard, the worse the news, the faster — and, within reason, the more publicly — it moves. Good news can wait for the weekly summary. A broken deploy, a slipped commitment, a mistake that touched customer data: those move now, to the channel where the right people will see them.

The instinct runs exactly backwards — bad news is the news we most want to sit on, soften, or fix quietly first. Resist it. Bad news is the news with the highest information value: it's the input people need to change plans, and its usefulness decays by the hour. "Within reason" just means judgment about the venue — a production incident goes straight to the incident channel; feedback about a specific person's mistake starts privately with them or your manager. Speed is non-negotiable; the venue takes judgment.

The No-Surprises Principle

Your manager should never learn about your slipped deadline, your broken prod deploy, or your at-risk project from someone else. Not from their manager, not from another team, not from a dashboard. Every time bad news reaches your manager before your report does, two things break: they're blindsided in whatever conversation surfaced it, and they learn your updates can't be trusted as the full picture. The first costs them credibility; the second costs you yours.

The test is simple: if something has gone wrong and you're wondering whether to mention it — the wondering is your answer. Mention it.

Report Problems Blamelessly

How you frame bad news determines whether people keep surfacing it. When reporting a problem — yours or anyone's — describe the event, the impact, the response, and the fix. Skip the blame, including self-blame. "I'm such an idiot, I broke prod" makes the report about your feelings; "the 2pm deploy broke signup for 20 minutes; rolled back; fix and a test to catch it coming today" makes it about the system. Blameless framing isn't about being gentle — it's what keeps the next person's bad news traveling first class instead of getting quietly buried.

Knowledge Check

Five scenarios. Pick what the Hireboard standard says you should do — not what feels most comfortable.