Communication

Declare your status. Asking questions is the work.

Why Communication Matters

Most project failures aren't technical. They're communication failures.

Someone didn't know they were blocked. Someone assumed understanding that didn't exist. Someone waited too long to say "I don't know." Someone didn't write it down.

Technical skills get you hired. Communication skills determine what you can accomplish.

Declaring Your Status

Your manager, your team, your stakeholders, they can't see inside your head. They don't know if you're stuck, making progress, blocked, or confused. Silence looks the same whether you're crushing it or drowning.

Declare your status proactively.

The Phrases That Work

In discovery: "I'm in discovery on this. I'll have questions. Once I understand it, I'll come back with a plan."

This reframes not-knowing as process, not failure. It sets expectations. It buys you time to learn.

In validation: "I'm spiking the riskiest assumption. I'll know by end of day if our approach holds."

This shows progress while acknowledging uncertainty. You're not guessing; you're testing.

When blocked: "I'm blocked on X. I need Y to proceed. Can you help me get Y?"

Clear. Specific. Actionable. Not "I'm stuck" but "here's what would unstick me."

When behind: "This is taking longer than expected because of Z. Current estimate is now W."

Bad news early is better than bad news late. Surprises are worse than delays.

The Rhythm

Daily: Quick status to your team. What you did, what you're doing, what's in the way.

When things change: Immediately. Don't wait for the standup. If you're blocked, say so now.

When you don't know: Say that. "I don't know yet, but I'm working on finding out" is a valid status.

Asking Questions Is the Work

Questions during discovery aren't admitting weakness. They're doing the work.

The Permission to Not Know

You're allowed to not know. That's expected at the start of any significant work. The questions are how you get to knowing.

Bad: Pretending you understand when you don't. Building on shaky foundations. Wasting time because you were afraid to ask.

Good: "I don't understand X. Can you explain it?" "What did you mean when you said Y?" "I'm confused about Z; is it A or B?"

Questions asked early are cheap. Questions asked after you've built the wrong thing are expensive.

The Two Contexts

The old rule (adversarial contexts): Never ask a question you don't already know the answer to.

This applies in courtrooms, negotiations, some meetings. The question is a move in a game. Showing uncertainty is weakness.

The new rule (collaborative contexts): Ask because you don't know. That's the point.

This applies to most engineering work. You're trying to understand, not win. Questions reveal unknowns. Unknowns addressed early save time.

Know which context you're in. Most of your work is collaborative. Ask freely.

Asking Good Questions

Be specific. Not "I'm confused" but "I don't understand how X connects to Y."

Show your work. "I've looked at A and B and I think the answer is C, but I'm not sure because of D."

Ask the real question. If you're worried about something, ask about that thing. Don't dance around it.

Ask the right person. Who actually knows? Don't waste everyone's time.

Writing Things Down

Why Write

If it's not written down, it doesn't exist. Verbal agreements, whiteboard discussions, hallway conversations, they evaporate. People remember differently. Details shift.

Writing clarifies thinking. The act of putting it in words forces you to be precise. Fuzzy thinking becomes clear (or reveals itself as fuzzy).

Your future self is a stranger. You will not remember why you made this decision. You will not remember what the alternatives were. Leave breadcrumbs.

Writing scales. A conversation reaches the people in the room. A document reaches everyone who needs it, now and later.

What to Write

Decisions. What was decided, what options were considered, why this one was chosen. The ADR format from Chapter 8 works.

Status updates. Where things are, what's next, what's blocked.

How things work. Enough for someone else to understand. Not a novel, a map.

What went wrong. Post-mortems, learnings, mistakes. The pain should teach someone something.

Where to Write

Somewhere findable. If no one can find it, it doesn't exist. Team wiki, shared docs, repo readme; pick a place, use it consistently.

Close to the code. README in the repo. Comments explaining why (not what). The closer to the code, the more likely it stays current.

Not in Slack/chat. Chat is ephemeral. Important things should live somewhere persistent.

How to Write

Assume the reader is busy. Get to the point. Summary first, details after.

Assume the reader doesn't have context. What's the problem? What do they need to know to understand this?

Structure for scanning. Headers, bullets, bold for key points. People skim first, read second.

Update or delete. Outdated docs are worse than no docs. Wrong information is worse than no information.

Difficult Conversations

Some conversations are hard. Disagreements. Bad news. Feedback. Conflict.

The Principles

Direct is kind.^[1] Dancing around the issue wastes time and creates confusion. Say the thing.

Timely is better. Address issues when they're small. Waiting makes them bigger.

Focus on the work, not the person. "This code has a bug" not "You wrote buggy code." "This approach won't scale" not "Your idea is bad."

Seek to understand first. Maybe you're missing context. Maybe there's a reason. Ask before assuming.

Having Them

The opening: State what you want to discuss, clearly. "I want to talk about X."

The content: Describe the situation objectively. Explain the impact. Share your perspective. Ask for theirs.

The close: Agree on next steps. Follow up in writing.

After: Follow through. One conversation doesn't fix things. Change takes consistency.

Meetings

Meetings are expensive. Eight people in a room for an hour is eight hours of work.

Making Them Worth It

Have an agenda. What are we trying to accomplish? If you don't know, you don't need a meeting.

Invite the right people. Who needs to be there? Who doesn't? More people = less effective.

Start with the goal. "We're here to decide X" or "We're here to share information about Y." Be explicit.

End with action items. Who's doing what by when? If there are no action items, was the meeting necessary?

Keep them short. Default to 25 minutes, not 30. Default to 50, not 60. People need transitions.

Attending Them

Prepare. If there's an agenda or pre-read, actually read it.

Contribute or leave. If you're not adding value, you probably don't need to be there.

Take notes. Someone should. Ideally, notes go out after.

Follow up. If you committed to something, do it.

Communication Anti-Patterns

The Disappearance. Going silent when things get hard. This creates anxiety and removes your ability to get help.

The Info Dump. Sending walls of text with no structure. No one will read it.

The Assumption. Assuming people know what you know. They don't.

The Hedge. Saying "I think maybe possibly this might be an issue" when you mean "This is a problem."

The Surprise. Revealing a major issue at the last minute. Bad news early is always better.

The Blame Shift. "I didn't know" when you should have asked. "They didn't tell me" when you should have confirmed.

The Core Practice

Declare your status. Proactively. Regularly. Especially when things change.

Ask questions. Early. Specifically. Without shame.

Write things down. Decisions, status, how things work. Somewhere findable.

Have the hard conversation. Directly. Timely. Focused on the work.

Communication isn't a soft skill. It's how work gets done.

Declare your status. Ask the questions. Write it down. The communication is the work, not a distraction from it.