Cross-Column Dependencies: Reading Your Board for Hidden Waits
Most task boards look orderly at a glance. Cards sit in tidy columns, owners are named, and due dates are visible. The trouble usually hides between the cards. A design review can be finished and still be waiting on legal copy, and a launch checklist can look healthy while every item quietly depends on one engineer's sign-off. Cross-column dependencies are the connections that determine when work actually moves, and they are rarely written down. This article describes a way to make them visible using ordinary board practices, so that a busy team can see what is waiting on what before a deadline makes the answer obvious.
Why column status hides the real bottleneck
A column tells you the stage a card is in, not what the card is waiting for. A card in 'In Progress' might be actively worked on, or it might be parked until a reviewer responds, a vendor replies, or a decision is made in a meeting nobody scheduled. Two cards with identical status can have completely different risk profiles. The board treats them as equal because it only records position, and position is a poor proxy for movement.
This gap matters most for founders and small teams, where one person often sits upstream of many tasks. When the same name appears as the missing input on five different cards, the board looks like five separate problems. In reality it is one bottleneck spread across the board. Recognizing that pattern is the first step toward fixing it.
A method for mapping what waits on what
Start with a single pass through your active cards. For each one, write down a short phrase describing what must happen before the card can move forward. Keep the phrase concrete: 'needs final pricing from finance' is useful, while 'waiting' is not. If a card needs nothing external, mark it as unblocked. This takes perhaps fifteen minutes for a board of thirty cards and often reveals more than a status meeting does.
Next, group the phrases. You will usually find that a handful of people, decisions, or external parties account for most of the waits. Note how many cards each one controls. A blocker that gates four cards deserves more attention than one that gates a single low-stakes task, even if both carry the same priority label. Some teams keep this as a simple tally at the top of the board, updated weekly.
Questions to ask about each blocker
Once you know what is waiting, ask a small set of questions. Who is the person or group that must act, and do they know they are the gate? When was the input first requested, and has it been acknowledged? If the blocker is a decision, is there an explicit owner with the authority to make it, or does everyone assume someone else will? Asking these questions often shows that a blocker is not a capacity problem at all, but an ambiguity problem: nobody has agreed who decides.
Also ask what happens if the blocker stays in place for another week. If the answer is 'nothing much,' the card can wait without harm and you should stop spending attention on it. If the answer involves a launch date, a customer commitment, or another team's schedule, the blocker moves up the list. This keeps attention proportional to consequence rather than to how loudly the card is discussed.
A checklist for a weekly dependency review
Run this review once a week, ideally before you set priorities for the coming days. First, list every card that has an external or cross-team input pending. Second, identify the three most-shared blockers and confirm each has a named owner. Third, for any blocker older than one review cycle, decide whether to escalate, reassign, or remove the dependency by changing the plan. Fourth, check whether any cards have been waiting so long that the original task no longer matches the need, and rewrite or close them.
Keep the review short, under twenty minutes for most teams. Record the outcome in plain language on the board or in a shared note, so the next review starts from what was decided rather than from memory. Over several weeks, the record itself becomes useful evidence: it shows which people or steps repeatedly gate progress, which is information for planning hiring, delegation, or process changes rather than for blaming individuals.
Keeping the map honest over time
A dependency map decays quickly if no one maintains it. Cards get unblocked and the note stays; new waits appear and go unrecorded. Make updating the blocker phrase part of moving a card between columns, so the map changes with the work rather than in a separate exercise. When a blocker clears, note the date it cleared. Over time, the gap between when a blocker appeared and when it was resolved becomes a useful measure of how responsive your team is to its own dependencies.
The goal is not a perfect diagram. It is a shared, current answer to the question every busy team eventually asks: what, specifically, are we waiting on? A board that can answer that question in a few seconds is far more useful than one that merely shows where cards sit.