본문으로 건너뛰기

Communication Norms

Practical guidelines for effective asynchronous and synchronous communication in a distributed, high-trust environment.

개요​

Communication norms determine whether a distributed team functions smoothly or devolves into chaos. Bad communication creates bottlenecks, duplicated effort, and frustration. Good communication enables asynchronous work, reduces meeting overhead, and builds trust.

Kyndof's communication norms prioritize clarity, transparency, and respect for people's time. We default to asynchronous communication, use synchronous sparingly, and document everything that matters. These aren't rigid rules—they're guidelines that adapt to context.

This guide applies to all team members, regardless of role or location.

Default to Asynchronous​

Asynchronous communication is the foundation of effective distributed work:

Why Async First: Synchronous communication (meetings, instant messaging) demands immediate attention and interrupts deep work. Asynchronous communication (email, documentation, recorded videos) allows people to respond when convenient, respecting different time zones and work styles.

When to Use Async:

  • Sharing updates, decisions, or context
  • Requesting non-urgent input or feedback
  • Documenting processes, decisions, or knowledge
  • Asking questions that don't need immediate answers
  • Broadcasting information to multiple people

How to Do Async Well:

  • Write clearly: Assume the reader has no context. Provide background, state the ask explicitly, and include relevant links.
  • Front-load key information: Put the most important point in the first sentence. People skim—make sure they get the core message even if they don't read everything.
  • Set expectations: If you need a response, state the deadline. "Need feedback by EOD Friday" is clearer than "let me know what you think."
  • Use threads: In Slack or Notion comments, reply in threads to keep conversations organized. Flat message streams become unreadable quickly.
  • Record instead of writing: For complex explanations, record a short Loom video instead of writing a novel. Seeing your screen and hearing your voice often conveys nuance better than text.

Response Time Expectations:

  • Urgent (same-day response needed): Use Slack with @mention
  • Important (1-2 day response): Use Slack or email
  • Standard (3-5 day response): Use email or Notion comments
  • No deadline: Document in Notion or wiki

When to Go Synchronous​

Synchronous communication is expensive—use it selectively:

When Sync is Better:

  • High-bandwidth brainstorming or problem-solving
  • Sensitive or emotionally charged conversations
  • Complex discussions with lots of back-and-forth
  • Building rapport and team cohesion
  • Real-time decision-making under time pressure

When Sync is Worse:

  • Broadcasting information (send an email instead)
  • Simple status updates (post in Slack instead)
  • Decisions that need documentation (start async, sync for clarification)
  • Anything that could be handled in 3 async messages or less

Meeting Best Practices (see Meeting Guidelines for full detail):

  • Every meeting has a clear purpose and agenda shared in advance
  • Invite only people who need to be there (required vs. optional)
  • Start and end on time—respect people's calendars
  • Document outcomes and decisions (meeting notes in Notion)
  • Record meetings for people in different time zones

Slack Etiquette​

Slack is our primary synchronous/near-synchronous tool:

Channel vs. DM:

  • Use channels for work-related conversations (creates transparency and searchable history)
  • Use DMs for truly private or sensitive discussions
  • When in doubt, use a channel—DMs create information silos

@Mentions:

  • @channel or @here: Use sparingly (emergencies or time-sensitive announcements only). Notifies everyone.
  • @person: Use when you need a specific person's attention. Don't abuse it—not everything needs immediate attention.
  • No @mention: Use when sharing information but not requiring immediate action. People will respond when they check Slack.

Threading:

  • Always reply in thread for follow-up conversation
  • Don't start new top-level messages for ongoing discussions—it fragments context
  • Use threads to keep channels scannable

Status and Availability:

  • Set your Slack status to reflect availability (in a meeting, focusing, out of office)
  • Use "Do Not Disturb" when you need uninterrupted focus time
  • Don't expect instant responses—async is the default even in Slack

Emoji Reactions:

  • Use emoji reactions for quick acknowledgment (👍 = seen and agreed, ✅ = done, 👀 = reviewing)
  • Reactions reduce message volume—don't reply "OK" when 👍 suffices

Channel Naming and Organization:

  • #team-*: Team-specific channels (e.g., #team-engineering, #team-marketing)
  • #proj-*: Project-specific channels (archive when project completes)
  • #fun-*: Social and non-work channels (e.g., #fun-random, #fun-coffee)
  • Keep channels focused—too many channels fragment conversation

