For about a year on one remote team, I was the answer to "how does staging work?" I had set up the deploy scripts, so when anyone hit a weird error the advice in the channel was the same: just ping him. I said it myself, in onboarding calls, with what I thought was generosity. "Honestly, don't struggle with it. Just ping me."
It worked, in the sense that people got unstuck. I answered in direct messages, usually within a few minutes, and I liked being useful. I did not notice that I was answering the same four questions on rotation, or that my afternoons had turned into a help desk with no queue.
Then I took a week off. On the second day a colleague hit a staging deploy failure that I had explained in DMs at least three times to three different people. None of those explanations were anywhere the team could search. She lost most of a day and a half working it out from the scripts, and when I came back there was a polite message in my inbox that said, more or less, "we really need this written down".
She was right, and the slightly uncomfortable part was that I had been the obstacle while feeling like the solution.
She was right, and the slightly uncomfortable part was that I had been the obstacle while feeling like the solution.
What "just ping me" quietly does to a team
"Just ping me" makes the speaker the router for a whole category of questions. That has costs that do not show up while the router is online.
Knowledge stays private. Every answer lives in a one-to-one thread, so the seventh person to hit the problem has exactly as much to go on as the first.
Time zones punish the people who are not awake. If the router works European hours, someone in the Americas waits until their tomorrow for something that was answered last week. Fair reply expectations across zones are their own topic, covered in response expectations across time zones.
Loud beats important. Whoever pings gets served first. A quiet, important request in the right queue loses to a casual DM, every time.
The bus factor is one. Holiday, a busy launch week, or simply a day of focus, and the path closes.
Decisions vanish. A choice agreed in a direct message has no record, so it gets made again a month later, sometimes the other way round.
None of these look like problems from inside. The team appears responsive. Questions get answered. It is only when the router is away, or when you count repeat questions, that the cost becomes visible.
Helpfulness is a path you leave behind
The shift that fixed it for me was changing what I counted as helpful. Answering fast is helpful once. Leaving a path that answers the next person without me is helpful every time after.
A communication system, at its simplest, says three things for each kind of request: where it goes, who owns it, and when a reply is fair. That fits in a table you can put in the channel topic.
Need
Instead of a ping
Path
Owner
Fair reply window
Status
"Any update?" DM
Ticket comment or written status
Ticket owner
Next local workday unless blocking
Decision
Surprise huddle
Short options doc with an ask-by date
Named decision owner
By the ask-by date, in UTC
How-to
"Got a sec?"
Runbook or FAQ link
Doc maintainer
Doc first, office hours if still stuck
Blocker
Vague complaint in chat
Blocker update with the impact stated
Team lead, or on-call if production
Overlap hours, or the page path
Access
"Can you add me?"
Access ticket with manager approval
Access rotation
Two workdays, rush through on-call
The windows are rules of thumb, not a standard. Change them to fit your team. What matters is that each row has a name in the owner column and a time in the last one.
Then the leads have to model it. If the most senior person still answers unstructured DMs privately, the table is decoration, and everyone can see that it is.
The staging fix, before and after
Here is roughly what changed on that team after my week away.
Before. The channel culture was "ping him if staging looks weird". Around five people a week did. I answered in DMs. A sixth person still had nothing to go on. My afternoon focus blocks were the first thing to go, and the onboarding doc told new starters to ping me for access as well.
After. The channel topic linked to a runbook with one page per known failure. Access requests went into a ticket queue with a two-workday window. Anything that affected customers went to on-call through the page path. When someone messaged me directly anyway, my reply was the same each time: "Check the runbook section on failed migrations. If customers are affected, page on-call. Otherwise post the error in the ops channel with a screenshot and I'll look in the 14:00 UTC overlap."
And after any question I had not seen before, I spent a minute adding it to the runbook before replying. The next person got a link.
The number I watched was repeat staging questions per month, not how fast I replied. It dropped from about twenty to four or five within two months, and most of the remaining ones were genuinely new problems, which is what a human should be answering anyway.
Diagram
Diagram · 16:9a staging question moving from a private message to a runbook, a ticket, or on-call, shows a path the team can use when one person is away, boxes and arrows, 16:9, diagram
When the client goes around the project lead
The freelance version of "just ping me" is the client founder who messages the developer directly while a project manager owns the work.
I had one client like this. The founder would message me for status in the evening while the PM, Maya, owned the plan. Two versions of the truth drifted apart. I switched context in the middle of features to answer, and Maya found out about changes after they had been promised.
What fixed it was writing the channels into the statement of work: status on the ticket, production emergencies to the phone number in the contract, preferences and changes through the PM. Then I redirected once, politely, each time: "Logged on TICKET-88 and copied Maya, details are there." After about three weeks the messages moved where they belonged. My personal messaging app is not a support portal, and the founder did not actually want it to be one. He wanted an answer, and once the answer reliably appeared on the ticket, he stopped needing me to be the route to it.
A request that does not need an interview
A lot of pinging is really interviewing. "Got a sec?" is followed by three rounds of "what are you trying to do, where, what have you tried?" The receiver does unpaid coordination work before the actual help starts.
Ask people to post requests with four things: the goal, a link to the context, when they need it (in UTC), and what they have already tried. That turns most pings into something that can be answered in one go, or answered by someone other than the original router. The longer request format, with options and a default, is in async communication for distributed teams.
Office hours are a release valve, not a loophole
Some people genuinely think better out loud, and some problems are easier to show than to describe. Two short office-hours slots a week, where live help is welcome and expected, keep those people happy without making talk the default route for everything. Outside the slots, the written paths apply.
Pinging is still the right call sometimes. A novel incident, a sensitive personal issue, a hard problem where pairing will save hours. And occasionally someone is not stuck on information at all, they are stuck because they are anxious about it, and five minutes of live conversation is simply kind. The goal is that recurring work runs through the system, not that nobody ever speaks.
A month to retire the habit without a rebellion
Week one. Post the path table in the channel topic and the onboarding doc. Announce the office-hours slots.
Week two. Leads redirect every unstructured DM once, in public, with a link. No private exceptions for friends, including the friends who are leads.
Week three. Keep a shared list of repeat questions. Anything asked three times gets a doc section before Friday. Rotate who writes those sections the way you rotate on-call, so it does not land on one senior person.
Week four. Take "just ping me" out of bios and welcome messages. Replace it with something like "Start at the runbook. Office hours Tuesday and Thursday 14:00 UTC. Outages use the page path."
Expect grumbling around week two. People who liked being the hero can feel a bit demoted, and I did too. Praising doc fixes in standup the same way you praise features helps more than any argument.
The measure of success is fewer repeat questions and a shorter time to first contribution for the newest person on the team, not the fastest reply time in chat. If you have to pick one honest test, use mine: take a week off and see whether anyone loses a day and a half. If they would, you are still the system, and "just ping me" was a loan the team will repay with interest the moment you are not there.
End of this piece
Writer
PrimedEcho
Independent notes on remote work, focus, and freelance practice. About this site.