Dependency Management in AI Parallel Work: Spot Blockers Early

Dependency Management in AI Parallel Work: Spot Blockers Early

When development accelerates with AI tools, the team naturally starts running more things in parallel. Backend APIs are being written while frontend components are being prepared, QA test scenarios are being written, documentation is being created. All at the same time, all connected to each other.

Parallel work increases efficiency. But it brings an invisible risk with it: dependencies.

Frontend is waiting on the API. The API is waiting on third-party service approval. The approval process is unclear. If this chain is written nowhere, Friday brings the surprise "this didn't finish." But if it had been visible on Monday, a four-day recovery window would have opened.

Why AI Parallel Work Makes Dependencies Invisible

In traditional development, sequential work kept dependencies naturally visible. B didn't start before A finished because writing B took time. The waiting was embedded into the process.

AI changed this structure. Now B can start before A finishes — AI produces something quickly, the developer moves forward. But B still genuinely needs A to complete. The difference is this: that wait is no longer visible because B appears active under the "In Progress" label.

Fake progress: Multiple tasks in "In Progress" simultaneously. Everything appears to be moving. In reality several are blocked, the waiting is hidden.

No dependency note: "B can't start until A finishes" was said during sprint planning but not written down. Mid-week, who is waiting on what becomes unclear.

Early reporting feels costly: Saying "I'm blocked" still feels like weakness. The developer deals with other things while waiting, doesn't report the blocker. The team lead learns about it at week's end.

WAITING Status in Alios

The center of dependency management in Alios is the WAITING status. Added to the standard four statuses, it means "not actively working, something is being waited on."

🔄 IN PROGRESS → actively being worked on
⏳ WAITING     → waiting on external input, can't progress
👀 REVIEW      → complete, awaiting approval
✅ DONE        → closed

The difference between WAITING and REVIEW is critical. In REVIEW, work is complete and someone else's evaluation is being waited on. In WAITING, work is incomplete and an external input is needed to continue.

Without this distinction, the blocker gets hidden. The WAITING status surfaces the blocker.

Blocker Note Format When Moving to WAITING

When a task moves to WAITING, a standard format gets filled in. A single "I'm waiting" line isn't enough — all the information needed for resolution gets written into the node.

⏳ WAITING — [Date / Time]

