Building a Cross-Functional Demand Operating System
Campaigns were launching, but ownership, sequencing, and stakeholder visibility were inconsistent. Cross-functional teams were spending too much time renegotiating how work moved instead of executing the work itself.
Context
B2B programs touched paid media, web, marketing operations, campaign operations, analytics, and sales. Each function brought its own intake, calendar, dependencies, and definition of done. The operating problem was not a lack of activity. It was the absence of one shared way to turn an executive priority into a runnable campaign.
My role
I led the campaign-side operating system: translating executive goals into the recurring ownership, launch sequence, reporting expectations, and decision cadence the cross-functional team could actually run.
Constraints
- ·No appetite for a new project-management platform.
- ·Existing meeting load was already high.
- ·Functions used different definitions of campaign success.
- ·The system had to reduce coordination overhead rather than create another governance layer.
What I did
- ·Mapped intake, handoffs, decision points, and reporting touchpoints.
- ·Separated recurring ownership ambiguity from one-off complexity.
- ·Defined a RACI for recurring campaign types.
- ·Standardized request inputs.
- ·Sequenced launch dependencies with named owners.
- ·Replaced status-heavy meetings with decision-focused pre-reads.
Before to operating design
How an executive priority became a runnable campaign.
Before
Each function interpreted the priority on its own terms.
- 01Executive priority
- 02Function-by-function interpretation
- 03Separate intake and calendars
- 04Ownership negotiation
- 05Launch
- 06Status reporting
Operating design
The same priority, routed through one shared path.
- 01Executive priority
- 02Scoped campaign brief
- 03Recurring ownership / RACI
- 04Dependency and launch sequence
- 05Readiness check
- 06Decision-focused pre-read
- 07Measurement and next decision
Readiness check means the documented launch checklist and dependency state: owners named and dependencies in order. It is not a scoring model.
What was built
A five-part operating system.
- 01
Intake and scope
Light intake captured the minimum inputs needed to scope work.
Built: Light intake form
- 02
Ownership
Recurring campaign types used a predefined RACI, so ownership was decided once instead of inside every launch.
Built: RACI for major recurring campaign types
- 03
Dependencies and sequence
A launch checklist named the owner of each stage and put dependencies in order, instead of letting functions advance independently.
Built: Launch sequencing checklist with named owners by stage
- 04
Decision cadence
Structured pre-reads focused on decisions, risks, and next steps instead of status reporting.
Built: Decision-focused pre-read format
- 05
Measurement expectations
Campaign work carried agreed reporting expectations, so activity could be separated from qualification and pipeline evidence.
Built: Shared reporting expectations
Governance and decision rights
Which decisions moved upstream.
The operating design moved recurring decisions upstream. The goal was not more process. It was fewer coordination decisions inside active work.
- Recurring ownership was decided upstream rather than renegotiated during execution.
- Decisions and risks were surfaced in pre-reads.
- Dependencies were surfaced before launch.
- Dependencies were resolved before launch where required.
- Reporting separated activity from stronger downstream evidence.
Business scope
What the system was used to operate.
- Documented campaigns of record
- 7
Those campaigns ran through the system, with leads, sales opportunities, opportunity value and active pipeline tracked in the shared reporting. Their figures are not published here.
The campaign count describes the business scope operated through the system. Nothing here is presented as revenue causally attributable to the operating model alone.
Why the model stuck
Operating models fail when they feel like overhead. The version that stuck was the one that removed work, not the one that documented it.
The leverage came from deciding recurring things once: what information a request needed, who owned which stage, what had to be ready before launch, and what leadership needed to decide.
What remains unproven
This case shows the system, the business scope it supported, and the decision discipline it created. Three things sit outside that evidence.
- Cycle time from brief to launch was not instrumented.
- Resource-allocation impact was not isolated.
- No causal claim is made for pipeline outcomes.
No quantified efficiency improvement is claimed.
What I would do next
Instrument the operating system itself, starting with cycle time from brief to launch and the causes of delay. That would make it possible to distinguish coordination improvement from campaign-performance improvement and identify the next operational constraint.
Contact
Get in touch
Open to full-time Senior Manager, Director, and Director-track roles in demand generation, growth, PLG, and GTM systems. Remote preferred; selective Seattle-area hybrid.