The meeting that costs more than the feature

Because the meeting is the product. A cross-stack feature that touches a CRM vendor, a commerce integrator, a loyalty supplier and a middleware team has four owners and no owner. Each pair of them is a standing line of communication with a contract stapled to it. The build is a few engineer-days; the coordination — the weekly syncs, the alignment decks, the escalation ladder — runs for months. That gap is structural, not a failure of diligence.

Why does a four-party feature need so many meetings?

The math was old before most route-to-market stacks existed. In The Mythical Man-Month, Fred Brooks observed that the communication paths in a group grow as n(n-1)/2 — add people linearly and the lines between them grow quadratically. Two people share one line; four share six; six share fifteen. The build effort on a small feature is roughly linear in the people doing it. The coordination effort is not.

Now count who is actually in the room for a 'simple' loyalty mechanic that has to read a customer from the CRM, price the offer in the commerce platform, accrue points in the loyalty engine and carry the events between all three. That is four suppliers before the client's own architect and product owner sit down, which makes six parties and fifteen standing paths. Nobody scheduled fifteen meetings; they scheduled one weekly sync per boundary that mattered and let the rest happen over email. It still consumed more calendar than the code ever did.

What makes a vendor path more expensive than a team path?

Brooks was counting paths inside one team, where the friction on each line is merely social. Draw the same graph across company boundaries and every line acquires a contract. A path between two of your own engineers is a chat message. A path between two vendors is a statement of work, a scope boundary, a change-request process and a named escalation contact — and the first question on any cross-vendor call is never 'how do we build this,' it is 'whose scope is this in.'

That question is expensive because the honest answer is usually 'nobody's, quite.' The feature lives in the seams. The CRM vendor owns the customer record but not the points; the loyalty vendor owns the points but not the event that earns them; the integrator owns the pipe but not what flows through it. Every dependency discovered in that gap becomes a change request, and every discovered dependency generates an invoice. The meeting exists to decide who bills for the seam — a decision that is slower and dearer than writing the code on either side of it.

How does the coordination outweigh the build?

Put rough numbers on it. The build — a handful of endpoints, a field mapping, a test harness — is a few engineer-days on each side. The coordination is a weekly hour for the twelve or so weeks it takes four organisations to agree, each hour attended by six to eight people who prepared for it and wrote it up afterwards. One hour on the calendar is never one hour of cost: it is the hour, plus the alignment deck built to survive it, plus the follow-up thread, plus the two people who could not decide in the room and escalated it to their own managers. Multiply one hour by eight people by twelve weeks and you have outspent the build before counting a single deck.

None of the individual meetings is wasteful. Each one settles something real — a field mapping, a retry policy, the liability for a failed accrual. The waste is structural: the feature is small and the graph it has to cross is large, so the artifact spends almost all of its life queued at a boundary waiting for two companies to align, not being built. This is the coordination overhead that never appears on any invoice under the word 'coordination' — the quiet tax that resurfaces later as a maintenance budget nobody can quite itemise.

Where does the cost actually land?

The bill never arrives as a line called coordination, which is why it survives the audits that catch everything else. It is smeared across four vendors' time-and-materials sheets, the client's own program-management headcount, and the lead time of every feature that has to cross the same boundaries. And it compounds with reach: run one four-vendor stack across four markets and you have not added boundaries, you have multiplied them by the opcos — the arithmetic underneath reading a four-market transformation honestly.

The failure at the end of that road is rarely technical. It is a system delivered late, over budget and shaped by whichever vendor won the most scope arguments rather than by the people who have to use it — the pattern behind a nine-figure order system the reps simply refused to use. By the time it ships, the seams the meetings spent months negotiating have hardened into the product.

The fix is not better meetings; it is fewer boundaries. Every weekly sync is an interest payment on a graph you drew the moment you split one feature across four suppliers. You can make the meetings shorter, the decks tighter and the escalations faster, and Brooks's n(n-1)/2 is still sitting there, because you are optimising the paths instead of deleting them. Collapse the four owners into one team on one event bus and most of those paths — with the contracts stapled to them — simply stop existing.

The build cost of a feature keeps falling; the coordination cost of a four-vendor graph does not, because it is set by how many companies you invited, not by how hard the work is. Left alone, the ratio only widens — every new supplier is another row on Brooks's table and another contract on every line it touches. The brewers who get faster over the next few years will not be the ones with the best-run steering calls. They will be the ones who worked out that the cheapest meeting is the one that never had to be scheduled.