How to prioritize between two teams competing for the same engineers, using OKR logic

Two teams asking for the same people is an OKR problem before it is a staffing problem: both teams are usually right that their work matters, and the decision only gets easier once you price what each one costs to delay. Google's OKR playbook is blunt about what to do when a team cannot staff a committed goal: "Escalating in this (common) situation is not only okay, it is required," because escalation "allows the team's management to develop options and resolve conflicts."

The pricing tool is cost of delay. Black Swan Farming's cost of delay explainer describes a single feature at Maersk Line whose cost of delay was more than $200,000 per week, so the 38 weeks it spent waiting in queues cost nearly $8m in lost revenue. That is one case from one company, chosen because it is dramatic, and your numbers will be smaller and rougher. It still makes the point that matters here: the cost of waiting is real money, and a staffing call made without estimating it is made on volume and seniority instead.

The worked example below follows one fictional company through the whole decision. Every number in it is illustrative.

What does a conflict over the same engineers look like?

Tradesloop is a fictional scheduling and invoicing app for plumbing and electrical businesses, with about 1,900 paying accounts at an average of €150 a month. It has two native mobile engineers, and two teams want both of them for most of the quarter.

The company OKR for the quarter has one objective, "Trades businesses run every job, from booking to paid, in Tradesloop," and three key results:

• KR A: Jobs paid within 3 days of completion rise from 52 to 62 percent.
• KR B: Monthly account churn falls from 2.4 to 1.8 percent.
• KR C: Technicians active in the mobile app each week, per paying account, rise from 3.1 to 3.5.

The Payments team wants both mobile engineers for 6 weeks to build tap-to-pay, so a technician can take a card payment on their phone at the door. The Scheduling team wants both for 8 weeks to rebuild offline mode, because technicians working in basements lose signal and their job notes and photos disappear. Each team has put its request at the top of its plan. Neither is wrong.

Step 1: Which company key result does each request move?

Write one row per request, and make each team state its claimed contribution in the key result's own units, with the evidence behind it. A request that cannot name a company key result is not part of this decision. Google's re:Work guide to OKRs gives the two questions to ask of every team priority: "Do the team priorities connect to any of the organizational key results?" and "Do the team priorities make it more likely that the organization will successfully achieve the organizational OKRs?"

Request	Company KR	Claimed contribution this quarter	Evidence	Confidence
Tap-to-pay (Payments)	KR A, paid within 3 days	+5 points (52 to 57 percent) if a quarter of accounts adopt it	40 pilot accounts using a card-reader workaround paid 71 percent of jobs within 3 days	Medium: the pilot accounts volunteered, so they may be keener than average
Offline mode (Scheduling)	KR B, churn; KR C, weekly technicians	Churn down about 0.15 points; KR C up modestly	60 accounts a month file 2 or more data-loss reports, and they churn at 7.5 percent a month against 2.4 percent overall	Medium: the churn link is correlation, but the exit surveys name lost notes

The table already removes one common argument. The Payments team's request moves a bigger slice of its key result, so on "contribution to OKRs" alone it looks stronger. The next step shows why that is not enough.

Step 2: What does waiting a quarter cost each one?

The question is not which initiative is more valuable. It is what the company loses for every week each one does not exist. Black Swan Farming's definition is the useful one: cost of delay "combines urgency and value," which people tend to blur together.

Tap-to-pay. Tradesloop earns a margin on card payments it processes. At the pilot's adoption rate, finance estimates about €2,000 a week of payment margin once tap-to-pay is live. If it waits a quarter, most of that is deferred rather than lost: the accounts will still be there next quarter, and KR A simply does not move yet.

Offline mode. About 60 accounts a month hit repeated data loss and churn 5.1 points faster than average, which is roughly 3 extra cancellations a month. At €150 a month and an average remaining lifetime of about 42 months (the inverse of 2.4 percent churn), each lost account is worth about €6,250. Three a month is about €18,750 a month, or roughly €4,300 a week. None of it comes back: a churned plumber does not return when offline mode ships.

