An experiment gets proposed in a growth meeting: test a new outbound angle against a specific vertical. Everyone likes it. Then it has to actually get built — which means pulling a list-builder from ops, copy from marketing, sequencing from a sales tool someone in RevOps owns, and reporting from an analyst who's booked two weeks out. By the time all four people find time, the moment that made the experiment interesting has usually passed.

The structure decides the speed, not the team's talent

Most GTM orgs are still structured functionally: a marketing team, a sales team, an ops team, each with its own manager and its own priorities. That structure is good at a lot of things, but it's specifically bad at shipping a single experiment that cuts across all three, because no one person owns it end to end. Every cross-functional experiment becomes a coordination project before it becomes a test, and coordination projects move at the speed of the slowest calendar, not the speed of the idea.

Pod-based structures — a small cross-functional team with a shared owner and its own mandate — exist specifically to fix this, and they genuinely do increase experiment velocity where they're implemented well. But they carry their own failure mode: pods can drift out of sync with the rest of the org's priorities, duplicate infrastructure that already exists elsewhere, and become difficult to scale past a handful of teams without recreating the same coordination overhead they were built to avoid. A pod that ships fast in isolation but builds its own reporting pipeline separate from the rest of the org just moves the coordination cost downstream, to whoever eventually has to reconcile the pod's numbers with everyone else's.

Neither structure is universally right

The honest answer is that functional structure is better for a company that needs consistency and efficiency at scale, and pods are better for a company that needs speed and is still discovering what its GTM motion actually is. Applying the wrong one for the company's actual stage is where most of the pain comes from — a fast-moving pod structure imposed on a company that actually needed process discipline, or a rigid functional structure imposed on a company that still needed to experiment its way to product-market fit.

Most companies also don't pick their structure deliberately at all — it accretes from whoever was hired first and which manager happened to inherit which function, and it rarely gets revisited as the company's actual needs shift from discovery to scale or back again. The mismatch between structure and stage is usually not a decision anyone made; it's a decision nobody made, which is worse, because it means nobody's specifically responsible for noticing when it stops fitting.

What actually determines whether experiments ship

The clearest diagnostic isn't the org chart itself — it's asking how many people had to say yes for the last experiment to actually go live. One or two people is a structure built for speed. Five or six is a structure built for something else, and that's worth being honest about before blaming the team for slow execution.

Running that diagnostic on the last five experiments, not just the most recent one, is more revealing than it sounds — patterns emerge quickly about which types of tests consistently stall (usually the ones crossing the most team boundaries) versus which ship reliably (usually the ones one person can own start to finish), and that pattern is a better guide to restructuring than any org chart theory.

The tools underneath the org chart matter here too: a stack that requires manual handoffs between list-building, copywriting, and sequencing recreates the coordination problem inside a single function, even with the org chart fixed. That's part of why consolidating the outbound motion into one system — which is what Skyp does, running targeting, personalized copy, and multi-channel sequencing together — removes one whole category of handoff that used to require its own meeting to schedule.