If you've been following our series, you know we've transformed check-ins from dreaded status meetings into valuable communication tools. We've dismantled the ineffective "what did you do yesterday" format and built a framework that respects both time and cognitive boundaries.
But there's a monster lurking in the shadows of even the best team communication systems: dependencies between teams.
This is where the rubber meets the road. Your team might be getting along perfectly, but the moment you need something from another group, everything grinds to a halt. It's not just frustrating; it's economically devastating.
The cost of dependencies
I remember once hearing something like: "The economic damage in our world isn't caused by idle people, it's caused by idle work," and it stuck.
I mean, think about it. When work sits waiting for a handoff, a review, or an approval, that's just pure waste, there’s no way around it. Your teams might look busy, but the work itself has stopped flowing. And dependencies between teams are the primary culprits.
The math here is sobering as well. Each dependency you add doesn't just increase risk linearly, it multiplies it exponentially. With two dependencies, your chance of smooth execution is already down to 25%. With five? You're looking at, what, roughly 3%?
No wonder projects with multiple team dependencies rarely finish on time.
Not all dependencies are created equal
Before jumping into solutions, we need to make a crucial distinction that transforms how you'll think about this problem.
There are two fundamentally different types of dependencies:
🌱 Structural dependencies
They're baked into your organizational design. They're the "all new features need security review" or "front-end always depends on back-end" patterns.
⏩ Instantiated dependencies
These are specific instances that arise from these structures: "we need security to review this login flow" or "front-end needs this specific API from back-end."
Here's the insight that changes everything: eliminating one structural dependency wipes out countless future instantiated dependencies. As one particularly insightful architect put it, "If I get rid of the class, I don't have any instances of it anymore."
Most organizations waste enormous energy juggling instantiated dependencies while ignoring the structural patterns creating them in the first place.
Reimagining check-ins for dependencies
OK, but how do we actually tackle this? Well, it starts with transforming how we approach check-ins. Luckily for you, we DailyBotters [🦦] know a thing or two about team check-ins. So here's the playbook:
Make the invisible visible
You can't fix what you can't see. Most team check-ins focus exclusively on each team's internal work, leaving the critical connections between teams in the shadows.
Try adding these questions to your check-in template:
✽ What are we waiting for from other teams that might slow us down?
✽ Who might be waiting on something from us?
✽ What structural patterns are creating these dependencies?
A product growth leader I worked with created a simple visual dashboard where dependencies appeared as lines between team cards. The thickness of each line represented the number of dependencies, while the color showed their status. This made the hidden network of dependencies instantly visible to everyone.
Solve the "when" problem
Knowing that a dependency exists is just the beginning. The critical question is: "When will it be resolved?"
This is particularly challenging because each team has its own priorities. Your urgent need might be someone else's "we'll get to it eventually."
In your cross-team check-ins, make expected resolution dates explicit:
"Team A needs this by Thursday for their release. Team B, can you commit to that date? If not, what's realistic, and what would need to change to make Thursday possible?" —This new you.
This conversation feels uncomfortable at first because it forces hard trade-offs into the open. But it's infinitely better than the alternative: silence followed by missed deadlines and finger-pointing.
Create working agreements
When teams interact repeatedly, don't reinvent the wheel each time. Establish clear working agreements that define how you'll handle dependencies.
These should cover:
- How requests get submitted and prioritized
- Expected response and resolution times
- How to handle conflicts and escalations
- What quality looks like for both sides
Create a simple template defining these parameters for common dependency types. Teams would reference these during check-ins rather than renegotiating the same ground over and over.
Attacking the root causes
Better coordination helps, but the real breakthroughs come from eliminating structural dependencies altogether. So we have four powerful strategies for you to discuss in your next strategic check-ins:
“Feature teams” (the highest ROI strategy)
The most effective approach for slashing dependencies is reorganizing around feature teams, you know, cross-functional groups with all the skills needed to deliver end-to-end value.
This isn't just theoretical. At DailyBot, we’ve used these “squads” to reduce major dependencies and make delivery much more reliable.
When everything you need is within one team, your check-ins shift from external coordination to internal collaboration: "How are we progressing toward our goal, and where do we need to change our collective focus?"
Shared services for specialized skills
Not every skill justifies a full-time position on every team. For specialized needs like legal, compliance, or specialized engineering, a shared services model can make sense.
The key here is making the service relationship explicit. In check-ins, these teams should provide transparency about their queue and capacity:
✽ Here's our current workload
✽ How we're prioritizing requests
✽ When teams can expect responses
Systemic swarming
For intensive but intermittent dependencies, consider systemic swarming: temporarily embedding specialists within teams during high-need periods.
For instance, imagine running "security sprints" where security engineers would join product teams for two-week periods rather than reviewing work asynchronously. This approach would slash both wait times and back-and-forth iterations on both ends.
During these “swarming periods,” check-ins focus on maximizing the embedded resource: "What do we need to accomplish while we have this expertise on our team?"
Control system-level WIP
The most overlooked strategy is simply limiting how many initiatives you pursue simultaneously. Many dependency problems stem from having too many competing priorities.
Use organizational check-ins to ruthlessly prioritize:
Given our dependencies and constraints, what are the few initiatives that deserve our full focus right now?
I know this might feel counterintuitive. Surely doing more things in parallel means finishing more? But the math of dependencies shows the opposite. Fewer parallel initiatives often means more total throughput because work flows instead of waiting.
Putting this into practice:
A 30-day plan
Let’s review how to implement these ideas in your organization:
Week 1: map the terrain
Start by understanding your current dependency landscape. Bring teams together to visually map both structural and instantiated dependencies.
Ask: "Which of these dependencies create the most delay and frustration?" This isn't about blame, instead, focus on identifying where changes will have the biggest impact.
Week 2: redesign your team check-ins
Revise your check-in formats to make dependencies visible and trackable. Create or modify your templates to capture:
✽ What dependencies exist
✽ When they're expected to resolve
✽ What happens if they don't
Establish clear escalation paths for when dependencies become blockers.
Week 3: implement new processes
Roll out your redesigned check-ins and train team leads on facilitating dependency-focused discussions. Start tracking how long dependencies typically take to resolve.
Use a simple metric (e.g. "dependency days") to measure the total time work spent waiting on dependencies each week. Just making this visible will help you focus on the right areas to improve.
Week 4: target structural solutions
Identify one structural dependency to eliminate. Design and begin implementing a structural solution, whether it's creating a feature team, establishing a shared service model, or implementing systemic swarming from time to time.
As you implement these changes, watch for these common traps:
The "dependency theater" trap
Many organizations create elaborate tracking systems that give the illusion of control without addressing root causes. They mistake visibility for progress.
Instead, for every dependency process you implement, ask yourself: "Is this helping us eliminate dependencies, or just manage them more efficiently?" Be honest about whether you're solving the problem or just documenting it better…
The "not my problem" syndrome
Teams often view dependencies as someone else's responsibility, leading to finger-pointing rather than collaboration.
Counter this by implementing shared metrics that measure the entire value stream, not just individual team performance. When everyone owns the system's performance, collaboration improves dramatically.
Priority mismatches
Different teams inevitably have different priorities, making dependency resolution inherently challenging.
Create a shared prioritization framework that teams use to evaluate requests. One effective approach is a simple 2x2 matrix of business impact versus urgency, giving both teams a common language for negotiating priorities.
Creating a dependency-conscious culture
Technical and process solutions only go so far. True dependency management requires cultural change (and willingness from everybody!) Use your check-ins to reinforce these principles:
Flow over utilization
Emphasize that keeping work flowing is more important than keeping people busy. A team waiting for dependencies to be resolved might appear "underutilized," but forcing them to start new work just creates more WIP and more dependencies.
System thinking over local optimization
Encourage teams to consider system-level impact, not just their own priorities. Questioning ourselves "how might our decisions create dependencies for others?" helps build this mindset.
Anticipation over reaction
Build the habit of looking ahead to identify dependencies before they become blockers. Simply asking "What dependencies might emerge in the next two weeks?" can prevent future fires.
Measuring real progress
How do you know if your dependency management is improving? Look beyond the obvious metrics like on-time delivery to these more revealing indicators:
Decreasing resolution time: Track how long it takes to resolve dependencies and watch for improvement trends.
Fewer escalations: Dependencies should increasingly be resolved without requiring management intervention.
Reduced structural dependencies: The total number of structural dependencies in your system should decrease over time.
Improved flow efficiency (it’s key): Calculate the ratio of active work time to total elapsed time. This shows how much time is lost to waiting.
Dependencies between teams are inevitable in complex work, but dependency hell surely isn’t. If you make dependencies more visible in your check-ins, distinguish between structural and instantiated dependencies, and systematically work to eliminate structural dependencies, you will transform a tangled web of interdependencies into a coordinated flow of value.
Remember that at its core, dependency management is about relationships between teams, and your check-ins are opportunities to build the shared understanding and trust that make complex work possible.
The organizations that thrive certainly aren't those with the fewest dependencies, but those that have learned to navigate dependencies with more intention, clarity, and mutual respect.
.jpg)