What is being waited on:
[Specific — not "API info" but
"Payment service sandbox API key and
webhook endpoint list"]

Who it's being waited on from:
[Name or team — internal or external source]

When it's expected to arrive:
[Date — if unknown: "unclear, will follow up"]

This task's deadline:
[Date — if wait exceeds N days, what is
the effect on the sprint goal]

Is there an alternative:
[ ] Yes — [Mock data can be used /
            Can proceed from another module]
[ ] No — fully blocked, chain is stopped

Follow-up action:
[Who, when, how will follow up —
"Will message Zeynep on Slack today,
if no reply by tomorrow: escalation"]

This format answers five questions: what is being waited on, from whom, by when, is there an alternative, and what is being done right now. When the answers to these five questions are written in the node, the team lead can intervene.

5 Common Blockers and Resolution Actions

The five most common blocker types in AI-assisted parallel development, and the resolution action to apply in Alios for each:

Blocker 1 — External API or Service Approval

⏳ WAITING — Stripe Sandbox Access

What: Stripe sandbox API key and webhook test endpoints
From: Stripe developer portal — approval process
When: 1-3 business days (unclear)
Deadline impact: If API doesn't arrive by Wednesday,
payment integration moves to Thursday, QA may not
make Friday

Alternative: Yes — basic flow can be written with
Stripe's test mocks, real key integrated when it arrives

Follow-up:
- Today: Check Stripe portal for application status
- Tomorrow morning: If no update, contact Stripe support
- Wednesday noon: Still nothing → decision to proceed
  with mock

Blocker 2 — Internal Team Dependency

⏳ WAITING — Backend API Not Ready

What: /api/payments/history endpoint —
response format and pagination structure
From: Ali (backend) — within his own sprint task
When: Tuesday EOD (Ali's deadline)
Deadline impact: If API doesn't arrive by
Wednesday morning, frontend moves to Thursday

Alternative: Yes — can start component writing
with mock data based on draft response format
Ali shared

Follow-up:
- Today: Quick sync with Ali — can draft response
  format be shared now?
- Tuesday 17:00: Check if API is ready
- If not ready: decision to proceed with mock

Blocker 3 — Design or Content Approval

⏳ WAITING — Design Approval

What: Payment history page Figma approval —
mobile view and empty state design
From: Zeynep (design) — in review queue
When: Requested Monday EOD, no response
Deadline impact: If approval doesn't arrive by
Tuesday noon, frontend can't be completed,
Thursday deadline at risk

Alternative: Partially — desktop view approved,
mobile and empty state can wait but delivery
won't count as complete

Follow-up:
- Today: Slack reminder to Zeynep — specifically
  requesting mobile and empty state approval
- Tuesday morning: No response → direct meeting
  request — 15 minutes is enough
- If no approval: proceed with current design,
  revise later, this decision goes on record

Blocker 4 — Technical Uncertainty

⏳ WAITING — Architectural Decision Pending

What: WebSocket or SSE? — architectural choice
for real-time feature not made
From: CTO or technical lead — decision maker
When: Will be brought to today's meeting
Deadline impact: If decision not made today,
implementation deferred to Wednesday,
sprint goal at risk

Alternative: No — implementation can't start without
architectural decision, wrong choice rewrites all code

Follow-up:
- Added to today's noon meeting agenda
- Decision will be made today, ADR node will be opened
- If no decision: tomorrow morning async decision process —
  Ali and CTO write options in node, decision by EOD

Blocker 5 — External Team or Agency Delay

⏳ WAITING — Agency Delivery Delay

What: Landing page HTML/CSS output —
agency said "delivering tomorrow" 3 days ago
From: XYZ Agency — external supplier
When: Promised 3 days ago, still not here
Deadline impact: If delivery doesn't come today,
integration and testing won't fit in Friday,
may need to move to sprint 15

Alternative: Partially — integration can start with
current draft but can't go live without final delivery

Follow-up:
- This morning: Email + phone to agency — "If not
  delivered by noon, late delivery clause in
  contract applies" — clear message
- Noon: No delivery → project manager steps in
- 17:00: Still nothing → sprint 15 move decision
  made and client is informed

Weekly Risk Control Routine

Opening WAITING nodes isn't enough — without regular review, they remain static records rather than becoming a dynamic management tool.

Twice a week, 20 minutes total:

📋 MONDAY MORNING — 10 MINUTES

1. List WAITING nodes
   → How many are there?
   → For each: is "when is it expected?"
     answered?
   → Any carried over from last week?
     Why still open?

2. Check dependencies on this week's
   deadline tasks
   → Was the dependency completed?
   → If not: is the deadline at risk?
   → If yes: will action be taken today?

3. If new parallel work started,
   check for dependencies
   → Was every new sprint task's
     dependency written into the node?

─────────────────────────────

📋 WEDNESDAY NOON — 10 MINUTES

1. Were Monday's WAITING nodes resolved?
   → If resolved: did they move to IN PROGRESS?
   → If not resolved: how many days in WAITING?

   WAITING aging scale:
   1 day  → Normal, being tracked
   2 days → Active follow-up — resolution step today
   3 days → Escalation — to management or
             directly to the relevant person
   5 days+→ Sprint goal at risk —
             alternative plan confirmed today

2. Is there chain drift?
   → Does one task's delay affect subsequent
     tasks' deadlines?
   → If yes: were those nodes' deadlines updated?

3. Is something now visible that won't
   make it to Friday?
   → If yes: decision made today —
     does scope shrink, does it move to next
     sprint, does extra resource come in?

The value of the Wednesday check is here: saying "this might not make it" on Wednesday instead of "this didn't finish" on Friday opens a two-day intervention window. In this window the blocker gets resolved, scope gets reduced, or a conscious move decision gets made.

Blocker Reporting Culture

No matter how well the system is built, if reporting a blocker isn't normalized, the WAITING status doesn't get used.

Three rules build this culture. First: reporting a blocker is sharing information, not showing failure. Saying "I'm blocked" doesn't mean "I can't do it" — it means "this link in the chain needs this input." Second: no permission is needed to move to WAITING — the developer updates the node themselves, doesn't wait for approval. Third: a late-reported blocker is evaluated, not judged. The question "why didn't you say this sooner?" prevents early reporting next time. Instead, focusing on solutions with "what can we do now?" keeps energy on resolution.

Final Thought

AI increases parallel work. Parallel work increases the number of dependencies. When dependencies aren't managed, speed becomes a source of risk rather than gain.

WAITING status, the blocker note format, and the weekly risk routine in Alios make this risk visible. Blockers stop being Friday surprises — they appear Monday, get resolved Wednesday, and the sprint closes Friday.

Keeping the first domino upright before the chain falls is possible. But only if you can see it wobbling.