Why Dependency Updates Are Never Just Technical Work
Matthew Holmes
April 20, 2026 · // 7 min read
“Just update the dependency across our repos” sounds simple. It is not.
The technical change takes 5 minutes. The coordination takes 3 weeks.
This is the dependency update paradox: the easier the code change, the harder the organizational challenge.
Managing dependency updates across multiple repos is a coordination problem. The code change takes minutes. The real work — creating PRs across 50+ repos, notifying teams, tracking stale reviews, resolving conflicts, following up repeatedly — takes 12+ hours of platform team time per initiative. At typical update frequency, that compounds to 96–144 hours of coordination overhead per quarter.
The Anatomy of a “Simple” Dependency Update
You need to upgrade a logging library from v2.3 to v2.4 across 65 microservices.
The technical work:
- Update package.json: 2 minutes
- Run tests: 5 minutes
- Total technical effort: 7 minutes per repo
The coordination work:
- Create 65 PRs: 2 hours
- Notify 18 teams: 30 minutes
- First follow-up round: 1 hour
- Second follow-up round: 1.5 hours
- Escalate stale PRs: 2 hours
- Fix merge conflicts: 1 hour
- Answer “why are we doing this?”: 3 hours (accumulated)
- Track progress in spreadsheet: 30 minutes/week for 3 weeks
- Total coordination time: 12+ hours
For every dependency update a platform team runs across a large repo organization, the coordination overhead is roughly 100x the technical effort.
Why Do Dependency PRs Sit Unmerged?
The real blockers are not technical.
“We Don’t Understand Why”
Teams get a PR with a dependency bump. No context. No urgency signal. No understanding of impact. Result: PR sits in review queue behind actual work.
“We’re Waiting for the Next Release”
Team has a quarterly release cycle. They’ll merge it when they have bandwidth. Result: PR open for 6 weeks, then closes due to conflicts.
“This Broke in Staging”
The update caused a test failure. The team deprioritizes investigating. Meanwhile, 64 other teams are waiting. Result: One blocker stops the entire initiative.
“We Lost the Notification”
Team got the notification, intended to review it, never got back to it. Result: Three follow-up messages later, they finally remember.
How Coordination Debt Compounds
Month 1:
- Start React update across 45 repos
- 3 weeks later: 30 merged, 15 in progress
Month 2:
- React update still ongoing (15 repos)
- Start Node.js update across 60 repos
- Now tracking 75 PRs across two initiatives
Month 3:
- React: 5 repos still pending
- Node.js: 35 merged, 25 in progress
- Start security patch across 80 repos
- Now tracking 110 PRs across three initiatives
Month 4:
- 140 PRs open across four initiatives
- You’ve lost track of which are blocking
- Teams are confused about which to prioritize
- Coordination overhead now exceeds technical work
This is why platform teams say they can only do one update at a time. The constraint is coordination, not engineering capacity.
What Makes Dependency Updates Different
Unlike feature work, dependency updates have distinct characteristics.
Scale. Feature work touches 1–5 repos. A dependency update touches 50+.
Coordination complexity. Feature work involves one team. A dependency update involves 15+.
Urgency variance. A security patch is urgent. A version bump is not. Both carry the same coordination overhead.
Merge order dependencies. Some teams need to wait for upstream libraries before they can merge. You are managing a dependency graph of teams, not just code.
Risk perception. Breaking changes in dependencies feel riskier than feature code. Teams delay.
What Doesn’t Work
Mandates from leadership. Leadership pressure does not solve the coordination problem. Now you are escalating to VPs to get PRs merged.
Dependency update schedules. Teams miss the schedule. Or they lack capacity that week. Or they merge without testing thoroughly.
Assigning owners per update. Owners still have to follow up with 50 teams. You have multiplied the coordination problem.
Batching all updates into one push. Merge conflicts, testing complexity, and risk perception all spike. Teams resist harder.
Every approach on this list treats coordination as a people problem. It is a systems problem.
What Actually Works
Make progress visible. “42 of 65 merged, 12 in review, 11 not started.” Everyone sees real-time status. No spreadsheet archaeology.
Automate notifications. Send reminders only to teams with stale PRs. Stop when they merge. Stop spamming everyone else.
Surface blockers early. Know which PRs have failed CI, merge conflicts, or missing reviewers. Fix them before they compound.
Track time-to-merge. Median time-to-merge tells you whether coordination is improving. Without this number, you cannot measure progress.
Put context in every PR. Link to documentation explaining why the change matters. Teams understand without asking. Follow-up volume drops.
The Real Metric: Time to 80%
Most teams measure 100% completion for dependency updates. That is the wrong metric.
Time to 80% merged is the number that matters.
The last 20% takes as long as the first 80%. The last 20% is usually legacy repos or teams without capacity. 80% coverage captures most of the security and compatibility value.
If it takes 3 weeks to reach 80%, coordination is the bottleneck.
What Does It Cost to Do Manual Dependency Upgrades at Scale?
Average dependency updates per quarter: 8–12. Average coordination time per update: 12 hours. Total coordination overhead per quarter: 96–144 hours.
That is 2–3 weeks of platform team time spent on coordination, not engineering.
Platform teams running 10+ dependency updates per quarter spend an average of 120 hours per quarter on coordination work that ships no new software.
Add security patches, framework upgrades, and breaking changes. The real number is higher.
Platform teams typically spend 35–40% of their quarterly capacity on dependency coordination when they manage it manually.
Automating Dependency Upgrades Across an Entire Org
Dependabot and Renovate create PRs inside individual repositories when new versions are available. They solve the per-repo detection problem.
The coordination problem is organizational. You need the same change applied across 65 repos, tracked in one place, with targeted follow-up for stale PRs and real-time visibility into blockers. Dependabot does not track cross-repo rollout status. Renovate does not follow up with Team B because Team A already merged. Neither tool eliminates the coordination layer.
Tidra is a Maintenance Agent that automates repetitive code changes — dependency upgrades, runtime migrations, config updates — across large engineering organizations, delivering every change as a reviewable pull request. Nothing auto-merges. Your CI validates. Your engineers review. The coordination layer — PR creation, rollout tracking, targeted follow-up — runs automatically.
The platform teams reclaiming that 120 hours per quarter are not running better scripts. They have replaced the coordination layer entirely.
The Path Forward
Better dependency management requires eliminating coordination overhead. The code change was never the problem.
Stop: manual PR creation, Slack follow-ups, spreadsheet tracking.
Start: automated workflows, targeted reminders, real-time rollout visibility.
Measure: time to 80% merge, coordination hours per update, follow-up count per initiative.
The platform teams that ship the most maintenance work are not faster engineers. They have removed the work that does not require an engineer at all.
See how Tidra eliminates dependency coordination overhead
Book a Demo