Chapter 3: Communication

The Standup Communication Paradox

You have 1-2 minutes to:

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

Most people waste this time with verbose, irrelevant updates.

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

The BRIEF Framework

Great standup communication is BRIEF:

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

Let's break down each element.

B: Bottom-Line First

Lead with the conclusion, then provide context 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's not done yet. Today I'll 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'll ask.

The Formula

[Status of work item] → [What's 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 doesn't 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.

❌ Irrelevant Information

"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.

✅ Relevant Information

"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's 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 outcome
❌ Activities that don't relate to current sprint goals

I: Interesting (Keep Attention)

If you're 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'll keep working on it. No blockers."

High energy:

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

Vary Your Language

Don't 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 authentication 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 hasn't deployed the endpoint I need.
Can't start frontend until it's 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's 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 can't test the integration."

4. Confusion: Don't understand something

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

The Blocker Formula

[What's 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?"

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

What NOT to Do with Blockers

❌ Don't hide blockers: Pride or fear makes people say "everything's fine"
❌ Don't be vague: "Having some issues" doesn't enable help
❌ Don't solve in standup: "Let's chat after" is the right move
❌ Don't blame: "Sarah didn't send me the mockups" → "Waiting on mockups from Sarah"

F: Forward-Looking

Talk about what's happening next, not just what happened.

Why This Matters

Backward-looking: Feels like status reporting
Forward-looking: Enables collaboration and planning

❌ Backward-Only

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

What should the team do with this information?

✅ Forward-Looking

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

Now Sarah knows she can proceed.

The Handoff

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

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

The Ask

If you need something from the team:

"Starting the payment integration today. I'll probably need a code 
review from someone familiar with Stripe. Who's 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's not working quite right yet. There's a weird bug with the data 
loading. I spent a lot of time debugging but couldn't figure it out.
I'm 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 can't 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 wasn't indexed properly, so I added the index and deployed it,
and it seems better now but I'm 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'm going to
start on a new one. I think it's the shopping cart feature. I'll 
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'm 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'm available."

The "Warn" Move

Surface risks before they become blockers.

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

The "Celebrate" Move

Recognize team wins.

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

Listening in Standups

Communication isn't just talking. It's listening.

Active Listening Behaviors

✅ Make eye contact (or look at camera if remote)
✅ Nod or react to show you're 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'll 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'm stuck on the API authentication. Not sure how to handle 
        the token refresh."
        
You:   "Sarah, I just did that last week. Let's chat 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-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
• Taking note of blockers to unblock later
• Observing team dynamics
• Staying silent unless critical

Your role: Enable the team, don't 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"

Don't be afraid of having nothing to say. It happens.

When You're Blocked and Frustrated

Bad (passive aggressive):

"Still waiting on design. Like I said yesterday. And the day before. 
Guess I'll just wait some more."

Good (direct and constructive):

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

When You Didn't Accomplish What You Committed To

Bad (defensive):

"I didn't finish because I had meetings and stuff came up and also
the task was harder than I thought."

Good (honest and forward-looking):

"Didn't finish yesterday — underestimated complexity. Will finish today.
If not, we should reprioritize."

When You Don't Understand Your Own Work

Bad (fake it):

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

Good (ask for help):

"I'm 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 keep us on time, can you share the blocker and we'll
dig into details after?"

As teammate (if no facilitator):

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

Virtual Standup Communication

Camera On

Always have your camera on. It's not optional.

Benefits:

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

"But I'm 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

Don't share your screen when:

• 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: "Let's chat at 2pm"

Don't use chat for:

• Having 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
• Shows you're talking to the team, not performing for the boss

Gestures

Use natural hand gestures to emphasize points.

Don't:

• Keep hands in pockets
• Play with objects
• Fidget 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
• Don't 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 Positive About Problems

Negative framing:

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

Positive framing:

"Tackling a gnarly bug today. It's 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 can't say it in 2 minutes, you're saying too much.

How to Compress

1. Remove context: Assume the team knows the background
2. Skip the journey: Just share the conclusion
3. Defer details: "Let's chat after if you want to know more"
4. Use shorthand: "The API ticket" instead of "The ticket about the authentication API endpoint"

Practice 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? Is it design, data, or
something else?"

Offering Help

"Alice, I've 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're 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 doesn't help the team
3. Surface blockers explicitly: the most important part of standup
4. Be forward-looking: enable collaboration on what's next
5. Listen actively: the conversation matters, not just your update
6. Keep it under 2 minutes: practice and compress
7. Camera on for virtual standups: nonverbal communication matters
8. Don't 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:

• Don't think about your update until it's your turn
• Focus 100% on each speaker
• Ask at least one clarifying question
• Offer to help someone

What's Next

Great communication is necessary but not sufficient. For standups to truly work, you need strong team culture:

→ Chapter 4: Team Culture: Building psychological safety and high-performing teams