Chapter 3: Communication

How to speak and listen in a standup so that two minutes of your time creates value for the whole team.

The Standup Communication Paradox

You have 1 to 2 minutes to:

• Share what you did
• Explain what you are doing
• Surface problems
• Enable collaboration
• Show you are contributing

Most people waste this time with verbose, irrelevant updates.

This chapter teaches you to communicate with precision, impact, and honesty.

The BRIEF Framework

Great standup communication is BRIEF:

• Bottom-line first
• Relevant to the team
• Interesting (keep attention)
• Explicit about blockers
• Forward-looking

Each element gets its own section.

B: Bottom-Line First

Lead with the conclusion. Provide context only if needed.

Bad: Rambling Story

"Yesterday I started working on the login feature and I had to set
up the authentication library first, which took longer than expected
because of some dependency conflicts. Then I spent time reading the
docs to understand how it works. I got partway through implementing
the endpoint, but it is not done yet. Today I will keep working on it."

Problems:

• Takes 30 seconds to get to the point
• People tune out
• No clear status

Good: Bottom-Line First

"Login endpoint is 60% done, will finish today. Had dependency
issues that are now resolved."

If someone wants details, they will ask.

The Formula

[Status of work item] → [What is next] → [Blockers if any]

Examples:

"User API is done and in review. Starting the frontend integration
today."

"Homepage redesign is blocked, waiting on design approval from Sarah."

"Database migration completed successfully. Moving to the reporting
feature."

R: Relevant to the Team

Filter out information that does not help the team.

Ask Yourself

• Does this help someone else do their work?
• Is this a blocker someone can unblock?
• Does this affect team priorities?
• Is this important context for collaboration?

If no to all four, skip it.

Bad: Irrelevant

"Yesterday I had three meetings, reviewed some PRs, answered Slack
messages, fixed a typo in the readme, and started thinking about
the architecture for the new feature."

None of this helps the team.

Good: Relevant

"The API is ready for frontend integration. David, I left comments
on your PR. Starting architecture design for the new feature, would
love input from anyone who has worked with microservices."

Every sentence creates value.

Common Irrelevant Details

• Number of meetings you had
• How busy you were
• Minor administrative tasks
• Things you "looked at" or "researched" without an outcome
• Activities that do not relate to current sprint goals

I: Interesting (Keep Attention)

If you are boring, people tune out and miss important information.

Energy and Pace

Low energy:

"Um, so, yesterday I, uh, worked on the thing. And today I guess
I will keep working on it. No blockers."

High energy:

"API endpoint shipped. Moving to frontend integration today."

Vary Your Language

Do not use the same phrases every day.

Boring repetition:

Monday      "I'm working on the login feature."
Tuesday     "I'm working on the login feature."
Wednesday   "I'm working on the login feature."
Thursday    "I'm working on the login feature."

Varied progress indicators:

Monday      "Starting the login feature, building the API first."
Tuesday     "API is half done. The auth flow is trickier than expected."
Wednesday   "API is done and tested. Ready for frontend integration."
Thursday    "Frontend is wired up. Doing polish and edge cases today."

Use Specific Milestones

Vague       "Making progress on the feature."
Specific    "3 of 5 endpoints done."

Vague       "Almost done."
Specific    "Done today if no surprises, tomorrow if complications."

E: Explicit About Blockers

The most important part of standup communication is surfacing problems.

Types of Blockers

1. Hard Blocker. Cannot proceed at all.

"Completely blocked. The API team has not deployed the endpoint I
need. Cannot start frontend until it is live."

2. Soft Blocker. Can work on something else, but not ideal.

"Blocked on design approval for homepage. Working on the settings
page instead, but it is lower priority."

3. Risk. Not blocked yet, but might be soon.

"Not blocked yet, but the third-party API is flaky. If it goes down,
we cannot test the integration."

4. Confusion. Do not understand something.

"Not sure I understand the acceptance criteria for this ticket. Can
someone help me clarify after standup?"

The Blocker Formula

[What is blocking you] + [Who can help] + [When you need it]

Examples:

"Blocked on database schema decision. Need Alice or Bob to review
my proposal by EOD so I can continue tomorrow."

"Waiting for staging environment access. Ops team, can someone help
me today?"

"Cannot finish the UI without the final mockups. Sarah, when will
those be ready?"

What NOT to Do with Blockers

• Do not hide blockers. Pride or fear makes people say "everything's fine"
• Do not be vague. "Having some issues" does not enable help
• Do not solve in standup. "We can chat after" is the right move
• Do not blame. "Sarah did not send me the mockups" becomes "Waiting on mockups from Sarah"

F: Forward-Looking

Talk about what is happening next, not just what happened.

