DG is right. Most marketing teams have an operating system problem. But I have contrarian opinions about what an operating system is.
In late May, Exit Five published a newsletter with the hook "Most marketing teams don't have a strategy problem. They have an operating system problem." The newsletter was promoting a podcast episode with the team at Tenon (a marketing automation platform built on ServiceNow, $8M Series A, positioning itself as the marketing operating system). The Tenon team's pitch on the episode: marketing teams whose strategy looks sound but whose execution doesn't, because campaigns aren't coordinated, the team isn't aligned, and focus drifts. The fix, they argue, is a platform that organizes the work.
I’ve spent the last decade+ inside exactly those teams. $20M - $80M ARR B2B SaaS, different industries, differing personas, degrees of variance in tech stack, but all share a few common threads of challenges. Most tried to buy tools/tech to fix it…to no avail.
My TL;DR: The operating system isn’t software alone. It’s backed by a posture.
We’ve seen this before
In the 1980s, every American automaker watched Toyota eat their lunch and concluded the answer was Toyota’s equipment. They bought the robotic arms, imported the just-in-time inventory systems, retrained the engineers, rebuilt the assembly lines. They were still getting destroyed by Toyota a decade later.
The reason is documented in every business school case study about the period. Toyota wasn’t winning because of the equipment. Toyota was winning because of how they thought about the equipment. The Toyota Production System wasn’t a stack. It was a posture: about who made decisions on the line, about what counted as a defect, about who had the right to stop production, about what a problem was for. The companies that imported the tools without the posture stayed broken. The ones that imported the posture (and built the tools around it) caught up.
There’s a phrase for what the laggards bought. Form without substance. The B2B version of this hit in the 2010s, when every mid-market company started importing Google’s open-plan office, free snacks, and ping-pong tables, then wondering why their teams didn’t suddenly produce Google-quality work. They copied the visible signals of how a great company looks, but didn’t import the hiring bar, the strategic clarity, or the autonomy that made any of those signals work in the first place.
The “marketing operating system” companies are selling ping-pong tables without the posture to support it.
👋 Hi, it’s Kaylee Edmondson and welcome to Looped In, my newsletter exploring demand gen and growth frameworks in B2B SaaS. Subscribe to join 2k+ readers who get Looped In delivered to their inbox every Sunday.
What an operating system should be
If software is the plumbing, the operating system is the architecture in this scenario. The set of decisions about who lives where, who has water, who shuts off the valve, and what happens when the basement floods.
For a marketing team, four things make up a well-oiled operating system.
One: role definition. What this function is for. Most teams can’t write it in under 100 words, which is the first sign they don’t have an OS.
Two: scope contract. What this function owns, what it influences, what it stays out of. Where the lines are. When sales or product or RevOps walk across the line, what happens next.
Three: skill stack. What the people on the team need to be able to do. The capability map: the math, the writing, the systems thinking, the political muscle.
Four: decision rights. Who decides what, with what evidence, at what cadence. When you change a campaign, who signs off. When you kill a channel, who signs off. When a CEO says “let’s replace HubSpot with AI in 40 days,” who has the authority to push back.
A team with all four has an operating system. A team with three or fewer probably has a tech stack and some hope.
Finding 1: Role definition is a hiring problem usually masked as a strategy problem
A GTM engineer started at one of my clients sixty days ago. Smart hire, real technical skill, exactly the role the company needed. His mandate, in the words of the CEO who hired him, was “generate pipeline.”
Two months in, he’s running outbound sequences like an SDR.
This isn’t his fault. The mandate was the problem. When the only thing you ask a GTME to do is generate pipeline, you’ve defined the role at the wrong altitude. The point of a GTME is to compound the entire revenue function. To fix conversion rates, build infrastructure, plug leaks, automate handoffs. None of that satisfies a “pipeline generation” mandate on the first measurement cycle. So he defaulted to the only motion that did: outbound. He’s the most expensive SDR in the building.
Buying him a better tool wouldn’t have fixed this. Plugging him into marketing operating software wouldn’t have fixed this. Nothing in the tech stack fixes a role aimed at the wrong altitude.
The role definition is the OS. The tool is the plumbing.
Finding 2: Scope contract is what makes the function defensible
Try this. Pull up some recent internal marketing decks. Find the slide where someone wrote down what demand gen (or whatever your department is) is for. This function exists because [X], it owns [Y], it produces [Z], and the company stops being able to do [W] if it stops.
If that slide doesn’t exist, you don’t have a scope contract. That’s the OS problem.
What you have instead is a budget line and a set of KPIs. Both are revisable. Both will be revised. The function survives whoever’s holding the budget; it doesn’t survive someone questioning whether the function should exist at all. The first time a CEO or a board member asks what the function produces and you can’t point to a concrete answer, the absence becomes the answer.
This is happening more in 2026 than it did in 2024. Boards are tighter, CEOs are reading more AI think pieces, and the question “do we still need this function” is being asked of marketing more often than of any other GTM team. A scope contract won’t save the function from a CEO who’s already decided to cut it. But it will save it from the CEO who’s only asking because nobody has put the answer in front of them. Most of these conversations are the second kind.
A scope contract is that answer. Not a JD or an OKR, but a written statement of what the function is for, what it owns, what it produces, and what stops if it stops. It’s amazing how simple it sounds, but still true that a ton of orgs don’t know the answer until it’s written (I’ve used the same template across every fractional engagement I’ve run that lacks this clarity. It walks through role overview, what’s in scope, and what’s explicitly out of scope, for ABM, growth, field, partner, and lifecycle. Copy it.)
Most marketing functions don’t have one. That is the OS problem.
Finding 3: Skill stack is the gap nobody is willing to name
DemandLoops (the frac b2b markting biz I run) has worked with plenty of companies that have no marketing operations owner. Not in the sense that the role is vacant, but more so in the sense that nobody on the team has been hired with the technical skill to own the role.
The pattern goes like this…
Salesforce breaks in a way that affects attribution.
The marketer in the meeting (smart, capable, not a MOPs person) raises her hand to figure it out.
She spends three weeks learning what should have taken a specialist maybe a few hours.
The dashboard ships, two weeks late, with an undisclosed flaw.
Three months later, the board deck cites numbers that are quietly wrong.
Multiply that by every function that’s facing similar gaps. That’s the OS problem at the skill-stack layer. A platform doesn’t fix this. Skill stack work is the least glamorous part of building an operating system. It’s also the only part though that compounds (especially when those human-skills can now become agent-skills).
Finding 4: Decision rights separate operators from spectators
Try a different test. Think about the last three significant marketing decisions your company made. A tool getting replaced, a channel getting killed, a budget reallocated mid-quarter. For each one, ask two questions: who was authorized to make the decision, and who was authorized to push back on it.
If the answer to either question is “nobody knew” or “leadership just decided,” you don’t have decision rights. Decisions are happening to the function rather than through it.
Strategy questions tend to get debated. Operational questions get a memo. But the in-between decisions, the ones that shape what the function actually does day to day, get made unilaterally because nobody specified who was supposed to make them. By the time you find out, the work has changed and the team that has to absorb it had no channel to weigh in before it happened.
That’s the decision rights gap. The gap isn’t “should we make this change,” but really “who is allowed to push back on a change after it’s been decided.” When the answer is “nobody,” you don’t have an operating system. You’ve found yourself in a top-down scenario where leadership oftentimes makes every decision, and you execute against whatever it is.
The difference between a company that absorbs a hard decision well and one that doesn’t is whether the operating system gave someone the right to push back before the decision was final. If it did, the conversation happens upstream. If it didn’t, the conversation happens downstream, after the cost is already real.
That’s not a tool. That’s a posture.
The test
Kieran Flanagan published a piece last week applying Satya Nadella’s framing of digital sovereignty to AI strategy. The test he names is one I’m adapting for client work going forward, because it maps almost perfectly to the operating system question.
Can you swap your entire tech stack tomorrow and still keep your competitive advantage?
If yes, you have an operating system. The stack is plumbing. Useful, but interchangeable. Your advantage lives in how you think, how you scope, how you decide.
If no, you don’t have an operating system. You have a tool you’ve grown to depend on, in a posture you never built. The day a competitor buys the same tool, your advantage disappears.
Most platforms in this category would fail this test for most of the teams buying them. The products themselves aren’t inherently bad, but the buyers don’t have an OS to plug them into. You can’t get sovereignty from a vendor. You build it, or you don’t have it.
The objection I’d have if I were reading this
Fair pushback: “But platforms still matter, right? You’re not telling people to stop buying software.”
I’m not. Platforms are great. Plumbing matters. The Toyota analogy isn’t “don’t buy robotic arms.” It’s “buy the robotic arms in service of the posture, not as a substitute for it.”
The way to know which you’re doing is to look at the order of the decisions. If your team picked the platform first and is now trying to design the posture around what the platform supports, you’re buying ping-pong tables. If your team wrote down the role definition, scope contract, skill stack, and decision rights first, and then picked the platform that fits, you have an OS and the right plumbing.
Most teams I work with picked the platform first. That’s the OS problem, not the platform problem.
Own the methodology. Rent the tools.
Kieran’s frame for AI strategy was “Own the layer. Rent the model.” The same logic applies to the operating system question.
Own the methodology. Rent the tools.
Your methodology is the four things. Role definition, scope contract, skill stack, decision rights. That’s the asset that compounds. It survives every platform migration and every leadership change. It is, to borrow Kieran’s framing, your sovereignty.
Your tools are interchangeable. Salesforce becomes whatever replaces Salesforce. Marketo becomes whatever replaces Marketo. None of that should affect what your function is for, the skills it houses, or the why behind its operation.
The companies that win this leg of the race are the ones who built the posture, and then plugged tools into it. We’re entering into the era of everyone being a builder after all.
See ya next week! ✌️
Kaylee
Spot on. A fancy tech stack means nothing if the words and the 1-page website don't actually tell a clear story. True operating system starts with clean language that makes people want to buy.