Campaigns Are Systems, Not Checklists

Everything below is free and useful before you read a word about who wrote it.

The executive problem

Every marketing organization has lived through some version of the same failure. The campaign was fully planned. Every task had an owner. Every asset had a deadline. And it still broke: a landing page went live pointing to a form that hadn't been updated, an email sent to a segment that had already unsubscribed through a different channel, a paid ad drove traffic to a page legal had not yet cleared. Nobody missed their to-do. The checklist was, by its own definition, complete. The campaign failed anyway.

This is not a story about individual error. It is a story about the model marketing teams use to run campaigns, and that model is a checklist: a flat, sequential list of tasks, each assigned to a person, each with a due date, tracked in a tool that has no idea what a landing page is, what a segment is, or what "live" means. The checklist can tell you every task was checked off. It cannot tell you the tasks were consistent with each other, executed in the right order, or reviewed by the right people before touching a live system. It has no concept of a dependency, and no concept of system state, only whether a box was ticked.

The cost shows up as production incidents, and marketing organizations have quietly normalized a level of breakage no other business function would tolerate. A pricing page goes live with last quarter's numbers. A campaign keeps sending to a list that should have been suppressed. A rebrand rolls out on the website before the ad accounts, so a prospect sees two different companies in the same afternoon. Each is treated as an isolated mistake, patched after the fact. None of them is isolated. Each is a predictable output of running an interdependent system as unrelated errands.

The deeper cost is what this does to velocity. When nobody can say with confidence that a campaign's pieces are in sync, the response is more review, more manual double-checking, more people added "just to be safe." Coordination overhead rises, not because the work is harder, but because the operating model gives nobody a reliable way to see the whole campaign at once, a discipline scaling its output faster than its process.

The contrarian thesis

The prevailing assumption is that orchestration and scheduling are the same thing: if every task has a date and an owner, the campaign is orchestrated. This is false, and the difference matters more than most marketing organizations have been willing to admit.

Scheduling answers one question: when does each task happen. Orchestration answers a harder set: what does this task depend on, what resources does it consume or modify, who has to review it before it proceeds, and what is monitoring it once live. A campaign is a system of dependencies, resources, reviewers, and monitoring. Treating it as anything less is the direct cause of the production failures described above.

Consider a mid-size product launch touching the website, a marketing automation platform, a CRM, an ad platform, and a legal review queue. A landing page cannot go live before its tracking pixels are configured. An email cannot send before its segment has been validated against the CRM's latest suppression list. A paid campaign cannot launch before its landing page has cleared review. None of these are scheduling problems. They are dependency problems, and a calendar cannot see them.

This is the contrarian claim worth stating plainly: a project plan with dates is not a system. A system has structure, explicit relationships between its parts, explicit ownership of state, explicit gates something must pass before it can affect production. Marketing has historically had none of these as first-class concepts, only spreadsheets, boards, and calendars, excellent at representing tasks and hopeless at representing systems.

The operating model

If orchestration is a systems problem, the operating model has to look like one. This is not a marketing-native idea. It is closer to how other technical disciplines have long managed this kind of coordination problem, worth borrowing openly rather than reinventing.

Adobe's Campaign product documentation, describing the orchestration layer of a marketing campaign platform, is a useful reference point precisely because it is vendor documentation rather than academic research. It describes what a working system has to represent. It frames a campaign as centralizing "all the elements related to a marketing campaign: deliveries, targeting rules, costs, export files, related documents," separating a campaign into categories a flat checklist collapses into one: campaigns "include actions (deliveries) and processes (importing or extracting files), as well as resources (marketing documents, delivery outlines)." A single interface is meant to "schedule, orchestrate, configure, personalize, automate, execute, and measure all your campaigns", scheduling is one verb among seven. It is equally explicit about the review layer: reviewers "monitor and control processes of the campaign: targeting, content, budget, extraction, and proof sending," with a modification and sign-off history compiled as deliveries move through validation steps. That compiled history is what most marketing operating models lack entirely. Most campaigns have no equivalent of a change log, so when something breaks, the postmortem starts from scratch.

