When “Communication Problems” Are Really Broken Escalation Rules

Imagine a fully distributed product team on a Tuesday morning. A customer issue is sitting in a support queue. The support lead posts it in chat, tags an engineer, and asks whether it is urgent. The engineer is in a planning meeting. A project manager sees the message, starts a second thread, and schedules a call for later. By the time someone decides who owns the next step, three people have spent an hour interpreting the word “urgent.”

That team does not mainly have a communication problem. It has a broken escalation rule.

Distributed teams often use “communication” as a catch-all diagnosis: people are not responsive enough, updates are too vague, meetings multiply, or someone feels excluded from decisions. Those symptoms can be real. But many start earlier, when the team has never agreed on what deserves interruption, who can make a call, and where the final decision must appear.

A working agreement should cover more than preferred channels and meeting hours. The working-agreements guidance from Atlassian explicitly includes communication channels, escalation paths, collaboration windows, and regular review. That is the useful frame: treat recurring friction as a workflow defect to inspect, rather than a personality flaw to debate.

Start with the symptom, not the team’s favorite explanation

“People need to communicate better” is too broad to repair. It bundles several different failures into one vague instruction. A team that responds slowly needs a different correction from a team that responds instantly in six places and still loses the decision.

Begin by collecting three recent incidents that created delay, duplicate effort, surprise, or unnecessary interruption. Do not choose the dramatic failure alone. The ordinary examples are often more revealing: a request that sat unanswered, a decision reopened in a meeting, an approval sought from three people, or a teammate who learned about a changed priority after beginning work.

If a recurring problem requires people to guess whom to interrupt, it is already an escalation-process problem.

This distinction matters because training people to write nicer messages will not solve missing authority. Nor will adding a new channel fix a team that cannot tell a production incident from a question that can wait until tomorrow.

Separate urgency from importance before messages start flying

Urgency is about the cost of waiting. Importance is about the consequence of the work. Teams confuse them when a senior stakeholder asks a question, a customer is unhappy, or a deadline feels emotionally close. Those situations may deserve care, but they do not automatically justify breaking someone’s focus or waking a colleague in another time zone.

Use a short escalation test. The person raising the issue should state: the observed problem, the decision or action needed, the deadline created by waiting, and the temporary owner. This turns “Can someone look at this?” into a request another person can assess.

There is no universal response-time target that will suit every distributed team. A support operation, a research group, and a design team face different costs of delay. The point is to write a shared test that matches the work, then let people use it without negotiating its meaning from scratch each time.

One reason asynchronous work can function across time zones is that the message carries enough context for the next person to continue. The Sourcegraph handbook’s guidance on asynchronous communication makes the same operational point: document what has been done, what remains unknown, and what a colleague needs to take the next move without waiting for more input.

An escalation should reduce uncertainty for the recipient, not transfer uncertainty to them.

Find the missing owner behind the slow decision

A long thread is sometimes a writing problem. More often, it is an ownership problem disguised as discussion. Several people contribute useful opinions, yet nobody knows whose role includes choosing among the options. The team keeps talking because it is trying to manufacture authority through consensus.

For each recurring decision type, define four parts: who prepares the recommendation, who decides, who must be consulted before the decision, and who needs to be informed afterward. These roles can be held by one person on small matters. The point is not ceremony. It is preventing a routine decision from becoming an accidental committee.

This is particularly important when a team has introduced new systems, reorganized, or added specialists. Process diagrams and tool permissions may suggest ownership, while day-to-day habits still point to the founder, manager, or longest-tenured employee. A decision workflow is only real when people can name the owner before an issue becomes tense.

Consulting the right people is useful; waiting for everyone to sound comfortable is a different process.

Do not mistake private caution for a channel preference

When people repeatedly send concerns by direct message, the channel may be convenient. It may also be evidence that the visible work thread feels unsafe for disagreement. The difference is important. Moving every sensitive conversation into public chat would be clumsy, but treating a pattern of private warnings as a simple preference leaves the underlying problem untouched.

Look at what happens after someone raises a concern. Are they asked for evidence? Is the concern recorded and answered? Does a manager become defensive, dismiss the issue as negativity, or quietly take the discussion offline? Teams learn their actual norms from these moments, not from a page of stated values.

Research on speaking up has repeatedly linked psychological safety with whether team members see voice as helpful. In one experimental study of status-diverse healthcare teams, people who felt safer were more likely to view a lower-status colleague’s alternative suggestion as a useful contribution to decision-making. The setting is not a distributed product team, but the warning transfers: hierarchy can shape whether disagreement is treated as input or as inconvenience. Read the study of psychological safety and perceived contribution for the limits and details of that finding.

The remedy is behavioral and visible. Decision owners should acknowledge the concern, state what evidence would change the call, and close the loop even when they decide against the suggestion. This does not mean every objection wins. It means people can see that raising a well-framed concern changes the quality of the decision record.

A team cannot claim that challenge is welcome if the only safe place to raise it is a private message.

Repair the record that lets old decisions return

Distributed teams do not need documentation for its own sake. They need a record that answers questions a person would otherwise send to a manager: What did we decide? Why? What assumption could reopen it? Who owns the next action? When will we revisit it?

Without that record, the same question returns under a slightly different name. A manager appears to be repeatedly changing direction, even if the earlier rationale was simply trapped in a meeting, a disappearing chat thread, or one person’s memory.

Keep the record close to the work rather than building a second archive nobody checks. A short decision note in the project space is usually enough. Link to supporting evidence; do not paste a transcript of the debate. Then put the outcome in the channel where affected people reasonably expect it. This is not redundant communication. It is a deliberate handoff between discussion, decision, and execution.

Explicit norms are especially useful in remote and distributed settings because informal cues are scarce. Atlassian’s team-norms guidance recommends making the team’s expectations visible, including norms about work hours, documentation, questions, and feedback. The useful standard is modest: a teammate who was offline should be able to find the current decision without reconstructing a conversation.

A decision is unfinished until the people affected can locate it and act on it.

Measure the coordination cost before adding another meeting

Before declaring that a team needs a daily sync, take a one-week sample of the work that triggered interruptions. Count only a few things: issues that lacked an owner, decisions reopened because the prior answer could not be found, and requests labelled urgent that could have waited. Do not turn this into surveillance. The purpose is to identify which defect is creating avoidable coordination work.

The chart below uses illustrative counts, not research data. It shows why one team might resist adding meetings: its bigger problem is not lack of talk, but unclear authority and lost decision records.

Where the coordination load is coming from

For a team with this pattern, write the ownership rule and decision-note location first. A new meeting may still be warranted for genuinely time-sensitive work, but it should not become the default repair for a documentation failure.

Test one escalation rule next week

Choose one recurring situation, such as customer-impacting defects, priority changes, or approvals that block a launch. For five working days, require every escalation to use a four-line format: impact, decision or action requested, decision owner, and deadline. Put it in one agreed location. The manager’s job is not to answer every request; it is to redirect incomplete escalations back to the format and make missing ownership visible.

At the end of the week, review five examples together. Which messages still created confusion? Did the rule miss a genuine urgent case? Did people know who could decide? If the answer is no, change the rule itself. If the answer is yes but people bypassed it, find out whether the path was too slow, too public, or simply unfamiliar.

Try the smallest rule that removes a repeated guess. If it reduces duplicate messages and lets people act without waiting for a manager, keep it. If it adds paperwork without making a decision clearer, remove it and test a narrower version.