Tindlo Learn
The Cross-Team Dependency Register: A Kickoff Worksheet for Naming, Owning, and Scheduling Every Dependency Before Work Begins

The Cross-Team Dependency Register: A Kickoff Worksheet for Naming, Owning, and Scheduling Every Dependency Before Work Begins

Published

Picture this: a project kicks off on Monday. Everyone leaves the kickoff meeting feeling good. Then, three weeks in, one team is blocked because they're waiting on an API from another team—a team that didn't know the deadline was so soon. The schedule slips. People scramble. Someone says, "We should have caught this earlier."

They're right. And the fix isn't a better retrospective. It's a better kickoff.

This article gives you a practical worksheet—a Cross-Team Dependency Register—that you can fill out during or right after your project kickoff. It helps you name every dependency, assign a clear owner, and put a date on it before anyone writes a single line of code or ships a single deliverable.

What Is a Cross-Team Dependency?

A dependency is anything your team needs from someone outside your team before you can move forward. It could be:

Dependencies aren't bad. They're just facts of how work flows across teams. The problem isn't having them—it's not knowing about them until they become blockers.

Some practitioner discussions describe this as a recurring frustration: the dependency existed from day one, but nobody wrote it down, nobody owned it, and nobody put a date on it. By the time it surfaced, it was already late. A practitioner discussion about lost project context captures this pattern well: cross-team communication and dependency management.

Why a Register, Not Just a List

A list says: "We need X from Team Y."

A register says: "We need X from Team Y. Sarah owns it on our side. Marcus owns it on their side. We need it by October 14th. If it's late, it blocks the checkout flow."

The difference is accountability and timing. A register turns a vague awareness into a trackable commitment. It gives both sides something concrete to point to in a status meeting, a planning session, or a difficult conversation about slipping timelines.

The Worksheet: Seven Columns That Cover Everything

You can build this register in a spreadsheet, a shared doc, or a work management tool. What matters is that every dependency gets all seven fields filled in before the project starts moving.

Here's the structure:

Column 1: Dependency Name

Give it a short, plain-language name. Not "API work" — something like "Payment Gateway API: sandbox credentials." Specific names make it easier to find, discuss, and track.

Column 2: Requesting Team

Which team needs this? Be specific. "Frontend" is better than "Engineering."

Column 3: Providing Team

Which team is responsible for delivering it? If it's a vendor or external party, name them here too.

Column 4: Internal Owner (Requesting Side)

Who on your team is responsible for following up, escalating if needed, and confirming delivery? This person doesn't do the work—they make sure the dependency doesn't fall through the cracks.

Column 5: External Owner (Providing Side)

Who on the other team has agreed to own delivery? Get a name. "The platform team" is not an owner. "Priya from Platform" is.

Column 6: Required By Date

When does your team need this in order to stay on schedule? Work backward from your milestone. If you need the API to start integration testing on November 1st, and integration testing takes a week, you need the API by October 25th—not November 1st.

Column 7: Downstream Impact

What breaks or slows down if this dependency is late? Write it in plain terms: "Blocks QA for the onboarding flow" or "Delays the public launch by at least one sprint." This column is what makes the stakes visible to everyone, including people outside your team.

A Filled-In Example Row

Here's what a completed row might look like for a software product launch:

That one row replaces a dozen unclear Slack messages and two missed status updates. Everyone who reads it knows exactly what's needed, who's responsible, and what happens if it slips.

How to Run the Dependency Register Exercise at Kickoff

You don't need a special workshop or a two-hour meeting. Here's a lightweight approach that fits into a standard kickoff.

Step 1: Share the register template before the meeting

Send the blank seven-column register to every team lead who'll be in the kickoff. Ask them to come with a rough list of things they'll need from other teams, and things other teams might need from them. Even a rough list is better than starting from zero.

Step 2: Walk the project timeline out loud

During the kickoff, walk through the project phase by phase. As you describe each phase, ask: "What does this phase need that comes from outside this team?" Let people call out dependencies in real time. Someone takes notes directly into the register.

Step 3: Assign owners before you leave the room

For every dependency named, get two names: one from the requesting team, one from the providing team. Don't leave the meeting with "TBD" in the owner columns. If someone isn't in the room, assign someone to follow up within 24 hours.

Step 4: Set the dates by working backward

For each dependency, ask: "When does the requesting team need this to stay on schedule?" Then check whether the providing team can realistically hit that date. If there's a gap, surface it now—not three weeks from now.

Step 5: Review the register at the first weekly sync

The register isn't a one-time artifact. Bring it to your first weekly sync and check the status of each item. Mark anything that's been delivered. Flag anything at risk. Keep it alive.

Common Dependency Types Worth Checking Explicitly

During kickoff, it's easy to catch the obvious dependencies and miss the quieter ones. Here's a checklist of dependency categories worth asking about explicitly:

Running through this list at kickoff takes about five minutes and can surface dependencies that wouldn't have appeared until they became blockers.

What to Do When a Dependency Has No Clear Owner

Sometimes you'll name a dependency and nobody in the room owns it. This happens when the providing team isn't represented at the kickoff, or when the work falls in a gray zone between teams.

When this happens, don't leave it blank. Instead:

An unowned dependency is a risk. Naming it as unowned—and assigning someone to resolve that—is still better than pretending it doesn't exist.

Keeping the Register Visible After Kickoff

A dependency register that lives in a folder nobody opens is just a document. For it to work, it needs to be somewhere people actually look.

A few approaches that help:

The goal is for the register to feel like a living part of the project, not a compliance artifact from week one.

How Tindlo Helps You Keep Dependencies in Context

One challenge with dependency registers is that they often live separately from the actual work. The register is in a spreadsheet; the tasks are in a project tool; the schedule is in someone's calendar. When these are disconnected, it's easy to lose track of which dependency affects which milestone.

Tindlo is a multi-layer operational scheduling platform that puts teams, projects, and work items on a shared time axis. You can create work items that include people, tags, files, links, a brief, and comments—so a dependency can live as a work item with all its context attached: who owns it, what it blocks, and when it's due.

Because Tindlo separates teams and projects into parallel layers on a shared timeline, you can see your team's work alongside the work of the teams you depend on. That kind of shared operational visibility makes it easier to spot when a dependency's due date is drifting toward a milestone it was supposed to clear.

Tindlo also integrates with Google Calendar, so the dates in your dependency register can sit alongside the rest of your team's schedule rather than in a separate system.

If you want to see how that kind of shared view works in practice, you can explore Tindlo here.

A Quick Reference: The Dependency Register Template

Here's the full template in one place. Copy it into a spreadsheet or shared doc before your next kickoff.

Add one optional column if your project is complex:

The Habit Worth Building

The dependency register isn't a heavy process. It's a habit: before work begins, name what you need from others, name what others need from you, put a person on each item, and put a date on each item.

That's it. Four things. Done at kickoff, reviewed weekly, and kept somewhere visible.

The projects that run smoothly across teams aren't the ones with the fewest dependencies. They're the ones where the dependencies were named early, owned clearly, and tracked honestly. This worksheet gives you a simple way to do exactly that.

Get started with Tindlo