A more recent and more prescriptive articulation of a systems-based operating model comes from the Harvard Business Review piece "Redesigning Your Marketing Organization for the Agentic Age" by Michelle Taite, John Winsor, and Will Fernandez (HBR, May 8, 2026). Their diagnosis is blunt: "most marketing organizations are struggling to keep up because their operating model (sequential, siloed, and coordination-heavy) hasn't changed." That is a precise description of the checklist model this article argues against, and the framing comes from a former CMO's direct operating experience, not an outside consultancy's theory.

Their proposed remedy is a machine-readable "brand code": a structured encoding of brand strategy, customer insights, and business rules that both humans and AI agents can act on directly, paired with "layered systems of specialized agents" handling content creation, experimentation, distribution, and reporting. Read this as a proposed operating model, not a proven one, the piece leans forward toward where marketing operations is heading rather than describing widespread current practice. But the structural insight holds regardless of how quickly agentic execution arrives: governing rules need to be explicit and machine-legible, not locked in someone's head. McKinsey's 2026 work on "the agentic organization" makes a parallel argument at the enterprise level, reasonable corroboration this shift is not specific to marketing.

Put together, a working operating model has four properties a checklist does not: it separates actions from resources from processes; it makes dependencies explicit rather than implicit; it routes review through defined reviewers at defined gates rather than an open Slack thread; and it keeps a compiled record of what changed and who signed off.

The framework

Call it the Dependency Map, five elements, and a campaign is not ready for production until each one is explicit rather than assumed.

Dependencies. Every deliverable depends on something else being true first: a tracking pixel configured before a page goes live, a suppression list updated before a send, a brand asset approved before downstream use. A dependency map lists these relationships explicitly, as a graph rather than a sequence, so anyone can see what blocks what without asking around.

Resources. A campaign consumes and modifies shared resources (landing pages, templates, segments, budgets, brand assets) that other campaigns may also depend on. Treating these as shared state, rather than private copies each owner manages independently, prevents one campaign's change from silently breaking another's assumption about the same resource.

Reviewers. Every gate needs a named reviewer with actual authority to block progress, mapped to what they review: targeting, content, budget, legal, and technical implementation. A reviewer without the power to stop a launch is a formality, not a control.

Schedule. Dates still matter, but here the schedule is downstream of the dependency graph, not a substitute for it. A task's date is only meaningful once its dependencies and reviewers are satisfied.

Monitoring. A campaign does not end at launch. Live, it needs active monitoring against the rules it was built to satisfy: is the segment still correctly suppressed, is the page still pointing where it should, has anything downstream changed a resource this campaign depends on. Monitoring turns "we launched it correctly" into "it is still correct", a different and frequently false claim.

The steps

1. Pick one live campaign this quarter and map its dependencies before touching its task list. List every "this cannot happen before that" relationship among its deliverables.
2. Inventory the shared resources it touches (pages, segments, templates, budgets, assets) noting what else depends on each, so collision risk is visible before it becomes an incident.
3. Name a reviewer for each gate, with authority to block. A gate with no reviewer, or one with no real authority to stop the launch, does not exist yet.
4. Build the schedule from the dependency graph, not the other way around. Dates should fall out of what depends on what, not get assigned first with dependencies discovered later.
5. Define what monitoring looks like once the campaign is live, what "still correct" means, and who is watching for drift.
6. Run the campaign and keep a record of every change and sign-off as it happens, not reconstructed afterward from memory and Slack scrollback.
7. After launch, review against the dependency map, not the task list. Ask which dependencies held, which broke, and which nobody had identified in step one.
8. Apply the same structure to the next campaign, expanding the shared-resource inventory each time so the organization builds a durable picture of its system instead of restarting from zero.

Roles