Why It Matters

Backward-looking   feels like status reporting
Forward-looking    enables collaboration and planning

Bad: Backward-Only

"Yesterday I completed the login API and wrote tests for it."

What should the team do with this information?

Good: Forward-Looking

"Login API is done and tested. Sarah, you can start the frontend
integration whenever you are ready. I am available for questions."

Now Sarah knows she can proceed.

The Handoff

When your work enables someone else's work, hand it off explicitly:

"The API is deployed to staging. David, it is ready for you to
integrate. Ping me if you hit any issues."

The Ask

If you need something from the team:

"Starting the payment integration today. I will probably need a
code review from someone familiar with Stripe. Who is available?"

Complete Before/After Examples

Example 1: Feature Development

Before:

"Yesterday I worked on the dashboard. I had to refactor some stuff
because the code was messy. Then I added a new chart component but
it is not working quite right yet. There is a weird bug with the
data loading. I spent a lot of time debugging but could not figure
it out. I am going to keep trying today. Hopefully I can get it
working. No blockers I guess, just this bug."

After:

"Dashboard has a data loading bug I cannot solve. Blocked. Can
someone with state management experience pair with me this morning?"

Example 2: Bug Fix

Before:

"So yesterday we had that issue in production with the timeout
errors, and I looked into it and found that it was actually a
database query that was not indexed properly, so I added the index
and deployed it, and it seems better now but I am still monitoring
it to make sure."

After:

"Production timeout issue is fixed, it was a missing database index.
Monitoring for 24 hours to confirm. Back to feature work today."

Example 3: Starting New Work

Before:

"Yesterday I finished that ticket I was working on. Today I am
going to start on a new one. I think it is the shopping cart
feature. I will probably start by looking at the requirements and
figuring out how to approach it."

After:

"Shopping cart feature starts today. Planning to have the API done
by Thursday. Will sync with frontend team mid-week about
integration."

Advanced Techniques

The "Connect" Move

Link your work to someone else's to surface collaboration opportunities.

"I am building the export feature today. John, I saw you did CSV
exports last month. Mind if I reference your code?"

The "Offer" Move

Proactively offer to help.

"I finished early and have capacity. If anyone needs code reviews
or pairing, I am available."

The "Warn" Move

Surface risks before they become blockers.

"Heads up: I am on PTO Friday. If anyone needs me for reviews,
ping me by Thursday EOD."

The "Celebrate" Move

Recognise team wins.

"Big shoutout to Sarah for unblocking me yesterday. Got twice as
much done because of that pairing session."

Listening in Standups

Communication is not just talking. It is listening.

Active Listening Behaviours

• Make eye contact (or look at the camera if remote)
• Nod or react to show you are engaged
• Ask clarifying questions after someone speaks
• Take notes on blockers or handoffs
• Offer help when you hear someone struggling

