Weekly Priorities Built Around Dependencies: Sequencing the Week by What Unblocks Others
Most weekly priority lists are built by sorting tasks on urgency or by who shouted loudest. A different approach starts from a simpler question: which pieces of work, if they stayed unfinished, would stall other people? Those dependency-heavy items deserve a place near the top of the week, even when they are not the most exciting or the most visibly overdue. This article walks through a method for finding them, a way to order them, and a short checklist founders and busy teams can use before Monday's first standup.
Why urgency-based lists keep failing busy teams
Urgency is a poor proxy for importance because it measures noise, not consequences. A request from a stakeholder who checks in daily feels urgent. A draft that a designer needs before she can start her own work often feels routine, even though it gates three other people's week. When priorities are chosen by volume of pressure, the blocking work quietly gets pushed to Thursday, and by Thursday the team is improvising around its absence.
A dependency-first view corrects for this. It asks what each candidate task unlocks. A task that unlocks two other tasks has a multiplier effect that a task standing alone does not. Choosing priorities this way does not mean ignoring deadlines or customer needs. It means recognizing that a deadline on a blocking item is the earliest real deadline on the whole chain.
Finding the blocking work in your current backlog
Start by pulling up everything in progress or queued for the coming week. For each item, write one line answering: who is waiting on this, and what do they do once it is done? If the honest answer is nobody, the item may still matter, but it is probably not a weekly priority. If the answer names a person or a downstream task, mark it as a dependency.
Next, look for items that appear as blockers on more than one card or in more than one conversation. A repeated name in the waiting-on column is a strong signal. Founders often find that a single decision, such as approving copy or confirming a vendor scope, sits upstream of most of the week. These are candidates for the top of the list because clearing them releases work that would otherwise sit idle.
Finally, check whether any dependency is stale. A blocker that has been waiting for a week is not just a task; it is a sign that the team has not agreed on who owns the decision. Naming that owner is often more valuable than doing the underlying work yourself.
Ordering dependencies without creating a new queue
Once you have a short list of blocking items, resist the urge to rank all of them. Pick at most three weekly priorities drawn from the dependency set, and order them by the size of the unblocked work rather than by how interesting they are. A small decision that releases a week of engineering effort outranks a large document that only one person will read.
Watch for the trap of creating a second, hidden backlog. If your dependency list grows longer than your capacity, the list itself becomes a source of anxiety and goes unread. A useful limit is to keep the dependency view to the items your priorities would unblock, and let everything else stay where it already lives.
Also consider the timing of handoffs. A blocking task finished on Wednesday afternoon may release nothing until Thursday, because the receiving person is in meetings or on a different schedule. Scheduling the blocker earlier in the week, or agreeing on a same-day handoff, can recover a day that a priority list alone would not show.
A short checklist for Monday planning
Before committing to the week, work through these questions in order. First, list every item that someone else is waiting on. Second, for each one, name the person or task it unblocks. Third, identify which of those unblocks affect more than one downstream item. Fourth, choose no more than three priorities from that subset, ordered by the amount of waiting work each releases. Fifth, confirm that each chosen priority has a named owner and a realistic completion point, not just a target day. Sixth, note any blocker that has no clear owner and assign that decision before anything else.
This method will not eliminate surprises, and it does not replace judgment about customers, quality, or commitments you have already made. What it does is make the cost of delay visible in terms of other people's work. When a team can see that one unfinished approval is holding up five tasks, the conversation about priorities changes from which task matters most to which delay the team can afford. That conversation is usually shorter, and it tends to produce a week that finishes with fewer items stranded in the middle.