The framing everyone uses is wrong

Almost every conversation about MarTech fragmentation starts the same way. A new CMO joins, runs an audit, and discovers twelve to twenty tools that nobody can fully explain. The reaction is predictable: consolidate. RFP. Replatform. Move to a unified suite.

Eighteen months later, the new unified suite has been extended with six third-party tools, two custom integrations, and a homegrown data layer to bridge what the suite does not natively support. The fragmentation that motivated the consolidation has returned, in a slightly different shape, with new vendors and the same operational pain.

This pattern has repeated across every replatform engagement we have run since 2019. The conclusion we have reached is uncomfortable: the fragmentation problem is not solvable at the tooling layer because the fragmentation is not caused by tools. It is caused by how teams are organized to operate them.

CRM CMS CDP DAM SEAM TEAM
Fig 1. The seam-spanning team sits at the center of the platform graph, with read/write authority across every adjacent system. Not a coordinator role — an engineering role.

Most enterprise marketing organizations are structured by channel — email, web, paid, social. Each channel team owns its tooling, its calendar, its KPIs, and its budget. The organizational seams correspond to the channel boundaries. A campaign that touches two channels has to cross a seam, which means a coordination meeting, which means latency, which means a workflow tool to manage the coordination.

The proliferation of tooling is downstream of this structure. Each team buys what it needs to do its work. The tools individually make sense; the collection in aggregate does not. Replatforming swaps the tools but preserves the channel-team structure, which is why the new collection becomes incoherent in the same way the old one did.

What "seam-spanning" actually means

The alternative is not a steering committee, a chief-of-staff role, or a "MarTech ops" team that sits adjacent to the channel teams. We have seen all three configurations and none of them shifts the underlying dynamic.

What works is an engineering team — not an operations team, an engineering team — that owns the seams between channels rather than the channels themselves. Concretely, this team has authority to:

The team that owns the seams owns the system. Everything else follows from that.

What we have seen across four engagements

Between 2022 and 2025 we ran replatforms at four enterprise clients where the seam-spanning team pattern was part of the brief. The implementation varied — different industries, different starting points, different budgets — but the underlying structure was consistent.

In every case the team had three properties:

  1. Senior engineering leadership. Not a manager-of-managers, an actual director-level engineer who could make tradeoff decisions about data modeling, identity resolution, and integration patterns under time pressure.
  2. Cross-functional product accountability. The team had a roadmap visible to channel teams, sprint reviews open to marketing leadership, and SLAs on key seam-handling services.
  3. Engineering staff allocated, not seconded. Engineers worked on this team as their primary role, not as a side allocation from a central engineering team that was nominally available "when needed."
Before and after — team topology Channel-organized teams (left) versus a single seam-spanning team (right) Before After Channel-organized Seam-spanning EMAIL WEB PAID SOCIAL SEAM TEAM EMAIL WEB PAID SOCIAL The seam team owns the substrate. Channel teams continue to exist — they just have somewhere to plug in.
Fig 2. The structural shift. Before: four channel teams with their own tool clusters and brittle inter-channel integrations. After: a central seam-spanning team that owns identity, data, and orchestration — channels orbit it.

What gets easier

When this team exists, MarTech vendor decisions become smaller and faster. The decision is no longer "what is our new platform" — it is "what tools does the seam team need to operate the orchestration substrate." That is a narrower question. It tends to produce decisions that consolidate naturally because the seam team has a strong preference for fewer integration points.

It also makes the case for build-vs-buy more honest. The seam team can reason about whether a piece of orchestration is worth building in-house, because they own the cost of operating it. Channel teams, on the other hand, will always prefer to buy because they do not bear the long-term integration cost.

What stays hard

The seam-spanning team is structurally difficult to staff. The role requires senior engineering judgment, marketing-domain literacy, and product management discipline in the same person. People who can do all three are rare and expensive. We have seen organizations fail at this pattern because they hired technical project managers for the role instead of engineers.

It also creates political friction. Channel teams that previously owned their tooling decisions lose some of that authority. The CMO has to back the structural change repeatedly, in budget conversations and in operating reviews, for at least the first 18 months. Without that backing, channel teams reassert the old pattern and the seam team becomes a service desk.

What this means for replatform conversations

If your organization is heading into a replatform discussion right now — whether driven by a new CMO, a contract renewal, or a stalled previous attempt — the most important question is not which platform to choose. The most important question is what the operating team looks like on the other side of the migration.

If the answer is "the same teams we have now, but on different software," the replatform will produce a different version of the same fragmentation in 18 months. That is not a vendor problem. That is a structural problem the vendor cannot solve.

If the answer involves a seam-spanning team — engineering-led, product-accountable, allocated full-time — the replatform has a meaningful chance of producing durable coherence. The platform choice becomes secondary, because the team can operate well across any reasonable choice.

The conversation we keep having with new clients is about the structural change first, the tooling choice second. The order matters. If this resonates and you want to talk through it, we are happy to share what we have seen.