Ten Priorities, One Team

Nobody sits down and decides that one team will pursue ten things at once. The list arrives at ten one addition at a time, each made by somebody reasonable, in a meeting where the cost is not visible and the people who absorb it are not present. A quarter opens with four. Then the security finding lands, and the customer commitment, and the thing an executive saw at a conference, and by March there are ten and no record of when the fifth arrived or what it displaced.

Saying yes to an item is close to free. It costs a sentence, it shortens the meeting, and in the moment it is indistinguishable from being helpful. Saying no costs something specific to a specific person who is sitting there and will remember. That asymmetry is the whole mechanism and it needs nobody to be cowardly or political. It only needs the two answers to have different prices, and people to notice prices.

I have handled this badly for most of my career, mostly by trying to rank the list harder and by absorbing the conflict myself when the ranking did not hold. Ranking is not the intervention. Here is the sentence the rest of this is about: ten priorities is an arithmetic problem wearing the costume of a prioritization problem, and the useful work is not solving it privately but making the arithmetic visible to somebody with the authority to cut.

How long a thing takes is how much is in flight, divided by how fast you finish. John Little proved in 1961 that in a stable system the average number of items in it equals the arrival rate times the average time each spends there. Rearranged: time in the system is work in flight divided by throughput. Start ten things instead of four with the same team and the average item takes roughly two and a half times as long to arrive, with no change in effort anywhere. It is an identity about long-run averages, so it explains nothing about why. It is also not arguable, which is rare here.

The last slice of a person is the most expensive one to sell. Kingman published an approximation for waiting time in a single-server queue in the same year, and its first term is utilization divided by one minus utilization. Set the variability term aside and, at half loaded, the wait is about one service time; at nine tenths loaded, about nine. That is a heavy-traffic approximation for one server, and a team is neither, so take the shape rather than the number: the cost of the last slice of somebody's time is not linear, and a plan allocating every hour priced it as though it were.

The switching cost is real, and it is quoted far more confidently than it was measured. Psychology has measured switch costs since Rogers and Monsell in 1995, where people classify letters and digits and alternate every few trials. The costs are consistent and they reproduce. They are also a few hundred milliseconds long, in a lab, on tasks with no state to reload, and the percentage-lost-per-project figures in planning decks trace back to that literature nowhere I can find. The engineering cost is not the switch anyway. It is the reload.

Ten workstreams at ten percent each is a plan with no queue in it. The table looks reasonable because the columns add up to a hundred. What the columns do not contain is the branch waiting on a review, the change waiting on an environment, the decision waiting on a person who is booked into a different workstream this week. Donald Reinertsen's 2009 book on product development flow argues that an item typically spends far longer waiting than being worked on, and that nobody manages the waiting because, unlike a warehouse of parts, the inventory is invisible. Only one of those two durations is on the plan.

A stack rank with no cut line is a decision about order and nothing else. If all ten items are still on the list afterward the team still starts all ten, because people who want to be useful do not leave the tenth item untouched simply because it is tenth. Somebody picks it up in a gap. Ordering becomes a decision only when something falls off the bottom, and the line, not the order, is the part people resist.

The version I have landed on is to draw the line myself, in the wrong place, on purpose. A wrong line is far more useful than no line, because it turns a vague sense of overload into a specific objection from a named person who has to say which item they would restore and what they would drop for it. I have never had a good conversation about capacity in the abstract. I have had several about one line through one list.

The other half is keeping the list a fixed length, which is where I am worst. The line gets drawn, the quarter starts, and by week three two items have quietly returned because each was individually small. If the list is six, a new proposal ends with a name against a removal, or the list is seven and everybody knows it is seven. What cannot happen is it growing without anybody able to say when.

The maintenance floor does not shrink because you are busy. Certificates expire on their own schedule, versions leave support on somebody else's calendar, and test suites rot at a rate set by how fast the code around them moves. This is the part of the budget that gets deferred first, because deferring it costs nothing this month. It does not remove the work. It moves the work to a date chosen by a vendor or an auditor rather than by you, which is the most expensive way to schedule anything.

The real capacity is usually one person, and it is not the average one. The constraint is rarely the team's throughput in aggregate. It is the one engineer who reviews anything touching the payments path, or the one who knows the schema well enough to say whether a migration is safe. Ten workstreams that each need two hours a week of the same person are not ten workstreams. They are one calendar, and that calendar is the single server the queueing approximation was actually written about.