Off-Hours Messages:

  • You can send messages anytime, but don't expect immediate responses outside work hours
  • Use scheduled send if you're working late but don't want to disturb people
  • If someone messages you off-hours, respond when you're next working—no obligation to reply immediately

Email Guidelines​

Email is for external communication and formal internal communication:

When to Use Email:

  • Communicating with external partners, customers, vendors
  • Formal requests, approvals, or documentation
  • Sharing information with large groups who don't use Slack
  • Legal, HR, or compliance-related communication

When Not to Use Email:

  • Quick internal questions (use Slack)
  • Real-time collaboration (use Slack or meetings)
  • Project updates (use Notion)

Email Best Practices:

  • Subject lines: Specific and actionable (e.g., "Feedback needed by Friday: Q4 roadmap proposal")
  • Top-posting: Put new content at the top, trim quoted text below
  • CC/BCC: Use CC when people need visibility; use BCC for mass emails where recipients shouldn't see each other
  • Attachments: Prefer links to cloud documents over attachments (easier to update, avoids version confusion)
  • Response time: Aim to respond within 24 hours during work week, even if it's "I'll get back to you by [date]"

Documentation​

Documentation is asynchronous communication across time:

What to Document:

  • Decisions and rationale (Architecture Decision Records, decision log)
  • Processes and workflows (SOPs in wiki)
  • Project context and status (Notion project pages)
  • Meeting outcomes (meeting notes)
  • Customer insights and feedback (customer database, knowledge graph)

Where to Document:

  • Wiki: Evergreen processes, policies, reference material
  • Notion: Project-specific context, task tracking, working documents
  • GitHub: Code, technical specs, ADRs, issue discussions
  • Knowledge Graph: Entity relationships, interaction history, decision links

Documentation Standards:

  • Findability: Use clear titles, tags, and structure. If people can't find it, it doesn't exist.
  • Freshness: Mark when documents were last updated. Archive outdated docs—don't let them mislead.
  • Completeness: Assume the reader has zero context. Link to background material.
  • Conciseness: Respect readers' time. One page is better than five if it conveys the same information.

Giving and Receiving Feedback​

Effective feedback is a communication skill:

Giving Feedback:

  • Specificity: Describe the behavior, not the person. "In the meeting, you interrupted three times" vs. "You're interrupting."
  • Timeliness: Give feedback soon after the behavior (within days, not weeks).
  • Actionability: Suggest what to do differently. "Next time, let people finish their sentences before responding."
  • Balance: Acknowledge what's working before addressing what needs improvement.
  • Private for criticism, public for praise: Critical feedback is one-on-one; recognition can be public.

Receiving Feedback:

  • Listen first: Don't interrupt or defend immediately. Ask clarifying questions.
  • Assume good intent: Most feedback is well-intended, even if poorly delivered.
  • Reflect before responding: You don't have to agree or disagree on the spot. "Thanks, I'll think about that" is fine.
  • Act on patterns: One person's feedback might be noise; multiple people saying the same thing is signal.

Transparency and Information Sharing​

Default to transparency:

Public by Default:

  • Share updates, decisions, and context in channels, not DMs
  • Document decisions in shared spaces (Notion, wiki, GitHub)
  • Avoid "hallway conversations" that exclude remote teammates—bring discussions to public channels

When Privacy is Appropriate:

  • HR and personnel issues
  • Salary and compensation discussions
  • Sensitive customer or partner negotiations
  • Pre-decision strategy discussions (to avoid premature speculation)

Over-Communication:

  • When in doubt, share more context rather than less
  • Repeat important information across channels (Slack, email, Notion)—people miss things
  • Summarize long threads or meetings for people who weren't present

Cross-Cultural Communication​

Kyndof operates internationally—communication norms vary:

Direct vs. Indirect Cultures:

  • Some cultures value directness (US, Germany, Netherlands); others value indirectness and face-saving (Korea, Japan, many Asian cultures)
  • Adjust your style: Be explicit about whether feedback is critical or just suggestion
  • When receiving indirect feedback, read between the lines—"it might be worth considering" can mean "this is wrong"

