Pick the most important cross-functional thing your company is supposedly working on right now. Customer onboarding, maybe. Or the data platform. Or the pricing overhaul. Or whatever new market motion was announced at the offsite. Now answer this question, honestly, in one sentence: who, by name, is the single person whose performance review depends on whether this gets delivered on time and on intent?

If you have to think for more than ten seconds, the project belongs to no one. And it is not going to be delivered.

I've watched this play out enough times to be confident in the prediction. The thing that everyone agrees is critical, that gets mentioned in every leadership meeting, that the CEO references when asked what the company is focused on — that thing, six months from now, is going to be in roughly the same state it's in today, plus or minus some apparent activity around the edges. Not because the people working on it are bad. Because the structure around it makes ownership impossible.

What "owner" actually has to mean

In most organisations, "owner" is a label slapped on a slide. The label says: this person is responsible. What it doesn't say — and what almost nobody asks — is: responsible to do what, with which resources, against what authority?

A real owner needs four things. They need a clear outcome they can be measured on. They need the budget, or the authority to request budget without going through six different approvers. They need the people, or the authority to redirect people from their current work without it being a political event. And they need the air cover to make trade-offs that other functions won't like — to slow something down in another team, to deprioritise an integration somebody wanted, to push back on the CRO when the deal that's been promised is actually incompatible with the architecture.

If you walk through your top initiative and check it against those four things, here's what you'll find. The "owner" probably has the outcome. They probably do not have the budget — it lives in three different cost centres and re-allocating it requires a finance review. They almost certainly do not have the people — the engineers are on loan from a platform team that has its own roadmap, the designer is shared with two other projects, the data analyst has a different boss who outranks the owner. And the air cover varies wildly with whether the CEO happens to remember the project that week.

That isn't an owner. That's a project manager with a title.

Why this happens

It's not because leadership teams are careless. It's because real ownership requires giving someone real authority over resources that other people in the room also want authority over. And every time a cross-functional initiative gets stood up, the implicit negotiation goes like this: "I want this thing to succeed, but I'm not actually willing to give up control over my engineers / my budget / my roadmap to make it happen." Multiply that by five executives, and what gets created is a project nobody actively opposes and nobody actively owns.

The clearest tell is the language. Cross-functional initiatives almost always get described with passive verbs. "Customer onboarding is being modernised." "The data platform is being built out." When you see that grammar, it's a signal. Real ownership produces active sentences: "Maria is rebuilding customer onboarding, and the platform team is going to slow their roadmap by six weeks to do it." That sentence makes someone uncomfortable, which is exactly why the passive version is preferred.

What it costs you

The first cost is obvious: the work doesn't get done, or it gets done late, or it gets done in a hollowed-out form that misses the actual outcome.

The second cost is less obvious but more expensive: every "shared ownership" failure trains the organisation to be skeptical of cross-functional initiatives in general. Senior individual contributors learn that getting assigned to a cross-functional project is a career risk — you'll be held responsible without authority, and when it fails you'll be the one explaining. So the next time a cross-functional initiative needs a lead, the best people quietly avoid it. Which means the lead role goes to someone less capable, which makes it less likely to succeed, which reinforces the lesson. After a few cycles, the company has a structural bias against the exact kind of work that creates strategic differentiation.

The third cost — and this is the one that surprises people — is at the executive level. Executives whose functions are nominally contributing to the unowned project develop a kind of selective amnesia about it. When asked, they say it's a priority. In their actual planning, they treat it as something they'll help with if they have spare capacity, which they never do. Over time, the leadership team loses the muscle of actually committing to shared bets. Every "priority" becomes a wish list item with a glossy name.

What works

There's a smaller set of things that actually fix this than the consulting literature would suggest. Most of them are uncomfortable.

The first is naming a single accountable owner with disproportionate authority. Not first-among-equals. Not a steering committee. One person whose job, for the duration of the initiative, formally outranks the functional heads on matters within scope. This is uncomfortable for the functional heads — which is the point. If they aren't willing to subordinate themselves on this specific thing, the company isn't actually committing to it.

The second is making the resource commitments explicit and binding. Not "the platform team will support." A named percentage of named engineers, locked for a named period, with a clear protocol for what happens if the platform team's own roadmap suffers. If you can't write that paragraph for the initiative, you don't have an initiative. You have a hope.

The third is putting the trade-offs in the planning artefact, not in a footnote. The initiative description should include the line "to do this, we will slow X, defer Y, and stop Z." If that line is missing, the initiative is implicitly assumed to be additive, which means it's competing for the leftover capacity that doesn't exist, which means it's not going to happen.

The fourth is making the owner's performance review depend on the outcome — and making it stick when it does. If a cross-functional owner can succeed at their day job but fail at the initiative and still get a good review, every future owner will optimise for the day job. If they can fail at the day job because they invested in the initiative and still get a good review, you've started to teach the organisation that this kind of work matters.

The Vindaris view

When initiatives, capacity and ownership sit in the same graph, the "project that belongs to no one" becomes structurally hard to maintain. You can see immediately which initiative has no named accountable owner, which one has no real capacity commitment, which one is competing for the same people as three others. The patterns that produce unowned projects — the implicit negotiations, the passive grammar, the resources nobody has actually committed — become visible artefacts instead of hallway intuitions.

That doesn't fix the underlying executive courage problem. Someone still has to be willing to give an owner real authority. Someone still has to write the line about what gets slowed, deferred or stopped. But it makes the gap obvious, which is the first move. Right now, the project that belongs to no one is hiding in the gaps between four different tools and the gaps between five different executives. Put it on one surface, and there's nowhere left for it to hide.

The most important work in your company is almost certainly cross-functional. That's just what "important" means at scale. The job of the operating model is to make that work ownable — and right now, for most companies, it isn't.