The question that moves is not which of these is most important but which of these gets materially worse if it waits a quarter. That is a factual question about the work rather than a status question about the sponsor, and people answer it accurately, including about their own item, because conceding it costs them nothing. They are not conceding that their thing matters less. They are saying it will be worth the same in April, which is usually true and much easier to say.

The honest limit of the question is that it systematically underweights the work whose decay is real but has no date. Knowledge concentration, test coverage, the slow rise in the cost of every change: each gets worse continuously and none gets worse by Thursday, so they lose every quarterly argument they enter. Decay is a good tiebreaker that quietly discriminates against the compounding kind, and somebody has to speak for that work knowing it will sound like a preference rather than a deadline.

Write the displacement, not the plan. The useful artifact is one line per addition: to take this on, these two stop, and here is the date each would otherwise have landed. It is not a negotiating position and should not read as one. It is the arithmetic, written when the item is proposed rather than reconstructed at the deadline, where it is indistinguishable from an excuse.

Say it in the room where the item was added. A manager who absorbs the conflict privately is protecting a group of people from a decision they are entitled to be part of, and will be blamed anyway when the date moves. I have taken the quiet route many times. It buys one comfortable meeting and sells a bad quarter, and the people who added the item never learn what it cost, so they add the next one on the same information.

Then the deliverable is an order of lateness. If everything is going to be attempted, say now which items will be late, in what order, and roughly by how much. Being late is survivable and routine. Discovering it in the last week is what costs a team its standing, because it removes every option the business had for responding, and it discounts the next estimate that team gives.

Sequence the work rather than share the team. If ten things genuinely have to happen, they can still happen one after another. Same throughput, less in flight, and the first items land far earlier than if all ten started together, which is the whole content of the arithmetic above. The objection is that sequencing makes the ordering argument unavoidable, and that is not an objection. That is the argument surfacing where it belongs.

Say out loud what is being borrowed. An attempt at all ten is funded from somewhere, and the somewhere is the floor: upgrades slip, reviews get shallower, the flaky test is muted rather than fixed. That is a loan with a repayment date nobody set. I would still take it occasionally, and not without writing down what was borrowed, because the next quarter gets planned as though the borrowing never happened.

A team pointed at exactly one thing is fragile to that thing. If it is canceled, or blocked on a vendor for three weeks, the whole team stalls at once with nothing else in flight to absorb it. Some parallel work is not waste, it is slack, and slack is what a system with variable arrivals uses to stay stable. The same approximation that punishes full allocation says a queue with nowhere to put a surprise is the one that falls over when one arrives.

There is a people version too. Two quarters on one effort costs the variety that keeps good engineers interested, and the item most likely to fall below a strict line is the small cheap one whose payoff lands in somebody else's work rather than yours, which is often the best thing available and always the worst at defending itself in a meeting.

The place I have to concede outright is teams whose work is genuinely independent. Separate services, separate consumers, no shared reviewer, no shared environment: those are separate queues rather than one queue with ten arrivals, and most of the arithmetic above weakens considerably. I have seen teams like that carry five or six efforts without much penalty, and if that is yours, this piece is largely wrong about you. I do not think it describes many, and I would check the shared-reviewer claim before believing it about my own.

So the claim I am left with is narrower than the one I started with. Not that focus is a virtue, which I do not particularly believe and which is unfalsifiable anyway. Only that there is a difference between a plan a team can execute and a plan a team can divide among itself, and that ten items across one team with one review queue is reliably the second kind.

I should be honest about how well any of this works. I have never once had a list cut because I presented the arithmetic clearly. The times it worked, a visible date was about to be missed and somebody senior wanted a defensible account of why, and the arithmetic was there ready to be that account. So it is not a way of persuading anybody. It is a way of having the right thing already written down on the day somebody becomes willing to read it.

What stays with me is that the plan is the only place where ten things happen at the same time. On the plan there are ten columns at ten percent each, each one tidy, each one adding up. On the floor there is one review queue, one person who knows the schema, one environment that has to be booked. A plan with no queue in it is a drawing of a team where nobody is ever waiting for anybody, and I have not worked on that team.