Passive Listening (Don't Do This)

• Looking at your phone
• Working on your laptop
• Thinking about what you will say next
• Ignoring everyone except your manager
• No reaction or engagement

The "I Can Help" Moment

When you hear someone describe a problem you can solve:

Sarah: "I am stuck on the API authentication. Not sure how to
        handle the token refresh."

You:   "Sarah, I just did that last week. Catch me after standup."

This is why standups exist.

Communication for Different Roles

Individual Contributor

Focus on:

• Work item status
• Handoffs to others
• Blockers you need help with
• Offers to help others

Keep it brief: 60 to 90 seconds max.

Tech Lead

Focus on:

• Technical blockers across the team
• Architecture decisions needed
• Cross-team dependencies
• Risks to schedule or quality

Be careful not to dominate. Let the team speak first.

Manager (If Attending)

Focus on:

• Listening, not talking
• Noting blockers to unblock later
• Observing team dynamics
• Staying silent unless critical

Your role is to enable the team, not interrogate them.

Handling Difficult Situations

When You Have Nothing to Report

Bad: Make something up or ramble. Good: "Nothing from me today" or "Continuing on the same work, no changes."

Do not be afraid of having nothing to say. It happens.

When You Are Blocked and Frustrated

Bad (passive aggressive):

"Still waiting on design. Like I said yesterday. And the day
before. I guess I will just wait some more."

Good (direct and constructive):

"I have been blocked on design for 3 days. I need to escalate this.
Can we prioritise getting me unblocked today?"

When You Did Not Finish What You Committed To

Bad (defensive):

"I did not finish because I had meetings and stuff came up and
also the task was harder than I thought."

Good (honest and forward-looking):

"Did not finish yesterday. Underestimated complexity. Will finish
today. If not, we should reprioritise."

When You Do Not Understand Your Own Work

Bad (fake it):

"Yeah, working on the thing. Making progress."

Good (ask for help):

"I am confused about the requirements for this feature. Can someone
help me understand the use case after standup?"

When Someone Else Is Rambling

As facilitator:

"Thanks John. To stay on time, can you share the blocker and we
can dig into details after?"

As teammate (if no facilitator):

"John, sounds like you are blocked on X. Want to chat after
standup?"

Virtual Standup Communication

Camera On

Always have your camera on. It is not optional.

Benefits:

• Shows respect and engagement
• Nonverbal communication is visible
• Builds team connection
• Keeps people accountable

"But I am not ready on camera": get ready. You have a 9am standup every day. Plan accordingly.

Audio Quality

Invest in a decent microphone. Your built-in laptop mic is probably terrible.

Requirements:

• Clear, understandable speech
• No echo or background noise
• Consistent volume
• Stable connection

Screen Sharing

Share your screen when discussing:

• Work board or tickets
• Code or designs
• Architecture diagrams

Do not share your screen when:

• You are just giving verbal updates
• No visual is needed

Chat / Slack Usage

Use chat for:

• Sharing links while someone talks
• Noting action items
• Posting after standup: "We can chat at 2pm"

Do not use chat for:

• Side conversations during standup
• Your actual standup update (speak instead)

Body Language (Co-located)

Power Poses

Stand tall:

• Shoulders back
• Head up
• Open posture
• Confident stance

Avoid:

• Slouching
• Crossed arms
• Looking at phone
• Leaning away

Eye Contact

Make eye contact with the team, not just the facilitator.

Rotate your gaze. Look at different people as you speak. It shows you are talking to the team, not performing for the boss.

Gestures

Use natural hand gestures to emphasise points.

Avoid:

• Hands in pockets
• Playing with objects
• Fidgeting nervously

Tone and Energy

Match the Team's Energy

If the team is high energy:

• Be upbeat and quick
• Show enthusiasm
• Keep pace fast

If the team is low energy:

• Be calm and steady
• Do not force false enthusiasm
• Keep it professional

Inject Energy When Needed

When the standup feels like a slog:

"Quick win to share: we deployed the new feature yesterday and
already got positive feedback from three customers. Nice work,
team."

Stay Constructive About Problems

Negative framing:

"This stupid bug is killing me. The codebase is a mess. I cannot
get anything done."

Constructive framing:

"Tackling a gnarly bug today. It is a puzzle. Could use a second
set of eyes if anyone has time."

You can acknowledge hard problems without dragging the team down.

The 2-Minute Rule

If you cannot say it in 2 minutes, you are saying too much.

How to Compress

1. Remove context. Assume the team knows the background
2. Skip the back-story. Share the conclusion
3. Defer details. "We can chat after if you want to know more"
4. Use shorthand. "The API ticket" instead of "The ticket about the authentication API endpoint"

Practise Your Update

Before standup:

1. Write your update
2. Say it out loud
3. Time yourself
4. Cut anything over 2 minutes

This takes 60 seconds of prep and saves everyone time.

Questions to Ask

Good questions make standups valuable.

Clarifying Questions

"Sarah, when you say the API is 'almost done,' does that mean
done today or this week?"

"John, what specifically are you blocked on? Design, data, or
something else?"

Offering Help

"Alice, I have worked with that library before. Want to pair
after standup?"

"Bob, I can review your PR today if that helps unblock you."

Surfacing Risks

"If we are all blocked on staging access, should we escalate to
get that fixed today?"

"We have three people working on the same area. Should we
coordinate to avoid conflicts?"

Key Takeaways

1. Bottom-line first. Lead with the conclusion, provide context only if asked
2. Relevance matters. Filter out information that does not help the team
3. Surface blockers explicitly. The most important part of standup
4. Be forward-looking. Enable collaboration on what is next
5. Listen actively. The conversation matters, not just your update
6. Keep it under 2 minutes. Practise and compress
7. Camera on for virtual standups. Nonverbal communication matters
8. Do not hide problems. Honesty enables help

Practice Exercises

Exercise 1: Rewrite Your Last Update

Take your last standup update and rewrite it using the BRIEF framework:

• Bottom-line first
• Relevant only
• Interesting
• Explicit blockers
• Forward-looking

Exercise 2: Time Yourself

Record yourself giving a standup update. Watch it back. Time it.

• Too long? Cut unnecessary details
• Too vague? Add specifics
• Boring? Increase energy

Exercise 3: Listen Better

In your next standup:

• Do not think about your update until it is your turn
• Focus 100% on each speaker
• Ask at least one clarifying question
• Offer to help someone

Next Steps

Continue to 04-team-culture.md for the cultural foundation that makes communication work: psychological safety and high-performing teams.