Stop Redrawing Your Org Chart: Build for Capability

TL;DR: Marketing org structures keep cycling because each one solves yesterday’s problem and creates tomorrow’s. The shift from brand management to channel centers to lifecycle teams has one recurring flaw: duplicated infrastructure. Domain-based design, organizing around shared capabilities instead of brands or channels, is how high-spend operators stop rebuilding the same machine five times.

The Org Chart Cycle Nobody Talks About Honestly

In 1931, a P&G executive named Neil McElroy wrote a memo proposing that each brand get its own dedicated owner and team. P&G approved it. Brand management was born, and it spread across consumer goods because the logic was sound: one person who genuinely understands the customer, with real authority to make the brand win. That structure held up for decades.

Then the bill arrived. Give every brand its own P&L and it starts demanding its own analytics stack, its own martech tools, its own email infrastructure. Fifteen brands end up paying to solve the same problem fifteen separate ways. Finance eventually asks the question nobody in marketing wants to answer: why are we funding fifteen versions of the same capability?

The answer was usually centralization by channel. Build centers of excellence around paid search, email, and social so specialists can serve all brands. This worked in a narrow sense. Channel specialists know things generalists don’t. But channel teams get measured on the channel, not on what happens to the customer afterward. When a growth problem cuts across three channels at once, a channel-centric org has no one positioned at the intersection. Everyone is excellent in their lane. Nobody owns the merge.

The next correction sliced the org around the customer lifecycle instead: acquisition teams, retention teams, sometimes split further by value tier. That is genuine progress. But acquisition teams still organized around acquisition channels and retention teams still organized around CRM. The underlying machinery kept getting rebuilt separately. The hard question stayed exactly where it was: who owns the pricing logic, the recommendation engine, the loyalty math, and the identity graph when five different teams all need the same thing working correctly at once?

Domain Design: The Idea Marketing Borrowed from Engineering

Software engineering spent twenty years learning not to organize around technical layers like frontend, backend, and database, and to organize instead around real business capabilities. Domain-Driven Design and Conway’s Law, the observation that a company’s systems end up mirroring its org chart whether anyone planned it or not, gave engineers the vocabulary. The Team Topologies framework gave it concrete shape: stream-aligned teams that own a capability end-to-end, platform teams that build shared infrastructure underneath them, and enabling teams whose 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. Think personalization, pricing and promotions, loyalty and rewards, search and recommendations, identity and consent, the content supply chain. A domain team doesn’t run a brand’s P&L or a channel’s media budget. It owns the capability itself: the models, the rules, the systems, and the roadmap that every brand and channel team depends on.

What a domain team owes the business is measured at the capability level. Aggregate revenue lift, conversion, and retention across every brand running on it. Cost eliminated by not building the same thing five separate times. That is a different accountability question than a brand or channel team faces, not a lower one.

Who Has Already Done This and What It Looked Like

Amazon built domain ownership into its operating model before anyone called it that. Jeff Bezos mandated that every team expose its work through a defined service interface. The two-pizza team rule and single-threaded ownership model turned the company into hundreds of independently owned capabilities: search, recommendations, fulfillment, payments. Each has one owner and a defined interface the rest of the company builds against.

ING applied the same thinking to a regulated, multibrand commercial operation. When the bank restructured roughly 3,500 people in 2015, it built about 350 cross-functional squads grouped into 13 tribes organized around business domains like payments, mortgages, and daily banking. Marketing, commercial, data, and engineering sat inside the same tribe rather than scattered across departments each holding a sliver of the work.

Mondelez ran a smaller, more marketing-specific version in consumer goods. Instead of letting every brand build its own AI and personalization stack, it invested in a shared digital core, a common data and AI layer, so brands plug into it for personalized content and targeting rather than rebuilding the capability brand by brand.

Spotify’s tribes and squads model is the most-copied org chart in tech and also the cautionary tale. Spotify’s own engineers have said the model doesn’t resemble how the company actually operates today. That doesn’t mean domain structures fail. It means an org chart on a slide was never the operating model to begin with. Copying the shape without building the platform infrastructure underneath it just gives the same old silo a new name.

What This Means for High-CAC Verticals

For operators in forex, iGaming, crypto, and legal, the domain question is not theoretical. These verticals run at customer acquisition costs that punish duplicated infrastructure immediately. A forex broker running three regional brands through three separate paid media setups, three attribution models, and three CRM configurations is not just paying a coordination tax. It is flying blind on which capability investment is actually moving the needle. A proper marketing infrastructure audit usually surfaces this problem within the first two weeks: shared capabilities being rebuilt in parallel, data that cannot be reconciled across brands, and budget allocated to redundancy rather than growth.

In iGaming, where iGaming acquisition programs span multiple brands, jurisdictions, and regulatory environments, a domain approach to identity and consent alone can eliminate weeks of compliance rework per campaign cycle. The personalization and recommendation layer that drives deposit frequency does not need to be owned by each brand team. It needs one owner, one roadmap, and one defined interface the brand teams use.

In legal, where law firm lead generation depends on intake quality as much as lead volume, a domain structure around lead qualification and routing means every practice area benefits when the scoring model improves, rather than waiting for each team to rebuild its own version. AI-driven lead qualification works the same way: build it once as a shared capability, route qualified leads to every vertical that needs them.

In crypto and trucking, where acquisition windows are short and cost per qualified applicant or depositor is under constant pressure, centralized performance ads management operates exactly like a domain: one team, one optimization loop, shared signal across all brands and channels rather than fragmented learnings that never compound. Precision audience targeting at the capability level, not the campaign level, is what separates operators who scale from those who just spend more.

When Domain Design Does Not Fit

Domain structures are not a universal upgrade. A single-brand operator with one channel and one product does not need a capability layer. The overhead exceeds the benefit. Domain design pays off when you have multiple brands, multiple channels, or both, all depending on the same underlying infrastructure: a shared data model, a shared identity graph, a shared personalization engine.

The other failure mode is copying the org chart without building the platform. Spotify’s lesson is exactly this. Squads and tribes without an actual shared platform underneath them are departments with better branding. The capability team needs a defined interface, a roadmap accountable to aggregate outcomes, and an enabling layer that ensures every downstream team can actually use what was built. Without those three things, you reorganize and six months later the silos are back, just with new names on the boxes.

The right question before any reorganization is not “what structure is fashionable right now?” It is “which capabilities are being rebuilt in parallel, what does that redundancy cost us, and what outcome improves if one team owns this end-to-end?” For operators running crypto acquisition programs or managing CDL recruitment across multiple carriers with trucking recruitment marketing, that question has a very specific dollar answer. Find it before you reorganize, not after.

Originally reported by MarTech, September 2026.