Chapter 5: Handling Problems | Standups Tutorial

How to surface blockers, get them resolved, and stop the same ones from coming back next week.

The Reality of Blockers

Most standups fail because blockers are not handled well.

Problems surface but do not get solved because:

People minimise or hide blockers
Blockers are noted but not assigned
Follow-up does not happen
Blame replaces problem-solving
Root causes are not addressed

This chapter teaches you to handle blockers well.

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 finalise mockups. Been
waiting 3 days."

How to handle:

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

2. Knowledge Blockers

Do not 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 is 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. Cannot integrate until it is
stable."

How to handle:

Find a workaround or mock
Report the issue to the vendor
Escalate to the infrastructure team
Work on a different part of the 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 a 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 am being pulled in three directions. Need clarity on what is
most important."

How to handle:

Manager or 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 am blocked on X. I have 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. We can chat at 11am."

Record it:

Who is unblocking
What they will do
By when

3. Unblock (Outside Standup)

Do not solve in standup.

After standup:

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

4. Verify It's Resolved

Next standup:

You: "Alice unblocked me yesterday. Schema is decided. I am 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 or monthly:

Review blocker patterns
Identify systemic issues
Improve processes to prevent recurrence

Blocker Best Practices

As the Blocked Person

Do:

Surface early (do not wait days)
Be specific about what you need
Explain what you have 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 Unblocker

Do:

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

Don't:

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

As the Facilitator or Manager

Do:

Make sure 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:

A blocker has not been resolved in 2 business days
A blocker affects multiple people
You need authority you do not have
You need resources outside the team's control
The blocker is systemic (will repeat)

Do not escalate when:

You have not tried to solve it yourself
It has been less than 1 day
You are escalating out of frustration
It is within the team's power to solve

How to Escalate

Bad escalation:

"Sarah has not given me the mockups and now I am blocked. This is
ridiculous."

Good escalation:

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

Escalation Template

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

Example:

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

Handling Repeating Problems

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 are not ready.

Q: Why are designs not ready?
A: Because designer is busy with other projects.

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

Q: Why do we not plan design capacity?
A: Because design is not included in sprint planning meetings.

Q: Why is design not 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

Do not 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. "I noticed code reviews are taking a while. Can we talk about how to prioritise 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 am noticing you are blocked frequently. How can I help?"
Pair programming. Work together to build capability
Training. Identify skill gaps and address them
Clear ownership. Make sure they have the authority they need

The Blocker Hider

Problem:

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

Solution:

Build psychological safety. Show it is okay to admit struggles
Ask probing questions. "How confident are you that you will 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 are stuck."

The Blocker Creator

Problem:

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

Solution:

Surface the pattern. "I have noticed we are often waiting on you. What is 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 behaviour does not change

Production Issues During Standup

When Things Break

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 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: do not deploy anything today
- Tomorrow we 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 is doing what, what is blocked, what is next

Format:

"Status update in 30 seconds each:

- What you did in the last 4 hours
- What you are doing in the 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. Cannot test checkout."

Solution:

Immediate. Use sandbox or 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 simplify
Continuous review. Shift-left security, do not batch it
Automate. Security scanning tools instead of manual review

Personal Blockers

When You Are Struggling

Sometimes you are blocked by yourself:

Lack of motivation
Burnout
Imposter syndrome
Personal issues
Loss of clarity

It is okay to admit this.

In standup:

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

Or 1-on-1 with manager:

"I need to be honest. I am burned out. I need help."

When a Teammate Is Struggling

Signs:

Declining output
Missing standups
Disengaged
Hiding problems
Irritable

Do not ignore it. Check in privately:

"I noticed you seem off lately. Want to talk about it? I am here
if you need anything."

Blocker Metrics

Track blockers to improve over time.

What to Measure

Number of blockers per week.
- Trending up means systemic problems
- Trending down means process improvement is working
Time to unblock.
- How long from "I am blocked" to "I am unblocked"
- Target: under 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 a systemic issue

Using Metrics

Do not weaponise metrics:

Bad   "John had 5 blockers this sprint. What is wrong with you,
       John?"

Use metrics to improve process:

Good  "We had 12 blockers waiting on code reviews. We can 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 over 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 the sprint:

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

Create Slack

Slack means buffer capacity.

Don't:

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

Do:

Plan for 70 to 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. Do not 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
Do not blame. Focus on problem-solving and learning
Pre-empt blockers. The best blocker is one that never happens
It is okay to struggle. Personal blockers are real too

Blocker Response Checklist

When Someone Reports a Blocker

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

When You Are Blocked

[ ] Explain specifically what is blocking you
[ ] Share what you have 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 more than 2 days
[ ] Thank whoever unblocks you

Next Steps

Continue to 06-remote-distributed.md for making async and remote standups work.