Why marketing keeps redrawing its org chart

Marketing organizations are meant to change as their customers change, and as the mechanics of consumerism and information sharing shift under everyone’s feet. There’s a line, often credited to Voltaire and probably mangled by now, that change is annoying, but certainty is absurd. Organizational design proves it.

Marketing keeps redrawing its org chart because each structure solves the problems of its moment, only to create new ones as the business changes. Sometimes the evolution loops back to something that looks like where a company started, brand ownership again, or channel expertise again, just seen from a different angle with new tools and new constraints.

What matters more now is knowing when change is actually needed, not just fashionable, and building the setup that fits this moment instead of the last one. The pattern is easiest to evaluate from where it actually began.

The brand era and its hidden tax

Brand management started with a memo: in 1931, a young P&G executive named Neil McElroy got frustrated while working on Camay’s advertising campaign because he had to compete not only with soaps from Lever and Palmolive, but also with P&G’s own Ivory.

As Derrick Daye recounts in Branding Strategy Insider, McElroy proposed putting a person in charge of each brand, with a team devoted to every aspect of its marketing, essentially treating each brand as a separate business. P&G approved the proposal, and brand management became widely emulated across consumer-products companies.

The logic behind it holds up well even today. One owner who genuinely understands the customer and the competitive set, with real authority to make the brand win, is simply how you run a company that sells more than one thing. That was true first in packaged goods, and eventually in any organization that grew a portfolio through acquisition or expansion.

The bill, though, comes due on the technology side. Give every brand its own P&L, and every brand starts wanting its own martech stack, its own analytics setup, and its own firm opinions about how email ought to work, mostly because nobody wants to depend on a system somebody else controls. Staffing then scales right along with the brand count, largely to rebuild things the brand next door already has working just fine. Eventually, finance notices that 15 brands are paying to solve the same problem 15 separate times, and starts asking a question nobody in marketing particularly wants to answer out loud.

The channel era: Real expertise, narrower view

The standard fix, in response, was usually to centralize by channel. Instead of each brand running its own paid search, email, and social operation, the company builds channel centers of excellence to serve all brands. This genuinely worked, in the sense that channel specialists know things generalists don’t, and spreading that knowledge across every brand that needs it is a fairly clean win.

The catch is that channel expertise, by design, stops at the channel’s edge. A channel team gets graded on the channel, and what happens to the customer five minutes after they leave it becomes somebody else’s problem, if it’s anybody’s problem at all.

When the company’s actual growth issue cuts across three channels at once, a channel-centric org has no one at the intersection to direct traffic. Every team is excellent in its own lane, but it’s difficult for someone to own the merge.

Recommended Articles

Your CEO wants answers your dashboard can’t give

Oct 23, 2026

The creative cost of chasing small performance gains

Oct 21, 2026

When the CMO sees growth and the CFO sees a problem

Oct 21, 2026

The segment and lifecycle era: Closer, but not quite there

The next correction usually cuts the org along the customer’s lifecycle instead, splitting acquisition from retention, new customers from existing ones, and sometimes splitting further still by value tier. This is real progress, since it organizes around the customer’s actual journey rather than a media-buying or channel category. It’s also become enough of a trend heading that companies are giving lifecycle teams their own budgets and revenue targets, specifically so they stop treating acquisition and retention as though they don’t affect each other.

Most of the time, though, this cut still lives inside the old channel walls. Acquisition teams organize around acquisition channels, and retention teams organize around CRM, so what changes is who’s accountable. What doesn’t change is how much of the underlying machinery still gets rebuilt separately for each group.

The harder question sits right where it was before: who actually owns the pricing logic, the recommendation engine, the loyalty math, and the identity graph when five different brand and lifecycle teams all need the same thing to work properly at once?

Enter the domain

Somewhere along the way, somebody decided the fix for “everyone keeps rebuilding the same capability, badly” was to give the capability its own team. Marketing didn’t come up with that idea, whatever a conference keynote might imply. It comes from software engineering, by way of Domain-Driven Design and Conway’s Law, the observation that a company’s systems end up looking exactly like its org chart, whether anyone planned that or not.

Engineering teams spent 20 years learning to stop organizing around technical layers, like frontend, backend, and database, and to start organizing instead around real business capabilities, or bounded contexts. The Team Topologies framework later gave the idea concrete shapes: stream-aligned teams that own a capability end-to-end, platform teams that build the shared plumbing underneath it, and enabling teams whose entire job is making sure everyone else actually knows how to use what was built.

A domain is a business capability with its own logic, data, and specialized expertise. It sits underneath every brand and every channel rather than living inside one of them, whether that’s personalization, pricing and promotions, loyalty and rewards, search and recommendations, identity and consent, or the content supply chain.

A domain team doesn’t run a brand’s P&L or a channel’s media budget. Instead, it owns the capability itself: the models, the rules, the systems, and the roadmap that every brand and channel team depends on.

