Chapter 5: Handling Problems | Standups

The Reality of Blockers

Most standups fail because blockers aren't handled well.

Problems surface but don't get solved because:

People minimize or hide blockers
Blockers are noted but not assigned
Follow-up doesn't happen
Blame replaces problem-solving
Root causes aren't addressed

This chapter teaches you to handle blockers like a pro.

Types of Blockers

1. Waiting Blockers

Waiting on:

Another team
External approval
Third-party response
Infrastructure or environment

Example:

"Blocked waiting for the design team to finalize mockups. Been waiting
3 days."

How to handle:

Set a follow-up deadline
Escalate if deadline passes
Find workaround if possible
Work on something else meanwhile

2. Knowledge Blockers

Don't know:

How to approach the problem
What the requirements mean
How the system works
Which technology to use

Example:

"Not sure how to implement this feature. It's outside my experience."

How to handle:

Pair with someone experienced
Research and spike (time-boxed)
Ask for architectural guidance
Break into smaller, understood pieces

3. Technical Blockers

Technical issues:

Bugs in dependencies
Infrastructure problems
Performance issues
Complex technical challenges

Example:

"The third-party API keeps timing out. Can't integrate until it's stable."

How to handle:

Find workaround or mock
Report issue to vendor
Escalate to infrastructure team
Work on different part of feature

4. People Blockers

Need from others:

Code review
Pairing session
Decision or approval
Information or context

Example:

"My PR has been waiting for review for 2 days. Can someone review today?"

How to handle:

Ask specific person
Set expectation for when
If urgent, interrupt them politely
Pair review instead of async

5. Priority Blockers

Conflicting demands:

Multiple urgent tasks
Unclear priorities
Interruptions and context switching
Production issues taking time

Example:

"I'm being pulled in three directions. Need clarity on what's most
important."

How to handle:

Manager/lead clarifies priority
Say no to lower priorities
Protect focus time
Delegate or defer

The Blocker Lifecycle

1. Surface → 2. Assign → 3. Unblock → 4. Verify → 5. Learn

1. Surface the Blocker

In standup:

"I'm blocked on X. I've tried Y and Z. I need help from someone who
knows about [area]."

Be specific:

What exactly is blocking you?
What have you already tried?
What do you need to unblock?
How urgent is it?

2. Assign an Owner

Someone must own unblocking you.

In standup:

You:     "Blocked on database schema decision."
Manager: "Alice, can you help with this today?"
Alice:   "Yes, let's chat at 11am."

Record it:

Who is unblocking
What they'll do
By when

3. Unblock (Outside Standup)

Don't solve in standup.

After standup:

Schedule follow-up immediately
Pair or have focused discussion
Make decision or provide help
Clear the blocker

4. Verify It's Resolved

Next standup:

You: "Alice unblocked me yesterday. Schema is decided. I'm moving
     forward on implementation."

If not resolved:

You: "Still blocked. Alice and I discussed but need input from the
     architect team. Escalating."

5. Learn and Improve

Weekly/monthly:

Review blocker patterns
Identify systemic issues
Improve processes to prevent recurrence

Blocker Best Practices

As the Blocked Person

Do:

Surface early (don't wait days)
Be specific about what you need
Explain what you've tried
Suggest who might help
Follow up proactively

Don't:

Suffer in silence
Be vague ("having some issues")
Blame others
Expect someone to read your mind
Let it linger for days

As the Unbocker

Do:

Commit to specific time to help
Actually follow through
Check back that you actually unblocked them
Be generous with your time

Don't:

Say you'll help then forget
Make them wait days
Be annoyed that they asked
Make them feel stupid

As the Facilitator/Manager

Do:

Ensure every blocker gets an owner
Track blockers day-to-day
Escalate if not resolved in 2 days
Remove systemic blockers
Celebrate when blockers are resolved

Don't:

Just note it and move on
Assume someone else will handle it
Blame people for being blocked
Let the same blockers repeat

Escalation: When and How

When to Escalate

Escalate when:

Blocker hasn't been resolved in 2 business days
Blocker affects multiple people
You need authority you don't have
You need resources outside team's control
Blocker is systemic (will repeat)

Don't escalate when:

You haven't tried to solve it yourself
It's been less than 1 day
You're escalating out of frustration
It's within team's power to solve

How to Escalate

Bad escalation:

"Sarah hasn't given me the mockups and now I'm blocked. This is
ridiculous."

Good escalation:

"I've been waiting for design mockups for 3 days. I've followed up
twice. This is blocking me from starting the UI work. Can you help me
get unblocked?"

Escalation Template

1. What's the blocker?
2. How long have I been blocked?
3. What have I tried?
4. What's the impact?
5. What do I need?

Example:

"I need production database access to debug the issue [WHAT].
I've been blocked for 2 days [HOW LONG].
I've asked ops team twice via Slack [WHAT TRIED].
Customers are experiencing errors [IMPACT].
Can you help me get access today? [WHAT NEED]"

Handling Repeating Problems

The Pattern Recognition

Notice when:

Same blocker every sprint
Same person always blocked
Same process always breaks
Same dependency always delays

Example:

Week 1: "Waiting for design"
Week 2: "Waiting for design"  
Week 3: "Waiting for design"
Week 4: "Waiting for design"

This is a systemic problem, not a one-off blocker.

Root Cause Analysis

Ask "Why?" five times:

Q: Why are we blocked on design?
A: Because designs aren't ready.

Q: Why aren't designs ready?
A: Because designer is busy with other projects.

Q: Why is the designer on other projects?
A: Because we don't plan design capacity in sprint planning.

Q: Why don't we plan design capacity?
A: Because design isn't included in sprint planning meetings.

Q: Why isn't design included?
A: Because we never invited them.

Solution: Invite design to sprint planning.

Systemic Fixes

When you find patterns:

Change the process
Add slack in the system
Improve communication
Increase capacity
Remove dependencies

Don't just keep escalating the same blocker.

Dealing with Difficult People

The Unresponsive Teammate

Problem:

You: "I need code review."
[2 days pass, no review]
You: "Still need review."
[1 more day, no review]

Solution:

Ask directly in standup: "John, can you review my PR today?"
Set expectation: "I need it by 2pm to unblock deployment."
If still nothing: Escalate to manager or ask someone else
Follow up privately: "Hey, I noticed code reviews are taking a while. Can we talk about how to prioritize them?"

The Chronic Blocker

Problem:

Someone is blocked every single day on different things.

Solution:

Look for patterns: Are they lacking skills? Resources? Clarity?
1-on-1 conversation: "I'm noticing you're blocked frequently. How can I help?"
Pair programming: Work together to build capability
Training: Identify skill gaps and address them
Clear ownership: Ensure they have authority they need

The Blocker Hider

Problem:

Someone says "Everything's fine" until it's clearly not fine.

Solution:

Build psychological safety: Show it's okay to admit struggles
Ask probing questions: "How confident are you that you'll finish on time?"
Create check-in points: Break work into smaller pieces with mid-sprint checks
1-on-1: "I want you to feel safe telling me when you're stuck."

The Blocker Creator

Problem:

Someone consistently blocks others by not delivering on time or not
responding to requests.

Solution:

Surface the pattern: "I've noticed we're often waiting on you. What's going on?"
Identify root cause: Overloaded? Unclear priorities? Skill gap?
Set clear expectations: "Code reviews need to happen within 24 hours."
Track and follow up: Make delays visible
Manager intervention: If behavior doesn't change

Production Issues During Standup

When Shit Hits the Fan

Scenario:

9:00am standup starts
9:02am someone gets alert: production is down

What to do:

Option 1: Cancel standup

"Production is down. Standup is cancelled. Everyone not on incident 
response, proceed with your day. We'll resume tomorrow."

Option 2: Quick coordination

"Production issue. Quick 2-minute standup for awareness:
- Alice is leading incident response
- Bob and Carol are helping  
- Rest of team: don't deploy anything today
- Standup tomorrow we'll debrief

Everyone else, back to work."

All-Hands-On-Deck Mode

When in crisis:

Standups become tactical coordination
Multiple times per day if needed
Very short (5 minutes)
Focus: who's doing what, what's blocked, what's next

Format:

"Status update in 30 seconds each:
- What you did in last 4 hours
- What you're doing next 4 hours  
- Any blockers

Go."

Dealing with External Blockers

Blocked by Another Team

Problem:

"Waiting for the API team to deploy the endpoint. They said 'next week'
three weeks ago."

Solution:

Direct contact: Message their team directly
Manager escalation: "Can you help me get priority with the API team?"
Workaround: Mock the API, work on other parts
Visibility: Make the blocker visible to leadership

Blocked by Third-Party

Problem:

"The payment provider's API is down. Can't test checkout."

Solution:

Immediate: Use sandbox/test environment
Communication: Contact vendor support
Workaround: Feature flag it off until resolved
Document: Track vendor reliability for future decisions

Blocked by Process

Problem:

"Need security review before deploying. Takes 2 weeks."

Solution:

Plan ahead: Submit reviews earlier
Process improvement: Work with security to streamline
Continuous review: Shift-left security, don't batch it
Automate: Security scanning tools instead of manual review

Personal Blockers

When You're Struggling

Sometimes you're blocked by yourself:

Lack of motivation
Burnout
Imposter syndrome
Personal issues
Loss of clarity

It's okay to admit this.

In standup:

"I'm struggling with motivation this week. Work is going slower than
usual. I'm working through it."

Or 1-on-1 with manager:

"I need to be honest. I'm burned out. I need help."

When a Teammate Is Struggling

Signs:

Declining output
Missing standups
Disengaged
Hiding problems
Irritable

Don't ignore it. Check in privately:

"Hey, I noticed you seem off lately. Want to talk about it? I'm here
if you need anything."

Blocker Metrics

Track blockers to improve over time.

What to Measure

Number of blockers per week
- Trending up = systemic problems
- Trending down = process improvement working
Time to unblock
- How long from "I'm blocked" to "I'm unblocked"
- Target: < 24 hours for most blockers
Blocker categories
- What types of blockers are most common?
- Focus improvement there
Repeat blockers
- Same blocker appearing multiple times
- Indicates systemic issue

Using Metrics

Don't weaponize metrics: ❌ "John had 5 blockers this sprint. What's wrong with you, John?"

Use metrics to improve process: ✅ "We had 12 blockers waiting on code reviews. Let's discuss review SLAs."

The Blocker Board

Visual tracking of active blockers.

Simple Version

BLOCKED ITEM    | BLOCKED BY      | OWNER   | SINCE
----------------|-----------------|---------|-------
Payment API     | Design approval | Alice   | 3 days
User dashboard  | Code review     | Bob     | 1 day  
Email service   | Ops team access | Carol   | 2 days

Update Daily

Add new blockers from standup
Remove resolved blockers
Escalate items > 2 days old
Celebrate when blockers are cleared

Pre-empting Blockers

The best blockers are the ones that never happen.

Look Ahead

In sprint planning:

"What might block us?"
"Do we have all the dependencies?"
"Are designs ready?"
"Do we have infrastructure?"

During sprint:

"What risks are emerging?"
"What might become a blocker?"
"What can we do now to prevent it?"

Create Slack

Slack = buffer capacity

Don't:

Schedule 100% capacity
Have zero time for helping others
Run at maximum all the time

Do:

Plan for 70-80% capacity
Leave time for code reviews
Leave time for pairing
Leave time for unplanned issues

Key Takeaways

Surface blockers early: waiting makes them worse
Every blocker needs an owner: someone commits to unblocking
Follow through: verify blockers are actually resolved
Escalate after 2 days: don't let blockers linger
Look for patterns: repeating blockers indicate systemic issues
Build slack into the system: buffer capacity prevents blockers
Track blocker metrics: improve your processes over time
Don't blame: focus on problem-solving and learning
Pre-empt blockers: the best blocker is one that never happens
It's okay to struggle: personal blockers are real too

Blocker Response Checklist

When Someone Reports a Blocker

[ ] Clarify exactly what's blocking them
[ ] Ask what they've already tried
[ ] Identify who can help
[ ] Get that person to commit to when they'll help
[ ] Record the blocker and owner
[ ] Schedule follow-up discussion outside standup
[ ] Check next standup if it's resolved
[ ] If not resolved in 2 days, escalate

When You're Blocked

[ ] Explain specifically what's blocking you
[ ] Share what you've already tried
[ ] Suggest who might be able to help
[ ] Be clear about urgency
[ ] Follow up proactively if not unblocked
[ ] Work on something else if possible
[ ] Escalate if blocker persists > 2 days
[ ] Thank whoever unblocks you

What's Next

Now that you can handle blockers, let's explore how remote and distributed teams can run effective standups:

→ Chapter 6: Remote & Distributed: Making async and remote standups work