Six functions, one deal, and nobody who actually decides

Look back at the deal that quietly slipped last month. Security had questions but assumed procurement would close it. Procurement was waiting on the budget owner. The budget owner thought the sponsoring VP had already blessed it. Legal was reading clauses nobody had told them were still open. IT architecture was cc'd on everything and asked about nothing. And the business owner, the person whose problem the tool was meant to solve, assumed all of the above meant the deal was moving. It was not moving. It was drifting, because six functions were involved and each one assumed another held the final call.

The reflex diagnosis is that there were too many people in the room. That is the wrong diagnosis, and acting on it makes things worse. This post argues that unclear decision ownership, not stakeholder count, is what turns a committee into a stall.

The crowd is not the problem

Six functions on a software deal is normal and usually correct. Security should look at a tool that touches customer data. Legal should read the master agreement. Finance should own the number. The business should confirm it solves the thing it was bought to solve. Removing any of them does not speed the deal, it just moves the risk to whoever is left holding it after signature.

So the size of the group is a distraction. What actually causes the stall is that the group was assembled without an answer to one question: who decides. Not who advises, not who has a strong opinion, not who can veto on their own turf. Who signs the decision and owns the outcome. When that is unassigned, every participant defaults to the safest posture available to them, which is to wait for someone else to move first. Six people waiting on each other looks exactly like six people working, right up until the renewal date on the incumbent forces a rushed choice.

Why ownership stays unassigned

This is not carelessness. There are structural reasons the owner never gets named, and they repeat across organisations.

First, intake rarely captures it. A request arrives with a submitter and a rough need, and the question of who will own the eventual decision is treated as something that will sort itself out later. It does not sort itself out. We have written before about the intake request that arrives with a submitter but not an owner, and the sign-off stall is the same disease at a later stage.

Second, advisory and deciding blur together. Everyone invited feels responsible for the outcome, which sounds healthy but produces diffusion. When responsibility is shared equally by six people, it is owned by none of them. Third, seniority masks it. The senior person in the thread is assumed to be the decider, but they may see themselves as a sponsor endorsing a recommendation someone else is supposed to make. Fourth, nobody wants to volunteer for the accountability. Owning the call means owning the miss if the tool underdelivers, so absent a named assignment, people quietly let it float.

What naming the owner up front actually does

The fix is not a meeting to discuss roles. It is a structure that forces the roles to be filled before the evaluation gets far enough to drift. The deal sign-off chain does this by naming the decision owner and each approver at the start of the deal, and by making the distinction between the two explicit. One person is the owner. Everyone else is an approver with a defined scope: security approves the data posture, legal approves the terms, finance approves the number. Advisers are advisers, and they are labelled as such so nobody mistakes an opinion for a gate.

The point is the sequencing. Naming the owner after the drift starts is damage control. Naming them before the first vendor call means every subsequent conversation has a clear destination. When the vendor asks who signs, there is an answer. When an approver goes quiet, the chain shows their gate is open and the owner can push on it, rather than the whole deal silently pausing.

The approver brief is what keeps advisers advising

Naming the owner solves half the problem. The other half is that approvers stall too, usually because they were handed the whole deal and asked to bless all of it, when they only actually own one slice. An approver who opens a hundred page package with no guidance on what they are responsible for will either rubber stamp it or sit on it. Both are failures.

So each approver gets a brief scoped to their gate. The security reviewer sees the data and tenancy posture, not the pricing negotiation. Finance sees the number and the commitment length, not the clause redlines. This is the same principle behind the sign-off that waits for a calendar that never clears: an approver who can see their scope in minutes clears it in minutes, and the deal keeps moving.

With the six specialist agents doing the reading and drafting behind the scenes, and the sign-off chain holding the structure, the owner spends their attention on the decision itself rather than on the logistics of extracting one. That is the whole gain. You did not remove any stakeholder. You removed the ambiguity about who among them decides.

What this does not solve

Be honest about the boundary. A sign-off chain names who decides. It does not make the decision good. If the owner is the wrong person for the call, naming them cleanly just gets you to a bad decision faster. Governance structure removes the drift, it does not supply judgement.

It also does not resolve genuine disagreement between functions. If security and the business owner truly conflict on whether the data posture is acceptable, the chain surfaces that conflict and routes it to the owner. It does not settle it. That is a feature, not a gap, but do not expect the tool to arbitrate a real dispute. And it cannot fix an organisation that overrides its own owners. If the named owner decides and a senior stakeholder reverses it off-platform, no chain will hold. The structure works where the organisation agrees to honour it.

What it does reliably is end the specific failure this post opened with: six capable functions, all engaged, all waiting on each other, all assuming the call belonged to someone else. That drift is a governance defect, not a headcount problem, and it has a governance fix. Name the owner. Scope the approvers. Start before the drift, not after.

Want to be updated when major licensing and pricing changes land? One analyst brief a week: the price rises, metric changes and audit campaigns that move software costs. Work email only.