In practice, that means a domain team is judged on a different question than a brand or channel team is, not a different standard of accountability. What a domain team owes the business is measured at the level of the capability itself: the aggregate revenue lift, conversion, and retention across every brand riding on it, and the cost taken out by not building the same thing five separate times.

Domains in practice: Who’s already doing this

The pattern is older than the vocabulary, and a few organizations, inside marketing and out, have been running some version of it for years now, with results specific enough to be genuinely useful rather than just inspirational.

Amazon built domain ownership into its bones before anyone called it that. Jeff Bezos’s internal mandate that every team expose its work through a defined service interface, combined with the two-pizza teams rule and the single-threaded owner model, turned the company’s insides into hundreds of independently owned capabilities, such as search, recommendations, fulfillment, and payments. Each one has a single owner and a defined interface that the rest of the company builds against, rather than a department that half-handles a slice of everything.

ING is the rarer case of a large, regulated, multibrand company applying this to commercial and marketing work, not just engineering. When the bank restructured about 3,500 people in 2015, it built roughly 350 small, cross-functional squads and grouped them into 13 tribes organized around business domains, like payments, mortgages, and daily banking. Marketing, commercial, data, and engineering people worked within the same tribe and domain rather than being scattered across departments, each holding a sliver of the work and blaming each other when the pieces didn’t add up.

Mondelez runs a smaller, more marketing-specific version of the same move in consumer goods. Instead of letting every brand in its portfolio build its own AI and personalization stack, it invested in a shared digital core, a common data and AI layer built with outside partners, so its brands plug into it for personalized content and targeting rather than reinventing the wheel on its own dime. It’s a domain team organized around a capability rather than a brand, even if part of that team technically sits outside the building.

It’s worth saying plainly that not every famous example aged well. Spotify’s tribes and squads model, with tribes built around domains like search and discovery, as well as onboarding, is probably the most-copied org chart in tech history, and yet Spotify’s own engineers have since said it doesn’t much resemble how the company actually runs today. 

That doesn’t prove domain structures fail. It simply shows that an org chart on a slide was never the operating model to begin with, and that copying the shape without the platform investment and the enabling layer underneath it just gives the same old silo a new name.

When it fits and when it doesn’t

Domain structures aren’t a universal upgrade, and treating them like one is exactly how a good idea turns into a painful reorg. They earn their keep when a real portfolio of brands or products leans on the same underlying capabilities, particularly when the company has the data and technology foundation to support shared ownership.

Domain ownership assumes there’s a real platform underneath it: shared data, shared identity, and shared tooling that a domain team can build on. Skip that foundation, and a “domain team” is just a silo with a rebrand, quietly re-plumbing things that should already exist.

The model also fits organizations willing to separate who’s accountable for a result from who controls the system that produces it. A brand or lifecycle leader can be on the hook for a growth number without personally owning the roadmap of the system they depend on, but that’s a genuinely uncomfortable trade for most leaders.

It fits less well when there’s little meaningful duplication to solve, as with a company that has one dominant product and a couple of sidelines, or when brands are genuinely separate businesses with different customers, different economics, and barely any shared technology. In those cases, a shared capability team mostly adds a layer of meetings.

If leadership hasn’t settled who takes the blame when the number is bad and the domain team insists the system is working exactly as designed, domains will surface a governance fight that brand and channel models mostly avoided by keeping ownership local and obvious.

There’s a real transition cost, too. Moving from brand or channel ownership to domain ownership takes decision rights away from people accustomed to having them.

It also requires real investment in the enabling layer: people whose job is to help brand and channel teams use the domain capability well, not just handing it over and walking away. Skip that layer, and you get domain teams that are technically excellent and organizationally invisible, quietly building things that nobody downstream ever quite adopts.

Quick reference: Domain-fit signals

What this means for the martech leader

None of this makes domain organization the correct answer in some permanent sense. It’s simply a strong answer to a specific problem: brand, channel, and segment structures eventually leave duplicated capability-building on the table.

Once a company has enough scale and shared complexity, that duplication gets expensive enough for someone to finally notice. That’s a real and growing problem, which is why domain thinking keeps spreading.

It’s also a model that assumes real technical maturity. It trades one set of costs, namely duplication, for a different and less familiar set: coordination and accountability.

AI adds real urgency to the problem. The model underneath any given AI feature is close to a commodity at this point, and it changes every few months, no matter what any one company does.

The actual differentiator is the harness around it: the data, the business context, and the integration work that lets a model do something specific and reliable within a real company rather than producing a generic answer.

That harness is exactly what a domain team is built to own. It’s also what makes a domain structure easier to navigate as AI spreads across more of the business.

A company that leaves five separate brand or channel teams to build that harness on their own is asking each of them to solve the hardest part of AI adoption badly and separately, at the exact moment getting it right matters most.