The Borrowed Critical Path: A Diagnostic for OKRs Held Up by Another Team

Most OKR guidance assumes that the team writing the objective also controls the work. In practice, many UK teams spend their quarter waiting on someone else: a finance team that must approve a pricing change, a platform team that owns the release pipeline, a supplier that controls stock availability, or a central function that holds the only specialist able to complete a compliance step. The objective may be sound, but the critical path runs through another team's diary.

The risk is not dependency itself. Cross-team dependency is normal in any organisation of scale. The risk is writing an OKR as though the dependency does not exist, then discovering at quarter-end that the team is being measured on an outcome it could not unilaterally deliver. The result is predictable: defensive status reporting, late escalation and a review meeting that becomes a search for someone to blame.

Why borrowed outcomes distort accountability

An OKR works when the link between effort and result is visible. A borrowed outcome breaks that link. The team can do everything in its own control and still miss the objective because another team deprioritised the work, a supplier changed its lead time or a platform release slipped by three weeks.

This does not mean teams should avoid ambitious objectives that require collaboration. It means they should be explicit about the boundary between influence and control. A useful diagnostic question is simple: if this team performed perfectly for the next twelve weeks, could it deliver the objective on its own? If the answer is no, the OKR contains a dependency that must be written down, owned jointly and reviewed on a shared cadence.

Separate what you own from what you borrow

Start by classifying each key result into one of three categories. Owned results are those the team can deliver without another party completing a critical step. Influenced results depend on another team's cooperation, but the team's work materially changes the outcome. Borrowed results are those where another party controls the pace and the team can only prepare, prompt and integrate.

This classification is not an excuse for passivity. It is a drafting discipline. Owned results can be written in the usual way, with clear measures and dates. Influenced results should name the counterpart team and the contribution expected from them. Borrowed results should rarely appear as standalone key results for the dependent team. Instead, they belong in a dependency clause attached to a more honest owned result, such as preparing the integration, completing the readiness checks or securing sign-off within a defined window.

A practical test is to ask what the team would report if the other party delivered nothing. If the answer is 'we would have no result to show', the key result is borrowed and should be reframed.

Write dependency clauses, not hope

A dependency clause is a short, explicit statement inside or alongside the OKR. It should name four things: the counterpart, the deliverable, the date by which the dependency is needed, and the consequence if it arrives late. For example, rather than writing 'Launch the new client portal by 31 March', a team might write an owned key result about completing all readiness activities, with a dependency clause stating that the platform team will provide the production environment by 20 February and that the launch date will be reset if that milestone slips.

This is not bureaucracy. It is the difference between an OKR that survives contact with reality and one that collapses into a post-mortem. The clause also protects the counterpart team from vague expectations. It makes the request visible early enough for them to plan, rather than arriving as an urgent email in the final fortnight of the quarter.

Set joint checkpoints with named counterparts

Dependencies fail quietly. A joint checkpoint is the antidote. For each material dependency, agree a short review every two to four weeks with the counterpart team's named owner. The agenda should be narrow: what was promised, what has moved, what is now at risk, and what decision is needed. Keep the conversation at the level of the critical path, not a general status update.

In UK organisations with matrix structures, these checkpoints are especially important because no single manager may own the whole path. A joint checkpoint creates a shared record without pretending that one team controls the other. It also gives both sides an early warning mechanism. If the dependency is going to slip, the dependent team needs to know while it can still re-sequence its own work, not after the quarter has closed.

A short diagnostic scorecard

Before committing an OKR set, score each objective against five questions. First, can the team deliver it without another party completing a critical step? Second, is every external dependency named with a counterpart and a date? Third, is there a joint checkpoint already in the calendar? Fourth, has the team defined what it will do if the dependency slips? Fifth, would the objective still be worth reporting if the dependency failed?

A score of four or five suggests the OKR is honest about its dependencies. A score of one or two suggests the team is about to spend the quarter waiting in a room it did not book.

When the dependency fails

Even well-written clauses do not guarantee delivery. If a dependency slips, the first response should be a factual reset, not a search for fault. State what has changed, what remains within the team's control, and which decisions are now required. If the objective can no longer be achieved as written, amend it openly and record why. An OKR that is quietly abandoned is worse than one that is formally revised, because it teaches the team that reporting is theatre.

For teams preparing for the 2027 planning cycle, the lesson is worth carrying forward. Dependencies are not a weakness in an OKR set. Pretending they do not exist is. The stronger approach is to write the borrowed critical path into the objective, agree the checkpoints early and keep accountability where it can actually be exercised.