Two facts decide most of this. Offline mode's delay cost is about twice tap-to-pay's, and it is permanent rather than deferred. When the do-nothing costs are close, the permanent one should still win, because a deferred loss can be recovered next quarter and a permanent one cannot.

Step 3: Can you shrink or sequence the work so both teams move?

Before choosing, test the three shapes the decision can take. Black Swan Farming's CD3 method (cost of delay divided by duration) is built for exactly this: "a prioritisation/scheduling method that maximises the value delivered in a given time period when you have limited capacity." Two questions shape the options.

First, can either request get smaller? The Scheduling team checks its data-loss reports and finds 85 percent involve job notes and photos, not the calendar or invoices. Offline notes and photos alone takes 5 weeks instead of 8, and removes about €3,650 of the €4,300 weekly cost. That is a CD3 of 730 (3,650 divided by 5) against tap-to-pay's 333 (2,000 divided by 6).

Second, what does each ordering cost? Count the delay cost each initiative runs up until it ships:

Option	Offline notes ships	Tap-to-pay ships	Delay cost until both ship
Split the engineers, one each	Week 10	Week 12	€36,500 + €24,000 = €60,500
Tap-to-pay first, then offline	Week 11	Week 6	€40,150 + €12,000 = €52,150
Offline notes first, then tap-to-pay	Week 5	Week 11	€18,250 + €22,000 = €40,250

The split looks fair and costs the most, and it flatters itself: it assumes one engineer works exactly half as fast as two, with no handover or review cost. Sequencing offline notes first is about €20,000 cheaper than splitting and €12,000 cheaper than the reverse order. It also means the Payments team does not lose its quarter. It loses its first five weeks.

Step 4: Who makes the call, and how?

The decision belongs to the person who owns all three company key results, here the head of product, not to the two team leads negotiating in a hallway. Each lead is the best advocate for their own key result, which is exactly why neither should settle the trade-off. The cascading vs aligning OKRs guide describes the leadership review that is supposed to catch collisions like this at planning time; when it misses one, this is the late version of the same review.

Tradesloop's decision, written in one paragraph:

Both mobile engineers join Scheduling for weeks 1 to 5 to ship offline job notes and photos. They move to Payments at the end of week 5 regardless of what is left, and Payments ships tap-to-pay by week 11. We are choosing this order because offline data loss costs us about €4,300 a week in accounts we do not get back, while tap-to-pay's margin is mostly deferred. We will revisit at the week 4 monthly review if data-loss reports among beta accounts have not fallen by at least half.

When estimates are this rough, two tie-breakers help, in this order. A committed OKR outranks an aspirational one: Google's playbook says teams with committed OKRs "are expected to rearrange their other priorities to ensure an on-schedule 1.0 delivery." And evidence outranks conviction: the request backed by data from real accounts beats the one backed by a strong opinion, even a senior one.

Step 5: How do you rewrite the losing team's OKRs?

Rewrite the Payments team's quarter as a smaller outcome, not a cancelled one. Leaving its original targets in place guarantees a grade near 0.2 that says nothing about how well the team worked; how to grade OKRs covers why a grade like that teaches nobody anything. Cancelling the objective is worse, because the team spends the quarter on whatever is lying around.

	Payments team, before	Payments team, after
Objective	Technicians get paid at the door	Technicians get paid at the door (unchanged)
KR1	Jobs paid within 3 days: 52 to 60 percent	Jobs paid within 3 days: 52 to 55 percent, through payment links sent automatically at job completion (web engineers only)
KR2	30 percent of active accounts take a card payment in Tradesloop	120 accounts take a tap-to-pay payment by quarter end (launch in week 11)
KR3	none	300 accounts join the tap-to-pay waitlist by week 10, to size next quarter's rollout

The objective stays, because the direction is still right. KR1 drops to what the team can reach with the people it has, and a payment link is a real lever on the same number. KR3 is new: it produces evidence the team will need next quarter, and it gives the five weeks without mobile engineers a measurable job.

