The Dependency Fog
Critical upstream and downstream dependencies exist, but are discovered too late and managed too weakly.
- Also known as
integration surprisethe hidden critical pathassumed handoffcoordination debt
- First noticed by
delivery leadarchitectprogram lead
- Mistaken for
- normal coordination complexity
- Often mistaken as
- bad luck
Why it looks healthy
Concrete external tells that make the pattern read as responsible behavior.
- Each team can describe its own work crisply
- Dependencies are acknowledged informally by everyone involved
- Planning meetings produce confident delivery dates
- Nobody has flagged a blocker yet
Definition
What it is
Blast radius delivery team systems business
A team believes it understands the path to delivery, but hidden dependencies keep changing that path after work has started.
How it unfolds
The arc of the pattern
-
Starts
The plan looks achievable from the perspective of each individual team.
-
Feels reasonable because
Dependencies are often socially known but not operationally managed.
-
Escalates
Integration assumptions fail, handoffs slip, and blockers appear serially instead of visibly.
-
Ends
Schedules slide, blame circulates, and teams discover they never had a shared delivery map.
Recognition
Warning signs by stage
Observable signals as the pattern progresses.
EARLY
Early
- We'll need something from that team later.
- Dependencies live mostly in conversations.
- Integration points are assumed rather than tested.
MID
Mid
- Blockers keep appearing after planning.
- Teams report progress locally but not systemically.
- Release plans depend on unowned external promises.
LATE
Late
- Everyone says they are waiting on everyone else.
- Cross-team integration becomes a fire drill.
- Dates move because unknowns arrive as surprises.
Root causes
Why it happens
- Local planning dominates system planning
- Ownership boundaries are unclear
- Interfaces are socially assumed, not technically or operationally validated
- Cross-team coordination is underinvested
Response
What to do
Immediate triage first, then structural fixes.
First move
List every external input your next milestone depends on - with an owner, a date, and a written confirmation from that owner.
Hard trade-off
Accept slower commitments now in exchange for commitments that actually hold, or keep the fog and keep missing dates.
Recovery trap
Building a dependency-tracking tool before anyone has started owning dependencies by name.
Immediate actions
- Map dependencies explicitly
- Name owners, dates, and integration proof points
- Surface assumptions in writing
Structural fixes
- Track critical path dependencies separately
- Add early integration milestones
- Use program-level visibility only where it changes action
What not to do
- Do not treat every dependency as equal
- Do not wait for full certainty before testing interfaces
AI impact
How AI distorts this pattern
Where AI-assisted workflows accelerate, hide, or help with this failure mode.
AI can help with
- AI can extract dependency graphs from tickets, docs, code, and meeting notes and make critical paths more visible.
AI can make worse by
- AI can make local work appear faster and cleaner while hiding the fact that system-wide dependency uncertainty remains unresolved.
Relationships
Connected patterns
Causal flows inside Failure Modes, and related entries across the site.
Easy to confuse with
Nearby patterns and how this one differs.
-
That failure mode is about the shape of specific contracts drifting. Dependency fog is about the set of dependencies being unknown at all.
-
Ownership drift is unclear who owns a system. Dependency fog is unclear who agreed to deliver what to whom.
- Adjacent concept Normal coordination complexity
Real coordination has named commitments. Fog has shared assumptions.
Heard in the wild
What it sounds like
The phrase that signals the pattern is about to start, and who tends to say it.
We should be unblocked once the other team lands their part.
Said bydelivery lead or engineering manager
Notes from practice
What experienced people notice
Annotations from engineers who have worked this pattern before.
- Best momentWhen intervention actually changes the trajectory.
- Before sequencing work based on assumptions
- Counter moveThe specific action that breaks the pattern.
- Turn vague dependencies into owned, testable commitments.
- False positiveWhen this pattern is actually the correct call.
- Complex work really does have dependencies. The failure mode is unmanaged dependency, not dependency itself.