An Engineer's Guide to Communication

Summary

Communication is inherently lossy, especially in writing, so technical skill alone cannot make engineering work reliable. Lauren Tan argues that engineers should treat people and communication as core parts of the work: listen first, ask questions to understand context, speak after hearing others, and express disagreement without turning observations into judgments about a person's character.

Why it matters

Many software problems are people problems. Tools and architectures cannot compensate for teams that misunderstand one another, skip context, or mistake strong opinions for effective communication. Better communication improves engineering execution and creates the trust needed to disagree, decide, and commit.

Key ideas

• What is left unsaid and how something is said can matter as much as the literal content.
• “Listen first, understand second, speak last” creates room for other people to be heard and gives the speaker more context before responding.
• Technical solutions such as microservices are not universal fixes; they can be organizational tools whose value depends on effective coordination.
• In a high-trust team, people can disagree and still commit to a decision owned by an informed captain rather than waiting for consensus.
• Nonviolent communication separates observation, feeling, need, and request.
• A factual observation such as “this change has no tests” should not be collapsed into a judgment such as “you do not respect the team.”
• Asking for the other person's explanation can reveal missing documentation, unfamiliarity, or another solvable constraint.

Practical applications

• In meetings, delay the first response long enough to hear the relevant perspectives and ask clarifying questions.
• When giving feedback, state the observable behavior, its effect, the need or concern it creates, and a specific request.
• Before proposing a technical solution to a coordination problem, inspect the roles, incentives, information flow, and decision ownership involved.
• In writing, make assumptions, context, and requested action explicit because readers cannot recover omitted tone or intent.
• Practice disagreement as a path to a better decision, not as a test of who is right or who belongs in the profession.

Open questions

• Which communication practices scale best as teams become more distributed and asynchronous?
• How can teams preserve informed decision ownership without allowing it to become unaccountable authority?
• What signals show that a feedback conversation has uncovered a system problem rather than merely corrected an individual behavior?

Related notes

• Commit to Commit
• Maximizing Success in Engineering Interviews