The Scheduling team's OKRs change too, and this is the part most decisions skip. Google's playbook says cross-team OKRs "should include all the groups who must materially participate," with each group's commitment appearing "explicitly in each such group's OKRs." So the handover becomes a committed key result on the Scheduling team's list: offline notes and photos live, and both mobile engineers working on Payments, by the end of week 5. Its aspirational key results become data-loss reports per 1,000 active technicians falling from 21 to 5, and accounts with 2 or more data-loss reports in a month falling from 60 to 15.

Step 6: What do you tell each team?

Send both messages the same day, in writing, before either team hears it secondhand. The one to the team that lost carries more weight, so write it first.

To the Payments team:

Tap-to-pay is going ahead this quarter, starting in week 6, not week 1. Both mobile engineers go to offline notes for the first five weeks, then move to you at the end of week 5 whatever state offline is in. The reason is cost: data loss is costing us about €4,300 a week in accounts that cancel and do not come back, and most of tap-to-pay's value moves to later rather than disappearing. It is not a judgement on the pilot, which is the best evidence anyone brought to this decision. Your revised OKRs are attached: payment links for weeks 1 to 5, tap-to-pay live in week 11, and a waitlist target that sizes next quarter. If data-loss reports among offline beta accounts have not halved by the week 4 monthly review, I will reopen the decision, and the handover date is a committed key result on Scheduling's OKRs, not a hope. If you still disagree, tell me now; if you can disagree and commit, I need that from you by Friday.

To the Scheduling team:

You have both mobile engineers for weeks 1 to 5, scoped to offline job notes and photos only. Calendar and invoice sync stay out of scope this quarter. At the end of week 5 both engineers move to Payments whatever is left, and that handover is now a committed key result on your list. I will check data-loss reports among beta accounts at the week 4 monthly review; if they have not fallen by half, the decision reopens. Payments gave up its first five weeks for this, so please keep them in your weekly check-in doc.

The "disagree and commit" line comes from Jeff Bezos's 2016 letter to Amazon shareholders, where he describes asking: "Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?" It works because it asks for commitment without demanding agreement. For the shape of a decline that names what the request was weighed against, the guide to saying no to stakeholders covers the single-requester version of this message.

Are cost of delay estimates too rough to decide on?

They are rough, and that is the strongest objection to this whole procedure. Tradesloop's €4,300 rests on a churn correlation and a lifetime estimate; either could be off by half. A team that dislikes the outcome can always argue the inputs.

Two answers. Rough estimates still beat the usual alternative, which is the loudest or most senior advocate winning without anyone writing down why. Black Swan Farming makes the same point about CD3: it "works perfectly well enough with noisy inputs on the denominator," and the value of the exercise is that assumptions become visible and arguable. And the reversal condition limits the damage of a wrong estimate to four weeks. Bezos's letter puts the general rule in numbers: "most decisions should probably be made with somewhere around 70% of the information you wish you had." Waiting for a clean churn model would have cost Tradesloop more accounts than the model would have saved.

The procedure has a real limit too. It assumes both requests trace to company key results. If one of them does not (a rewrite an architect wants, a feature a large customer asked for), the comparison is between a priced outcome and an unpriced one. Send the unpriced one back to be traced to a key result first, which is usually the fastest way to find out whether it belonged on the OKRs at all. For building that trace, see objectives, not tasks and the baseline method in how to write good OKRs.

Where can you practise resolving OKR conflicts?

How to Design OKRs is a one-week Builders Camp bootcamp with 6 microlessons, part of the Product Leadership Track. Its published topics include alignment across teams (translating company goals into team OKRs without copy-paste or conflicts) and cadence and scoring. Its practical challenge includes a resource conflict between two teams over the same engineers, with a different company and different stakes from the example here, and asks you to make the call and revise the losing team's OKRs.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the How to Design OKRs bootcamp for dates and the full syllabus.