The work that goes late is rarely the work that is hard. It is the work that is waiting on someone else. A card sits in Doing looking perfectly healthy, but it cannot actually move because it needs a file from a client, sign-off from a manager, or a piece another teammate has not finished yet. That is a dependency, and on a busy board it is the quietest way a deadline slips. The good news: a kanban board is unusually good at surfacing dependencies once you decide to make them visible. Here is how to do that without turning your board into a tangle of arrows.
What a dependency actually is
Strip away the jargon and a dependency is just this: one piece of work cannot finish until another one does. The design cannot start until the copy is approved. The invoice cannot go out until the client confirms the scope. The feature cannot ship until someone reviews the code. In every case a card is only partly in your hands — part of it lives with another person, another team, or an outside party you do not control.
That last part is what makes dependencies different from ordinary tasks. When work is fully yours, effort moves it forward. When work depends on someone else, effort does nothing; only their action unsticks it. Treating those two situations the same way is exactly how a card ends up sitting untouched for a week while everyone assumes someone else is handling it.
Why dependencies quietly wreck your flow
Blocked cards at least announce themselves — something has visibly gone wrong. Dependencies are sneakier because the card often still looks like it is being worked on. It is in Doing. It has an owner. Nothing is flagged. But no real progress is possible, and every day it sits there it is aging while the rest of the board flows around it.
Left unmanaged, dependencies do three things. They inflate how long work really takes, because most of that time is spent waiting rather than working — the gap between effort and elapsed time that shows up when you look at how much time your work spends waiting versus actually moving. They create false bottlenecks, where one person looks slow when they are simply stuck waiting on a handoff. And they cluster at the worst moment: several cards all come due, all needing the same busy person, all at once.
Make the dependency visible on the card
The first fix costs nothing. The moment a card depends on someone else, write it on the card in plain language: “Waiting on Priya for logo files” or “Needs client sign-off before build.” Name the person or party, name the thing you need, and if you can, note the date you expect it. A dependency written down is a dependency someone can chase. A dependency living only in one person’s head is a dependency that gets forgotten until it is late.
This tiny habit also settles the most common team argument: “I thought you were following up on that.” When the card says exactly who owes what, there is no confusion about whose move it is.
Ways to show dependencies on the board
Writing it on the card is the baseline. To manage dependencies at a glance, give them a visible home on the board. A few options, from simplest to most structured:
- A waiting marker. Add a tag, colored dot, or label that means “this card is waiting on someone.” One glance tells you which cards are stalled, so nobody mistakes a waiting card for one that is being actively worked.
- A dedicated Waiting column. Put a column between Doing and Done for work that is out of your hands. Moving a card there is honest — it admits the card is parked — and it stops parked work from clogging your Doing limit and hiding your true capacity.
- Linked or related cards. When two of your own tasks depend on each other, note the link on both (“blocks card #14” / “blocked by card #9”) so finishing the first prompts an immediate pull of the second.
- A swimlane for handoffs. If a lot of your work crosses to another team, a dedicated lane keeps those cross-team items together and easy to review, much like using swimlanes to organize a busy board so nothing gets lost.
You do not need all of these. Pick the lightest one that makes your waiting work impossible to miss, and resist the urge to draw a spiderweb of arrows between every card — that is more diagram than tool.
Reduce the dependencies you can
Making dependencies visible is management. The bigger win is having fewer of them. Not every dependency is real; many are just how the work happened to be sliced. Before you accept one, ask whether you can design it away:
Split the card. Often only part of a task needs the other person. Pull the self-contained part forward and do it now; leave only the truly dependent slice waiting. A card that is 80% doable today should not sit idle because of the last 20%.
Ask earlier. Most waiting is created at the last minute — you reach the handoff, then request what you need, then wait. If you can see the dependency coming, request it while you work on something else so the answer arrives before you need it. Lining up inputs before they are needed is exactly what a good replenishment routine that refills the board without overloading the team is for.
Batch the handoffs. If one person approves everything, do not interrupt them five times a day. Group the requests so they can clear several at once. It respects their time and gets your cards moving in a single pass.
Manage the rest with a simple routine
Some dependencies are unavoidable, and those just need tending. Build two small habits. First, at your daily check-in, look specifically at waiting cards and ask one question of each: what would unstick this today, and who has to do it? That keeps handoffs from silently aging. Second, escalate early rather than late. If a card has been waiting past the date you expected, that is not the moment to keep quietly hoping — it is the moment to nudge, reassign, or raise it. A dependency chased on day two is a conversation; the same dependency chased on day ten is a fire.
It also helps to watch where waiting work piles up. If the same handoff stalls cards over and over, you have found a structural bottleneck worth fixing at the source rather than a one-off delay — and fixing the source is what stops the same cards from turning into blocked work week after week.
The takeaway
Dependencies are not a flaw in your process; they are a normal fact of work that involves other people. What hurts is leaving them invisible. So do the small things that add up: write every dependency on its card, give waiting work a visible home on the board, split and sequence tasks so fewer cards need someone else, and check your handoffs every day so nothing ages in silence. Do that, and the work waiting on other people stops being the thing that quietly sinks your week — it becomes just another set of cards you can see, and a board everyone can read at a glance is what makes that possible.