Communication for Engineers

---

Master the skill that multiplies your impact.

Technical expertise alone doesn't distinguish exceptional engineers. In the daily work of engineering - collaborating with colleagues, navigating stakeholder relationships, reporting to leaders, and coordinating across teams - communication is the multiplier that determines impact.

This guide explores what exceptional communication looks like across different contexts, mediums, and relationships in engineering work.

---

What Does Exceptional Communication Look Like?

Exceptional engineering communication isn't about being the loudest voice or the most articulate speaker. It's about clarity, intentionality, and empathy - ensuring the right information reaches the right people at the right time in the right format.

The Hallmarks of Exceptional Communicators

1. They write for their audience, not themselves

The act of writing is fundamentally different from reading. When writing, you own the material - it's a thinking exercise. When reading, someone shifts context from whatever they were doing into parsing your document. Exceptional communicators recognize this asymmetry and optimize for the reader's experience.

As Sarah Drasner (VP of Developer Experience at Google) notes:

It can be tempting to assume that once you've written something down and someone has read it, the two of you have effectively communicated. In an ideal state, that would be true. However, in day-to-day life, this is not always what occurs.

2. They simplify without dumbing down

Technical terms, acronyms, and jargon create barriers. Even within teams, terminology may not be well-socialized. Exceptional communicators:

• Use metaphors and analogies to explain complex concepts
• Avoid team-specific jargon when communicating outward
• Never assume context that others might lack
• Bring all of their audience along, regardless of familiarity

3. They are concise and on point

• Avoid discussing caveats and edge-case exceptions irrelevant to the audience
• Keep messages short - they're more likely to be absorbed in their entirety
• Don't stray from the core point
• Eliminate filler words: "basically," "you know," "like," "kind of"
• Mentally check if it's the right audience, forum, and time before speaking

4. They listen as much as they speak

• Understand, reflect, and then respond to what's being said
• Observe verbal and non-verbal signals before responding
• When it comes to written communication, reading is equivalent to listening - read carefully and re-read until you've fully grasped the message
• Replace a straight "No" with a "Yes, but" when possible

5. They document decisions, not just outcomes

Future engineers (including future you) need to understand why a decision was made, not just what was built. Exceptional communicators create artifacts that serve people who weren't in the room.

---

Communication Across Different Relationships

With Colleagues (Peer-to-Peer)

Peer communication is the foundation of engineering work. It happens constantly - in code reviews, design discussions, chat threads, and pairing sessions.

What exceptional looks like:

• Code reviews as communication: Thoughtful code review is a gift to your team. Critique the work, not the person. "This approach might cause issues because..." not "You didn't think about..."
• Proactive knowledge sharing: That thing only you know? Write it down. Eliminate bus factors.
• Ask for help early: Struggling in silence slows the whole team. Asking for help after 30 minutes beats asking after 3 days.
• Healthy intra-team dynamics: Create an atmosphere of asking and answering questions politely.

Anti-patterns to avoid:

• Dominating discussions without giving space for others to contribute
• Assuming malice when confusion or different priorities are more likely
• Letting small disagreements fester into larger conflicts

With Stakeholders

Stakeholder communication requires translating technical reality into business impact. Your audience likely has different skillsets, priorities, and expectations.

What exceptional looks like:

• Convince, don't pitch: Executives and stakeholders will zero in on things you try to gloss over. Lead with facts and data, not flash and handwaving.
• Bespoke communication: The things that encourage buy-in from your COO might not work for your CMO. Cover appropriate breadth and give them the right stats.
• Respect their time: If they have to wade through dozens of dense pages to get your point, you'll lose them. Link to detailed data, but keep the core message clear.
• Influential storytelling: Structure compelling stories that lead to alignment, buy-in, and belief from stakeholders, partners, and teams.

The "Elephants and Goldfish" principle:

Think of executives as elephants (they never forget) and goldfish (can't remember three seconds) simultaneously:

• They'll remember everything you want them to forget
• They'll forget everything you want them to remember

This means:

• Repeat critical points even if you've said them six months in a row
• Always follow up on casual mentions that might have lodged worry in someone's mind
• Set foundations and context fresh each time

With Leaders and Bosses (Managing Up)

Managing up is making it easier for your manager to support you in doing great work. It's not about saying yes to everything or making your boss happy at all costs - it's about clarifying mutual expectations, giving and receiving feedback, and asking for help before you need it.

What exceptional looks like:

Understand their style first:

• Do they focus more on tasks and timelines, or people and relationships?
• Do they prefer concise updates or detailed reports?
• Do they decide quickly or take time?
• Do they prefer recommendations or options?
• Do they welcome open disagreement or avoid it?

Communicate with purpose:

• Treat your 30-45 minutes of weekly 1:1 time as strategic time
• Keep project status updates separate from 1:1s - use dashboards and shared docs
• Never let your manager be caught off guard
• Share how you think, not just what you do: "Just a heads-up. Working on problem X. Trying Y before committing to Z."

Proactive tactics:

• Augment their capacity: "What's a big burden on you right now, and how can I help?"
• Help them make better decisions: Present choices, pros and cons, outline trade-offs
• Bring a problem-solving mindset: Raise issues early, bring options
• Advocate for them: Find sincere, quiet ways to acknowledge their wins

When your manager makes it hard:

If they're consistently unavailable:

• Create a small list of important updates and share them in advance
• Gradually introduce topics beyond status updates into 1:1s

If they don't give feedback:

• Let them know feedback matters to you
• Ask for advice, not feedback - people like being asked for advice
• Seek input from peers, stakeholders, or skip-level leaders

If they fall short sometimes:

• Capture decisions in writing
• Keep them in the loop but don't rely exclusively on them
• Prepare short, fact-based updates they can use in leadership discussions

---

Communication Modes and When to Use Them

Synchronous vs. Asynchronous Communication

The most effective teams understand when to use synchronous (real-time) vs. asynchronous (time-shifted) communication. This isn't about preference - it's about matching the mode to the need.

Default to asynchronous when:

• Status updates and FYIs
• Process documentation
• Detailed technical conversations (especially when linked to code)
• Gathering consensus on a proposal
• Any topic that would require documentation afterward anyway

Use synchronous when:

• First-time meetings with new team members or external parties
• High-stakes, difficult-to-reverse decisions
• Emotionally sensitive topics (personal issues, career discussions, difficult feedback)
• Supporting and unblocking direct reports
• Celebrations and retrospectives
• When async back-and-forth exceeds 3 rounds without resolution
• Pair programming - Active code creation benefits from real-time collaboration (see Teamwork for more on pairing practices)

The Power of Asynchronous Communication

GitLab, a fully remote company with team members in 65+ countries, has pioneered async communication culture. Their key insight:

Asynchronous work is a simple concept: Do as much as you can with what you have, document everything, transfer ownership of the project to the next person, then start working on something else.

Six benefits of asynchronous working:

1. Autonomy and agency: Team members move projects forward on schedules that suit them
2. Increased efficiency: No waiting for synchronous alignment to take action
3. Inclusivity: Removes time zone barriers; business happens around the clock
4. Mental health: Reduces stress of needing to be always-on and available
5. Thoughtfulness: All communication becomes deliberate, never rushed or reactive
6. Knowledge preservation: Documentation bridges knowledge gaps across team changes

Making async work:

The key question to ask: "How would I deliver this message if no one else on my team were awake?"

This removes the temptation to take shortcuts or call meetings just to gather input. It requires:

• Strong documentation practices
• Low-context communication (precise, direct, with maximum context embedded)
• A single source of truth for ongoing work
• Tools and practices the whole team understands

Chat Communication (Slack, Teams, etc.)

Chat tools are ubiquitous but often misused. They should serve informal communication, not replace structured work artifacts.

Best practices:

• Use chat for informal communication primarily: Quick questions, social connection, real-time coordination
• Port important decisions to persistent locations: If a conversation in chat matters, it should be documented elsewhere (issues, docs, wikis)
• Don't let chat create always-on expectations: Remove notifications during focus time; consider removing chat apps from your phone entirely
• Clear messages regularly: Mark all messages as read daily or weekly to reduce cognitive load
• Use status indicators honestly: Signal when you're at capacity or in focus time

Anti-patterns:

• Expecting immediate responses
• Having critical discussions that aren't documented elsewhere
• Using chat as the single source of truth for project decisions
• Creating FOMO through channels people feel obligated to monitor

Video Communication

Video calls are powerful for building rapport and handling nuanced discussions but are expensive in terms of time and energy.

When video excels:

• Building relationships with new team members
• Brainstorming sessions that benefit from real-time iteration
• Delivering or receiving sensitive feedback
• Unblocking conversations stuck in async back-and-forth
• Team celebrations and social connection

Best practices:

• Every meeting must have an agenda: If you can't articulate what the meeting will accomplish, don't have it
• Make attendance optional when possible: Share agendas and docs in advance so people can contribute asynchronously
• Document everything live: The organizer is responsible for capturing outcomes and porting them to persistent locations
• Question every meeting: Ask "Could this be handled asynchronously?" before scheduling

The retrospective question:

For existing and upcoming meetings, ask: "Could this meeting have been handled asynchronously, and if so, how?" Share learnings publicly to build team awareness.

---

Written Communication Excellence

Written communication is the backbone of engineering work. READMEs, commit messages, PR descriptions, design docs, RFCs, chat messages - all are communication artifacts that represent you.

Principles for Excellent Written Communication

1. Read it from someone else's perspective

After writing, reread positioning yourself as the reader: What would someone think if reading this quickly and having never seen the material? What do they need to know right away? What questions might arise?

2. Don't blather

Avoid overstated corporate jargon that sounds official but means little. Speaking plainly and with clarity is hard - hold yourself accountable. Write for clarity, not for status.

Sometimes people write this way to be less transparent in high-risk situations. Speaking clearly can be an act of courage because you make intentions clear.

3. Format clearly

Structure documents so headings and outlines express the most important points. Someone should be able to skim and jump to relevant sections. Include:

• Author and last-edited date
• Clear section headers
• Summaries at the top for long documents (1000+ words should have highlights)

4. Lead with context

Before diving into details, explain why something matters. "We need to migrate because our current solution won't scale past 10k users" beats "Here's how we'll migrate."

Types of Technical Communication

Documentation through design docs, RFCs, and explainers:

• Force you to think through problems as you write
• Create artifacts others can contribute to asynchronously
• Preserve context for future team members

Code review comments:

• Specific, actionable, and kind
• "This could be clearer" helps less than "Adding a comment here explaining X would help future maintainers"
• Assume good intent - the engineer who wrote that code was likely under constraints you don't see

Group discussion threads:

• Use accurate names and @-handles to avoid confusion
• Time-box feedback with specific deadlines
• Be explicit about what action you're requesting

Presentations and video explainers:

• Consider pre-recording for async consumption
• Allow asynchronous Q&A before or after live sessions

---

Communication Culture: What Works

Building a Low-Context Culture

Low-context communication means messages are precise and direct, with maximum context embedded. Senders forecast what questions may arise and add context proactively. This:

• Removes ambiguity
• Decreases misinterpretation
• Enables self-service and self-learning
• Creates documentation that serves people who weren't in the room

Psychological Safety in Communication

Communication culture depends on psychological safety. People must feel safe to:

• Ask questions without judgment
• Admit mistakes without fear
• Disagree respectfully
• Share works-in-progress
• Give and receive feedback

Practices that build safety:

• Celebrate incremental improvements equally with major launches
• Embrace "everything is in draft" mentality
• Replace blame with curiosity
• Make feedback a regular, normalized practice
• Acknowledge that managers are human too

The "Don't Drop the Baton" Principle

Effective team communication shapes company culture at all levels. The key is treating communication like a relay race - clear handoffs are critical.

Good handoffs include:

• Complete context for the recipient
• Clear next actions
• Explicit ownership transfer
• Documentation of what was decided

Handling Conflict Through Communication

Conflict is inevitable in technical work. How you communicate through disagreement determines whether conflict is productive or destructive.

Principles:

• Assume good intent - most conflicts arise from different information or priorities
• Separate people from problems: "We have a challenge" not "You created a problem"
• Seek to understand before advocating your position
• Disagree and commit: once a decision is made, support it fully
• Document agreements to prevent repeated conflicts

---

Practical Frameworks

For 1:1 Meetings

• Come prepared with updates shared in advance
• Focus on context, risks, and opportunities - not just status
• At least twice a year, share professional goals and growth areas
• If covering topics async during the week, leave the calendar block for catch-up

For Communicating Change

When leading through change:

• Tailor communications to how people are experiencing the change
• Repeat key messages - people process change at different speeds
• Create space for questions and concerns
• Document the "why" behind decisions

For Communicating Mandates (Even If You Disagree)

• Present the mandate clearly without editorializing
• Provide context for why it matters to the organization
• Be honest about your own process while supporting the decision
• Create space for team concerns without undermining leadership

For Async 1:1s

An alternative format that builds communication skills:

1. Communicate that you'd like the next 1:1 to be async
2. During the week, comment in a shared agenda document with written or embedded video context
3. Use tags like "FYI" or "FYA" (for your attention)
4. Move unaddressed items to the next session and resume face-to-face

---

Communication Anti-Patterns to Avoid

In Writing

• Blather and corporate jargon that obscures meaning
• Assuming context the reader doesn't have
• Failing to document decisions (only outcomes)
• Writing for yourself instead of your audience

In Meetings

• Scheduling meetings that could be handled async
• Dominating discussions
• Failing to document outcomes
• Not having an agenda

In Chat

• Expecting immediate responses
• Using chat as the source of truth
• Creating always-on expectations
• Letting important discussions go undocumented

With Stakeholders

• Pitching instead of convincing (flash over facts)
• Glossing over problems or difficulties
• Not tailoring communication to the audience
• Forgetting that executives are "elephants and goldfish"

With Managers

• Never asking for help until it's too late
• Assuming they know what you need
• Letting 1:1s become purely status updates
• Not adapting to their communication style

---

TL;DR

• Default to async, use sync intentionally - documents, issues, and wikis reach everyone; switch to synchronous for high-stakes decisions, emotional topics, and when async has cycled 3+ times without resolution
• Write for your reader, not yourself - lead with context ("why this matters"), format for skimming, and document decisions (the "why"), not just outcomes
• Manage up proactively - understand your manager's style first, then share how you think ("heads-up, trying Y before Z"), not just status updates
• Treat executives as "elephants and goldfish" - they remember what you want them to forget and forget what you want them to remember; repeat key messages and always follow up on casual concerns
• Replace "No" with "Yes, but..." - lead with questions rather than declarations to invite dialogue instead of shutting it down

---

Sources and Further Reading

• Addy Osmani, "A Tech Lead's Guide to Effective Communication" (LeadDev)
• Sarah Drasner, "Writing Matters: How to Improve Your Written Communication Skills" (LeadDev)
• GitLab Handbook, "How to Embrace Asynchronous Communication for Remote Work"
• David Kiger, "How to Communicate with an Executive Audience" (LeadDev)
• Diego Quiroga, "Need-to-Know Tactics for Managing Up Successfully" (LeadDev)
• Kellan Elliott-McCrea on Managing Up
• Coda Hale, "Work is Work" on organizational design