The Orchestration Tax

When execution breaks in public, the argument usually lands on a vendor. That is satisfying. It is also incomplete.

A lot of “tooling problems” are coordination problems wearing a software costume. The work is graph-shaped: partners, parallel approvals, channel rules, versioning that has to stay true across handoffs. The organization still tries to run it like a single straight line because that is how planning meetings fit on a calendar.

What breaks first is not ambition. It is integrity of handoffs: who owns the truth at each step, how late changes propagate, and whether the system can carry reality without turning senior people into human routers.

Where I learned it

I am not going to litigate anyone’s current stack. I have lived the other side in promotional work at serious volume: hundreds of brand partners, asset production, URL discipline, and launch timing that cannot stay manual without eroding quality or missing dates.

The published version of that work is on my site as case study material: workflow as source of truth, pipelines for deploy-ready output, status visible before windows compress, automation built on initiative because waiting for a perfect off-the-shelf fix would have been its own strategy, and a bad one.

That experience is not proprietary to one retailer. It makes the lesson easier to see. Orchestration debt is not a complaint about buttons. It is a failure mode that shows up across markets.

Throughput is not “more campaigns”

There is a common illusion: if the roadmap adds campaigns, the organization adds throughput the way a factory adds shifts.

Often it does not. It adds coordination surface area.

Every new partner, bundle, or compliance constraint does not only add tasks. It adds edges where truth can diverge: the brief, the landing page, the tracking scheme, the email build, the reporting definition. Under enough load, teams do not fail because they stop caring. They fail because the cost of staying aligned starts competing with the cost of doing the work.

That is the first implication worth naming: throughput without control. You can measure sends and launches and still run hot with a rising error class. Wrong parameters, late swaps, rework chains, emergency QA that becomes normal.

When the official workflow is not the real one

The second implication is quieter. Decision latency disguised as busyness.

If the real workflow lives in inboxes, chats, spreadsheets, and heroic individuals, but the official system is treated as truth because that is where status is reported, leadership sees motion while execution sees waiting. Approvals become bottlenecks not because people are slow, but because the decision graph does not match the tool graph.

The conflict here is not cynicism. It is competing realities. Ops wants repeatability. Creative wants room. Legal wants control. Partners want commitments. Everyone can be right and still produce a schedule nobody can honestly keep.

That messiness should not resolve too cleanly. Organizations that sanitize it into “we need better communication” often buy another platform and rediscover the same physics six months later.

What bad orchestration collects

If you want one mental model, think of it as a tax. It is paid in currencies leadership claims to care about but rarely measures together.

Rework. Not learning. Repeated correction of the same class of mistakes because truth did not survive a handoff.

Latency. Time spent waiting for clarity, re-briefing late changes, or rebuilding something that should have been generated once.

Creative displacement. Experienced people spending judgment on proofing and routing instead of bets, because the system cannot carry detail reliably at speed.

Risk asymmetry. Small operational slips at scale become large external consequences. The organization drifts toward safe repetition instead of better differentiation, not because the team lacks ideas, but because blast radius is scary.

Person-bound execution. If only a few people know how the wiring works, you do not have a process. You have heroes. That does not scale and it does not survive turnover.

Why the fix is rarely “better tools” first

The uncomfortable point: the fix rarely starts with shopping. It starts with deciding what must be true at each edge of the graph: what may vary by channel, what must never vary, what has to be generated not typed, and what human authority stays non-negotiable. Tools come after that. Sometimes as integration. Sometimes as automation you build because the gap is specific to how the business actually runs.

In the work I have published around this problem, the through-line is not that we adopted magic software. It is that initiative-built systems appeared where the throughput ceiling was real: pipelines for deploy-ready output, discipline in workflow states so downstream automation receives clean inputs, checkpoints that match how teams actually fail, not how decks pretend they fail.

That is not an argument that every company should build software. It is an argument that orchestration is a strategy problem disguised as an IT problem. If leadership treats glue as embarrassing, the org pays the tax in rework and risk. If leadership treats glue as infrastructure, the question becomes what you standardize, what you automate, and what you refuse to speed up because the cost lands somewhere ugly.

What still runs slow

People like to say marketing is getting faster. Often what is getting faster is the clock. Launch windows, partner expectations, competitive pressure. The coordination fabric moves at last year’s pace.

You do not win by being the loudest room. You win by being the one where truth survives handoffs. That is a design standard, not a slogan.