The fastest replier on the team shipped the least
On one remote team I worked with, there was a backend developer everyone loved. Ask him anything and the answer arrived inside a minute. Naming conventions, a flaky test, where the staging credentials lived, what a field in the API meant. He reviewed pull requests from notifications, joined every side thread, and was usually the first green dot in the morning and the last one at night.
He was also, for three sprints in a row, the owner of a database migration that did not move. Every standup it was "nearly there". Nobody blamed him, because he was so obviously working. He was working all day. He was just working on everyone else's questions in ninety-second slices, and a migration does not survive being picked up and put down forty times a day.
When it finally shipped, it was in a week he had asked to be taken off the support rota and turned chat notifications off, half apologetically, "just to get this thing out". It took him four days. That was the week I stopped thinking of availability as a personal virtue.
That was the week I stopped thinking of availability as a personal virtue.
I've done a milder version of the same thing myself. On freelance weeks with two clients, I kept both chats open "so nobody waits", replied to everything within minutes, and closed the laptop with a lovely warm message history and a feature that was in exactly the state it had been in that morning. The day felt full. The finish list was empty.
What "available all day" actually trains
Nobody writes "be available all day" in a handbook. It arrives by accident. Fast replies get thanked. A slow reply gets a nudge. Urgent is never defined, so every message turns up with the same weight, and the safest strategy for each person is to watch the channel.
What usually happens is the team ends up optimising for latency. The number that gets noticed is how quickly you answered, because that is visible. The number that matters, how much finished work someone else could open and use, is invisible until the end of the sprint.
The cost is not spread evenly. The people who answer fastest are often the most helpful and the most senior, which means the team's deepest work is being cut into the smallest pieces. And the quiet person who closes chat to get something done looks, on the green-dot scoreboard, like the least engaged member of the team.
At home this gets worse, because there is no physical end to the day. In an office, leaving the building was the signal. Remotely, "available all day" quietly becomes "available until I go to sleep", and the evening laptop check turns into a habit nobody asked for.
Three tiers and one focus hold
The fix I've seen work is small enough to fit in a channel topic. Three response tiers, one calendar block, and leaders who behave as if both are real.
Tier 1, Now. Interrupting is allowed. Production down, a customer blocked with money on the line, data or security at risk. This uses the phone or a named page path, never a direct message, and the channel for it carries nothing else.
Tier 2, Today. Normal work questions. These get answered in reply windows, for most people one late in the morning and one in the middle of the afternoon, not within ninety seconds of arriving. Your status names the next window: "Next replies at 11:30."
Tier 3, When you surface. Updates, FYIs, reviews that block nothing. Same day or next day is fine, and the message can say so.
The focus hold. One block on the calendar, daily or on the days that matter, with the same social weight as a meeting. The status says "In focus until 11:30, Tier 1 only." The end time is mandatory. People will wait much more happily for something that has a finish line.
The written version is the easy part. If the team lead replies to every Tier 3 line within a minute, the policy is fiction, and new people copy what gets praised in their first month, not what the topic says.
Before and after, on the same Tuesday
Here is the same day twice, for a developer fixing tax calculation in checkout.
Always on. Chat stays open all morning. Over four hours they send fourteen quick replies, approve two low-risk pull requests from notifications, and contribute to a thread about naming. At 16:00 the tax logic is still wrong for one currency. The channel stayed warm all day. There is no pull request, and the ticket has no new reproduction steps.
With tiers. A focus hold from 09:00 to 11:30, Tier 1 only. Reply windows at 11:30 and 15:00. One review done properly in the afternoon window. The tax fix is pushed by late afternoon with notes for whoever tests it. Fewer minutes with a green dot. One finished thing.
Nothing about the second version is heroic. It is just a day where the long task got a long stretch.
Some roles do need fast replies, so staff for it
Support, on-call and operations people need to respond quickly, and pretending otherwise helps no one. The mistake is copying that norm onto every individual contributor without arranging cover.
A team of four cannot all be walk-up help desks and also ship a migration. Someone holds the channel for the morning while someone else holds a two-hour block, and they swap in the afternoon or on alternate days. Rotate it, so the responsive job does not always fall on the same agreeable person, who in my experience is usually the one with the most important work.
If your job is mostly messages, still protect short deep blocks for the parts that need them: writing documentation, a root-cause investigation, the one hard ticket. Defending those blocks when you work from home has its own problems, which I go through in protecting focus at home.
Three questions before breaking a focus block
Before you interrupt yourself or someone else, I run a quick check.
- Is production down, or is something client-visible broken? Then it is Tier 1, use the page path.
- Is someone blocked, with no written path forward and a deadline inside today? Then it is Tier 2, and it goes into the next window or the next overlap.
- Is it a preference, an FYI, or a "quick sync" that could be a ticket comment? Then it is Tier 3, and it waits.
If neither of the first two applies, it waits for the window. Teaching people this sort does more to reduce random direct messages than any amount of faster replying.
A common one: your status says focus until 14:00 and a manager sends "quick sync?" Reply once, offering a structured choice: "Written summary on the ticket by 14:15, or a call at 14:30?" Most people pick the summary. If the same person keeps breaking the hold, that is a conversation for the team norm, not something to absorb quietly every day.
Clients learn availability from what you do, not what you wrote
Retainers without stated windows teach clients that every hour of yours is available at urgent rates. Write the windows into the agreement, then repeat them in your status messages until the habit matches the paperwork. A reset can be as plain as: "Replies Monday to Friday, 09:00 to 17:00 CET. Outages go to the phone number in the contract." Hold that line for two weeks and most clients adjust without comment.
If a client keeps labelling Tier 3 things as urgent, name the switching cost when you next talk about scope, or narrow what the retainer covers. Unbounded availability is a discount you did not mean to offer.
Status lines that teach the tiers
Copy these and adjust the times:
- "Focus until 11:30 (Tier 1 only). Next replies 11:30 to 12:00."
- "Covering the channel this morning. Focus block this afternoon, 13:00 to 15:00."
- "Questions go on the ticket. Outages use the page path in the channel topic. I won't see DMs during focus."
After two weeks, count how many Tier 3 messages still arrived as direct messages during focus. The number should fall. If it does not, someone senior is still rewarding instant replies, and that is the thing to fix before anyone buys another focus app.
Pair the tiers with a shutdown routine so chat closes as part of finishing the day, not as an act of withdrawal, and replace presence with a short written status on a rhythm (async status people actually read). At the weekly check-in, ask what shipped that others could open without pinging anyone, not how quickly people answered (busy versus finishing).
The developer with the stuck migration was not the problem. The team had built a system where the most generous person paid the highest price, and called it collaboration. Being reachable at the right times, in the right way, is genuinely useful. Being reachable every minute is just slow output with good manners. Publish the tiers, put one block on the calendar with meeting weight, and treat two uninterrupted hours as the minimum the job needs, not a treat you earn after the inbox is empty.