• Campaign owner: Maintains the dependency map, resource inventory, and schedule; accountable for the campaign as a system, not a task list
• Reviewers (targeting, content, budget, legal, technical): Hold real authority to block a gate until conditions are met; sign-off is recorded, not verbal
• Resource stewards: Own shared assets (segments, templates, brand assets, budgets) and flag conflicts across campaigns touching the same resource
• Systems that consume the campaign record: CRM, automation platform, ad accounts, and analytics stack that read from or write to the campaign's state

Metrics

• Dependency-related launch delays. How often a campaign is held or rolled back because a dependency was violated. A falling count is evidence the map is catching what the checklist used to miss.
• Escape rate. The share of production incidents that reach a live audience before anyone catches them, versus the share caught at a review gate.
• Coordination overhead. People pulled into ad hoc review or firefighting on a campaign not already accounted for in its named reviewers. Rising overhead despite a growing team signals the operating model, not headcount, is the constraint.
• Time from dependency map to first draft schedule. How long it takes an owner to go from a blank map to a schedule they trust. This should fall as the shared-resource inventory matures.

The checklist

• Draw the dependency graph for your next campaign before you build its task list.
• List every shared resource the campaign touches and who else depends on each one.
• Name a reviewer, with real authority to block, for every gate the campaign passes through.
• Confirm every sign-off is recorded somewhere durable, not implied by silence.
• Build the schedule from the dependency graph, not before it exists.
• Define, in writing, what "still correct" means once the campaign goes live, and assign someone to watch for drift.
• Hold a post-launch review against the dependency map, not the original task list.
• Carry forward every dependency and resource conflict into the shared inventory for the next campaign.

The 30/60/90

Days 1-30. Select one active or upcoming campaign as a pilot. Build its dependency map, resource inventory, and reviewer list from scratch, resisting the urge to reuse an existing task list as a shortcut. Run it through to launch, keeping a plain record of every dependency violation, review delay, and ad hoc coordination outside the named reviewers.

Days 31-60. Run the post-launch review against the dependency map and use it to correct the map, not just the campaign. Extend the same structure to a second, more complex campaign, and begin consolidating the shared-resource inventory across both.

Days 61-90. Make the dependency-map-first approach the default starting point for campaign planning, not an exception for pilots. Establish the four metrics above as a standing report, and use the growing resource inventory to surface cross-campaign conflicts before they reach production.

The technology layer

None of this requires new headcount so much as software that can hold a dependency graph, a resource inventory, and a review history as first-class, queryable state rather than tribal knowledge scattered across documents and threads, and increasingly, software is built for exactly that purpose: Launch, for instance, discovers what is actually live across a marketing team's connected systems, checks it against the rules that govern it before anything ships, and keeps the record of what changed and why, the same function version control and code review serve in software engineering.

Frequently asked questions

Q: Isn't this just project management with extra steps? No. Project management tools represent tasks and dates; they have no native concept of a dependency between systems, a shared resource multiple campaigns touch, or a reviewer's authority to block a gate. The Dependency Map adds structure a task list cannot represent.

Q: Our campaigns are simple, do we really need this? If a campaign touches more than one system (a website, an email platform, an ad account, a CRM) it already has dependencies whether or not anyone has mapped them. The question is whether the structure is explicit enough for someone other than the owner to see it.

Q: How is this different from what Adobe Campaign or similar platforms already do? Adobe's documentation shows the concept working inside one vendor's product: it separates actions, resources, and processes, and gives reviewers explicit monitoring and sign-off roles. The framework here generalizes that structure so it applies regardless of which tools a team runs.

Q: Is the "brand code" and agentic-layer model from the HBR piece something we should adopt now? Treat it as a direction, not a mandate. The piece is deliberately forward-leaning about how quickly AI agents will take on layered execution roles. Its durable insight, that governing rules need to be explicit and machine-legible, is worth adopting now, regardless of how fast agentic execution itself matures.

Q: Where should we start if we only have time for one change this quarter? Start with the dependency map on a single real campaign. Resources, reviewers, and monitoring all become easier to define once the graph makes the campaign's actual structure visible for the first time.

Related reading

For the practices behind a controlled release, read what release management means for marketing. The article why marketing never got a release process gives the background.