Time Zones:

  • Schedule meetings at reasonable times for all participants (rotate burdens if needed)
  • Record meetings for people who can't attend live
  • Don't expect instant responses from people 8+ hours away

Language:

  • Use simple, clear language—avoid idioms, slang, or culture-specific references
  • Be patient with non-native speakers—clarity over speed
  • Offer to switch to written communication if verbal is difficult

Communication Anti-Patterns​

Avoid these common mistakes:

Drive-By Questions: Asking "quick question" without context forces the recipient to do triage work. Instead, provide context: "I'm trying to deploy feature X and getting error Y. Here's what I've tried…"

Zombie Threads: Reviving dead Slack threads weeks later. Start a new thread or message if it's been more than a few days.

Information Hoarding: Keeping knowledge in your head or private notes. If it's useful to you, document it for others.

Vague Asks: "Thoughts on this?" is lazy. Be specific: "Do you see any security risks in this approach?" or "Would this solution scale to 1M users?"

All-Hands Meetings for Updates: If it's purely informational, send an email or post in Slack. Meetings are for discussion, not broadcasting.

Unstructured Brain Dumps: Sharing a wall of text without structure forces readers to parse it. Use headings, bullets, summaries.

No Follow-Through: Asking for input and then disappearing. Close the loop—share what decision was made and why.

Escalation and Urgency​

Know when and how to escalate:

Urgency Levels:

  • Critical (immediate): Outages, security breaches, legal crises. Use phone call or Slack with @channel.
  • Urgent (same-day): Customer escalations, time-sensitive decisions. Use Slack with @mention.
  • Important (1-3 days): Priority work, decisions with deadlines. Use Slack or email.
  • Normal (1 week): Standard work, FYI updates. Use async channels.

Escalation Path:

  1. Try to resolve at peer level first
  2. If blocked, escalate to your manager
  3. Manager escalates to their manager if needed
  4. CTO/CEO for company-wide critical issues

Don't Cry Wolf: If you mark everything urgent, nothing is urgent. Preserve urgency for actual emergencies.

Remote Work Communication​

Remote work requires intentionality:

Presence Indicators:

  • Set working hours in your calendar
  • Update Slack status when away (meeting, lunch, focus time)
  • Use video in meetings when possible (builds rapport)

Timezone Coordination:

  • Use UTC or specific timezone references ("2pm EST") to avoid confusion
  • Tools like World Time Buddy help visualize overlaps
  • Schedule recurring meetings at times that rotate fairness

Informal Communication:

  • Create space for non-work chat (#fun-random, virtual coffee chats)
  • Remote work loses hallway conversations—compensate with intentional social time
  • Celebrate wins publicly (shout-outs in Slack, recognition in all-hands)

Tool Selection​

Right tool for the right job:

ToolUse ForDon't Use For
SlackQuick questions, real-time collaboration, announcementsLong-term documentation, complex discussions
EmailExternal communication, formal requestsInternal quick questions, real-time collaboration
NotionProject tracking, working docs, knowledge baseCode, version-controlled docs
GitHubCode, technical specs, issue trackingNon-technical docs, project management
WikiPolicies, processes, evergreen referenceTemporary or rapidly changing info
LoomAsync video explanations, demosReal-time discussion, permanent documentation
ZoomMeetings, interviews, workshopsUpdates that could be async

Why These Norms Exist​

Communication norms prevent chaos. Without them, teams develop conflicting expectations: Some people expect instant Slack responses; others treat it as async. Some document everything; others keep knowledge in their heads. These mismatches create friction.

Good norms align expectations. Everyone knows that Slack isn't email (faster but not instant), that meetings need agendas, that decisions get documented. This reduces cognitive load—people don't have to guess how to communicate.

These norms also respect people's time and work styles. Async-first communication lets people batch communication and protect deep work time. Clear escalation paths prevent people from being bothered unnecessarily. Documentation reduces repetitive explanations.

But norms only work if they're practiced. Managers set the tone by modeling good communication: writing clear updates, responding promptly, documenting decisions. If leadership treats Slack as email or holds meetings without agendas, teams will too.

Communication is a skill, not a personality trait. You can learn to write clearer updates, give better feedback, and choose the right channel. Treat these norms as a starting point and refine them based on what works for your team.

관련 문서​