Dependencies are discovered late every cycle
Important cross-team or cross-system dependencies are found after work is already underway, not during planning or framing.
- Where you see this
large programsdistributed ownership modelsservice-heavy architectures
- Not necessarily a problem when
- a genuinely novel initiative is exploring unknown terrain and the uncertainty is explicit
- Often mistaken for
- this always happens in complex environments
- Time horizon
- near-term
- Best placed to act
architectprogram leadengineering manager
The signal
What you would actually notice
Late dependency discovery ruins predictability and creates avoidable re-planning.
Field observation
Teams start work confidently, then uncover blockers, approvals, or integration needs late in execution.
Also observed
- We did not realize we needed platform support.
- That dependency was only discovered during testing.
Primary reading
What it usually indicates
Most likely underlying patterns when this signal shows up. Not a diagnosis, a starting hypothesis.
Usually indicates
Most likely underlying patterns when this signal shows up.
- weak planning visibility
- poor system mapping
- cross-team ownership opacity
Stakes
Why it matters
Late dependency discovery ruins predictability and creates avoidable re-planning.
Inspection
What to check next
Deliberate steps to confirm or disconfirm the primary reading above. Not a checklist. An order of inspection.
- dependency mapping practices
- cross-team planning quality
- integration contract visibility
Diagnostic questions
Questions to ask the team, or yourself, before concluding anything.
- What did planning fail to reveal?
- Are dependencies hidden technically, organizationally, or both?
- Who knows the dependency graph best?
Progression
Under the signal
Where this pattern tends to come from, what's holding it up, and where it goes if nothing changes.
Leading indicators
What tends to show up first.
- planning confidence is high until implementation starts
- blocked states appear late
- cross-team meetings multiply mid-cycle
Common root causes
What is usually sitting under the signal.
- weak system understanding
- poor dependency mapping
- siloed teams
Likely consequences
What happens if nothing changes.
- delivery slips
- coordination overload
- scope churn
Look-alikes
Not what it looks like
Patterns that can be mistaken for this signal, and 'fix' attempts that make it worse.
- this always happens in complex environments
Anti-patterns when responding
Responses that feel sensible and usually make the underlying pattern worse.
- treating every late dependency as a one-off surprise
- planning detailed tasks without mapping the dependency surface
Context
Context and ownership
Where this signal surfaces, who sees it first, who can actually act, and how much runway there usually is before escalation.
Where it shows up
- large programs
- distributed ownership models
- service-heavy architectures
Who sees it first
Before it escalates.
- delivery lead
- program manager
- senior ICs
Who can move on it
Not always the same as who notices it.
- architect
- program lead
- engineering manager
near-term
How much runway there usually is before the signal hardens into the underlying pattern.
AI impact
AI effects on this signal
How AI-assisted and AI-driven workflows tend to amplify or hide this signal.
AI amplifies
Ways AI tooling tends to make this signal louder or more common.
- AI can speed up plan creation without improving actual dependency discovery.
AI masks
Ways AI tooling tends to hide this signal, so it keeps growing under the surface.
- Generated plans may look complete even when dependency mapping is shallow.
Relationships
Connected signals
Related failure modes, decisions behind the signal, response playbooks, and neighboring red flags.