Every complex project hits blockers. Something depends on something else. A vendor is slow. A piece needs to be built before the next piece can start. This is normal, and experienced clients know it's normal.
What's not normal, and what erodes trust fast, is when you can't explain what's going on. "It's blocked" with no further context sounds like an excuse. "There are a lot of dependencies" sounds like you're hiding something. The skill here isn't avoiding blockers (you can't), it's making them understandable.
Why this matters
When a client hears "we're blocked" and doesn't understand why, they fill in the blanks themselves. Usually with something worse than reality. They start wondering if you planned poorly, if you're in over your head, if the whole project is off the rails.
But when you explain a blocker clearly, something changes. The frustration doesn't go away entirely, but it transforms from "why can't you just do this?" into "okay, that makes sense, what's the plan?" That shift, from suspicion to collaboration, is everything.
I've also found that clients who understand your constraints often help remove them. They'll chase down their own team for those design assets. They'll escalate with their vendor. They'll reprioritize so you can work around the block. But only if they understand the situation.
How to think about this
Explain why, not just what. "We're blocked" is a statement. "We're blocked because the reports module pulls data from the API, and the API isn't built yet, so there's nothing to pull from" is an explanation. The difference is enormous. One sounds like an excuse, the other demonstrates understanding.
Make invisible things visible. Dependencies are obvious to you because you live in the technical details. They're invisible to clients. Use analogies, diagrams, whatever it takes. A quick sketch showing "A needs B which needs C" does more than ten minutes of verbal explanation.
Different blockers need different conversations. A blocker where you're waiting on a third party is different from one where you underestimated complexity, which is different from one where you need the client's input. Be specific about what kind of blocker it is, because that tells the client what to expect and what they can do.
Never present a blocker by itself. Always pair it with: what you're doing about it, when you expect it resolved, what the timeline impact is, and what you're working on in the meantime. A blocker with a plan is manageable. A blocker without a plan is scary.
What good communication looks like
Explaining a technical dependency
Client asks: "Why can't you work on reports while the API is being built? Can't you do both at the same time?"
"Good question. The reports module displays data that it pulls from the API. Think of it like building a house: you can't install the plumbing fixtures until the pipes are in place. If we built the reports first, we'd have to rebuild them once we knew what the API actually provides.
What we can do simultaneously is design the reports UI while the API is being built. That way we're ready to wire everything together the moment the API is done. That's actually what we're doing now. The design doesn't wait, just the implementation that connects to live data.
Does that make sense?"
Why It Works
Clear analogy. Shows what can be done in parallel instead of just what can't. Demonstrates strategic thinking rather than passivity.
Communicating an external blocker
In a status update:
"Blocker update on payment integration:
We're waiting for [Third-Party Service] to activate our production API credentials. Their activation process requires manual review, which they do twice a week on Tuesdays and Fridays.
What we've done so far:
- Submitted documentation last Friday
- Followed up twice to confirm receipt
- Escalated through our account manager yesterday
Expected resolution: their Friday review, October 4.
Timeline impact: if approved Friday, no impact to the October 15 launch. If it slips another week, we'd need to push to October 18.
What we're doing while we wait:
- Pulling other features forward
- Prepping deployment scripts so we can move fast once unblocked
- Running payment tests in the sandbox environment
Fallback plan: if this drags past Friday, we launch with manual payment processing and add automated processing in a quick update the following week.
Bottom line: frustrating, but manageable. We're staying productive and have contingencies."
Why It Works
Crystal clear about the what, why, and when. Shows proactive effort to resolve. Quantifies the timeline risk. Demonstrates that you're staying productive. Offers a fallback.
Explaining hidden complexity
Client says: "Adding a profile picture should be simple, right? Can we add that quickly?"
"I get why it seems straightforward. And the core feature is pretty simple. But let me walk you through what's actually involved:
- Upload and storage: images need to go somewhere secure
- Image processing: resize and optimize so they load fast
- Security: validate that uploaded files are actually images, not something malicious
- Privacy: who can see whose photo?
- Performance: caching so images don't slow down the app
- Edge cases: what if an image fails to load? Need a default.
- Mobile vs. desktop: different image sizes for different screens
Each piece is maybe 2-4 hours, plus testing. Total is about 1.5-2 days.
We can absolutely add it. I just want you to know it's not a 30-minute task so you can prioritize accordingly. Still want to include it this sprint?"
Why It Works
Validates their intuition. Breaks down what "simple" actually involves. Gives a real time estimate. Empowers them to make an informed decision without telling them no.
A visual dependency map
Sometimes a quick diagram does more than any amount of explanation:
```
Phase 1: Foundation (Weeks 1-3)
├── Database setup
├── Authentication system
└── API framework
Phase 2: Core features (Weeks 4-6)
├── User profiles (needs: Authentication)
├── Messaging system (needs: User profiles)
└── Notifications (needs: Messaging system)
Phase 3: Advanced features (Weeks 7-8)
└── Analytics (needs: All of Phase 2)
```
"This is why we can't jump to analytics. It needs data from messaging, which needs user profiles, which needs authentication. Like building floors of a building.
The good news: once Phase 1 is done, multiple things can happen in parallel. We're front-loading the sequential stuff deliberately."
Why It Works
Makes the abstract concrete. Shows logic, not just timeline. Clients can see the "why" instead of just hearing it.
Being honest about a resource gap
"I want to flag something early. The payment integration includes PCI compliance requirements that are outside my core expertise. I can build the integration, but I want a security specialist to review it before launch. This is too important to get wrong.
Options:
- Bring in a specialist I've worked with for a half-day review. About $800, adds 3 days for scheduling.
- Launch without credit card storage. Less convenient for users, but avoids PCI scope entirely.
- Use a fully managed payment solution that handles compliance for us. Monthly cost, but faster and lower risk.
I'd recommend option 3. Faster, safer, probably cheaper long-term.
Wanted to surface this now so we can decide thoughtfully rather than hitting it as a surprise later."
Why It Works
Honest about limitations. Surfaces early. Provides real options. Makes a recommendation. Frames it as protecting the client, not making excuses.
What bad communication looks like
The vague excuse: "It's just really complicated. There are a lot of dependencies."
This tells the client nothing. It sounds like either you don't understand the situation or you're dodging the question.
The jargon wall: "We're blocked because the polymorphic association refactoring for the STI pattern conflicts with the eager loading strategy in the ORM..."
This actively excludes the client. It sounds like showing off or hiding behind complexity.
The blame shift: "We're blocked because you didn't get us the information we needed. We asked weeks ago."
Even if true, this is hostile. It damages the relationship and offers no constructive path forward.
The late surprise: Three weeks into a four-week sprint, "Oh by the way, we can't finish this feature because we're blocked on [thing]."
Should have been surfaced immediately. Leaving it this late suggests either you didn't notice or didn't care.
The shrug: "We're blocked waiting for the vendor. Not sure when they'll respond. Guess we just wait."
No plan, no follow-up actions, no initiative. This doesn't inspire confidence in anything.
Getting better at this
Build a standard blocker format. Every time you communicate a blocker, cover: what's blocked, why, what you've done about it, expected resolution, timeline impact, what you're doing meanwhile, and your fallback plan. Make it a checklist you run through every time.
Develop analogies for your common dependencies. Sequential dependencies are like building floors. Technical prerequisites are like plumbing before fixtures. External dependencies are like waiting for permits. Having these ready saves you from fumbling through explanations.
Surface blockers before they're blockers. "Heads up, we might get blocked next week if the vendor doesn't respond by Friday" is much better than "we're blocked and have been for three days." Early warning gives everyone more options.
Show agency even when stuck. Being blocked doesn't mean being passive. Show what you're doing to resolve it, what workarounds you're exploring, what you've reprioritized to stay productive. Blockers happen; helplessness is a choice.
Quantify everything. "This will delay us" is vague and anxiety-inducing. "This adds 3 days to the reporting module but doesn't affect the launch date" is specific and manageable. Help clients evaluate the actual impact.
How this connects
This skill leans heavily on explaining complex things simply, proactive communication (catching blockers early), delivering bad news (because blockers are rarely welcome news), and using analogies and visuals to make abstract things concrete. It also connects to expectation management, because blockers almost always require resetting timelines or priorities.
Things to try
- List your current project's blockers. For each, write a one-paragraph client-friendly explanation.
- Draw a simple dependency map for your project. Share it with your client.
- Next time you hit a blocker, surface it within 24 hours with a plan attached.
- Build a small library of analogies for the kinds of dependencies you hit most often.
- Ask your client after a blocker conversation: "Did that explanation make sense?"
Blockers are normal. What clients remember isn't that you got blocked. It's whether you explained it clearly, had a plan, and kept things moving.