Two directors want different things from me and I have to pick.

What to do when two directors want different things and you have to pick

Two thousand and five. A small company called Monitor One Ten has just raised serious money on the strength of an idea that, at the time, sounds like science fiction. A real-time natural language processing engine that will analyse the entire public web and surface intelligence from it. This is years before anyone is using the phrase "AI" to describe that kind of thing.

From day one, Monitor One Ten has two visions of what it is building.

The technology leadership wants to build the engine — the deep infrastructure play, the thing that would be valuable whatever you did with it. The business leadership wants something different. A curated intelligence product. Effectively a Bloomberg terminal for web content. Same data. Different product.

Because the company has raised easily and has plenty of runway, nobody is forced to choose. So nobody does. The two visions run in parallel for three years, each team building the version they want, each one consuming cash, neither one shipping a finished product.

In two thousand and eight, both are dead.

Monitor One Ten's founders wrote a post-mortem afterwards. It's one of the most honest documents in the venture failure canon. And the founders name, plainly, the single cause of death: the refusal to decide. They didn't die because they picked the wrong strategy. They died because they picked both.

So let's go to the office and work through it.

"Two directors want different things from me and I have to pick."

The feeling is cornered.

You're being asked to arbitrate a disagreement that wasn't yours to start, and will probably outlast whichever way you go. The instinct is to escalate, to ask for clarity from above, to get the two directors in a room together. Sometimes that works. More often it just moves the argument sideways without resolving it.

First work out whether it is about status or capacity

Before anything else, work out which of two problems you're actually looking at. Because they look identical from the outside, and they need opposite moves.

When the clash is really a status battle

Choice one: it's about status. Two senior people using your workload as a proxy for a battle that has nothing to do with you. In that case the move is counter-intuitive. Email them both and say you will proceed with Director A's request by default unless they reply with an agreed alternative. You're not picking a side. You're handing the disagreement back to the people who own it. Choice architecture beats arbitration when the choice wasn't yours to make in the first place.

When both bids are legitimate

Choice two: it's about capacity. Both directors genuinely need the work done and neither is wrong to ask. In that case the move is a trade. Deliver Director A's priority now, and get Director B's written commitment that their project runs next quarter. People concede far more easily when the cost of conceding is in the future. The promise costs Director B nothing today, and you've bought yourself the thing you needed — which was time.

Working out which choice you're facing is the first move. Everything after it depends on getting that right.

How to make the case about economics, not politics

Three tools, in sequence. The through-line is simple: shift the argument from politics to economics.

Put a pound figure on every week of delay

The first is

Cost of Delay.

Don Reinertsen formalised Cost of Delay in The Principles of Product Development Flow in two thousand and nine, refining work he'd been doing through the nineteen-nineties on lean product development.

The reason the tool exists is that arguments about priority tend to be circular. Whose project matters more is a question that doesn't terminate — there's always another reason on either side, another stakeholder to invoke, another future scenario to point at.

The unique insight is the conversion. Every week a project is delayed has a real financial cost; if you can express that cost in pounds per week, you've converted an argument about priority into an argument about money. Money arguments end. Priority arguments don't.

What you get is the directors' real position, on paper, in numbers they put there themselves. The push-back itself tells you which choice you're facing — capacity directors will engage with the numbers; status directors won't.

So. How to run it.

Frame. A short note to both directors. We need to sequence these projects, and the cleanest way is to put a pound figure per week of delay on each. Not an estimate; a working figure.

Score. Each director returns a number. Not a range, a number. The discipline is the point.

Compare. Set the two figures side by side. Either the difference is large enough to settle the sequence, or it isn't. If it isn't, the next tool picks up.

Let the maths sequence the work for you

The second is

WSJF — Weighted Shortest Job First.

Reinertsen developed WSJF as a refinement of Cost of Delay; it was later adopted as the core prioritisation mechanism in the Scaled Agile Framework, where most managers encounter WSJF now.

The reason the tool exists is that Cost of Delay alone doesn't sequence the work. A high-value project that takes six months and a high-value project that takes two weeks have different opportunity costs, and the comparison isn't intuitive.

The unique insight is the formula. Cost of delay divided by job duration. A high-value short job scores higher than a high-value long one — which is usually the right answer, but rarely the obvious one.

What you get is a sequence that falls out of the maths. No winner; no loser; just a list. The political content of the disagreement evaporates because the directors aren't being asked which they prefer — they're being shown what their own numbers produce.

So. How to run it.

Input. The Cost of Delay figures from the first tool. Plus a duration estimate for each project — weeks, not gut-feel.

Divide. Run the division. The higher number runs first.

Read. Show both directors the working. The arithmetic is what's making the call, not you.

Force a clean order through pairwise choices

The third is

Stack Ranking.

Stack Ranking has a grim reputation when it's applied to people. Jack Welch's GE used it to fire the bottom ten per cent of employees each year through the nineteen-eighties and nineteen-nineties, and the practice spread disastrously through corporate America. That is not what we're doing here. We're stack ranking work items, not people.

The mechanics borrow from pairwise comparison in operations research — specifically the Analytic Hierarchy Process that Thomas Saaty formalised in the nineteen-seventies.

The reason the tool exists is the failure case for the previous two. If the directors refuse to engage with Cost of Delay — because maths removes the thing they were actually enjoying — the conversation needs a different forcing function.

The unique insight is the pairwise comparison. Don't ask which of five projects matters most. Ask which of two matters more, then the next two, then the next. Pairwise judgements are decisions people will make; rankings of long lists are decisions they'll dodge.

What you get is a sequence the directors built themselves, comparison by comparison. Someone has to be second; someone has to be fifth. No ties.

So. How to run it.

List. The projects on cards, one per card. All visible.

Pair. Two cards at a time. The directors choose. No ties. Move to the next pair.

Sequence. The accumulated wins build the order. By the end, every project has a position.

The version of this that fails is letting the room argue each pair instead of decide. The discipline is choose, move on. The argument lives at the end, looking at the full sequence — not at each pair.

That's the toolkit. One more story before we close. A few years after MonitorOneTen died, a different company faced a different version of the same problem.

A precedent: the choice that keeps the work coherent

Decide.com, early twenty-tens.

A small team had built a price prediction engine for consumer goods. Type in the product you were thinking of buying, and Decide would tell you whether to buy now or wait, based on its model of how the price was likely to move. The experience depended on showing prices from multiple retailers side by side. Including Amazon.

Then a cease-and-desist letter arrived. Amazon's legal department wanted Decide to stop displaying Amazon's prices.

The team had to choose. On one side was Amazon — the largest and most aggressive commercial entity on the internet, threatening litigation that could eat the company's runway in months. On the other side was the product. A comparison engine that couldn't compare with the dominant retailer in its category wasn't really a comparison engine at all. It was a worse version of itself.

They refused to comply. They kept showing Amazon's prices.

The legal fight was expensive. The company spent more time on it than it should have. But the product remained the product. Users kept coming. And eBay acquired Decide a few years later for a substantial sum — in part because what they were buying was a product that had stayed coherent under pressure.

MonitorOneTen died because it couldn't choose between two versions of itself. Decide could have died by picking the safer version of itself. The question, when two directors want different things from you, isn't which director is more powerful. It's which choice keeps the work itself coherent — and which choice makes you a slightly worse version of the thing you were hired to be.

So. The question from this Playbook.

Who in your next meeting actually has the authority to decide?

And does everyone else in the room know it — or are you about to hold a discussion that decides nothing?