GTM Foundations - GTM Team Structure: Choosing the Right Model for Your Stage
Most conversations about GTM structure start with an org chart and end in a hiring plan. That order is backwards. Structure is a consequence of two things: the motion you have chosen, and the size of the deal you are chasing. Get those right and the org chart mostly draws itself.
This page covers the three structural models that hold up in practice, how reporting lines should run inside each, the specific signals that mean you have outgrown your current shape, and how to run the transition without stalling a quarter.
8 min read7 sectionsGTM Foundations
What you'll take away
- Structure follows motion and deal size. A €5k self-serve product and a €250k enterprise deal cannot share an org chart.
- Central RevOps belongs in every model, including the small ones — the scope changes, the need does not.
- The pod model is the highest-return structure between roughly €2M and €20M ARR, and the one most often implemented badly.
- Transitions fail when they are announced rather than sequenced. Move definitions and data first, people second.
What actually determines your structure
Before choosing a model, get honest about four inputs. Each of them constrains the shape more than any organisational philosophy does.
- Average contract value
- Below roughly €5k a year, human-led sales rarely pays for itself and structure should lean on product and marketing. Above €50k, you need discovery, technical validation and multi-threading — which means specialised roles.
- Sales cycle length
- A two-week cycle can be run by one person end to end. A nine-month cycle with a procurement stage and a security review needs handoffs, and handoffs need an operations function to survive them.
- Buying committee size
- One decision maker means one relationship. Six stakeholders across finance, IT, security and the business unit means you need people who can speak each of those languages.
- Primary motion
- Inbound, outbound, product-led and partner-led each demand a different centre of gravity. Running two seriously at once roughly doubles the coordination overhead — which is a structural cost, not a headcount cost.
Write these four down before drawing boxes. Teams that skip this step usually copy the org chart of a company three stages ahead of them and then wonder why coordination is eating their week.
Model 1: founder-led
Up to roughly €1–2M ARR, the founders are the GTM team. That is not a deficiency to be corrected quickly; it is the only period when the person who decides what gets built is also in every sales conversation, and that feedback loop is worth more than any process you could install instead.
The failure mode is not the model itself but what does not get done during it. Founders sell on intuition, adapt the pitch in real time, and remember everything. None of that transfers. When the first sales hire arrives, they are handed a motion that exists only in someone's head.
- Who does what
- One founder owns discovery, pricing and close. A generalist marketer covers content, website and events. Everything operational is manual and that is acceptable at this volume.
- What to build anyway
- A written ICP, recorded calls, a single CRM with honest stage definitions, and a document that describes the sales conversation. Two days of work that makes the first hire productive months earlier.
- When to leave
- When founder calendar time is the binding constraint on pipeline, or when the founder is closing deals they can no longer service well. Both are usually visible a quarter before anyone acts on them.
Model 2: pods and squads
Between roughly €2M and €20M ARR, the pod model outperforms the alternatives consistently. A pod is a small cross-functional group — typically demand generation, an SDR, one or two account executives and a customer success contact — that owns a segment, a region or a product line end to end.
The reason it works is ownership. When the same four people are accountable for the whole path from first touch to renewal in one segment, the handoff problem largely disappears because there is no organisational boundary to lose context across.
| Role | Count | Owns |
|---|---|---|
| Account executive | 2 | Discovery through close for the segment |
| SDR / BDR | 1 | Outbound and inbound qualification into those AEs |
| Demand generation | 0.5–1 | Segment-specific campaigns and content |
| Customer success | 1 | Onboarding, adoption and renewal for accounts the pod closed |
| RevOps (central, shared) | — | Definitions, data, reporting, tooling across all pods |
The two ways pods are implemented badly: giving each pod its own process, which destroys comparability across the business; and leaving RevOps inside a pod rather than central, which means nobody owns consistency. Keep the process central and the ownership local.
Model 3: specialised functional org
Above roughly €20M ARR, depth starts to beat breadth. Enterprise deals need dedicated solutions engineers, partnerships need a real function, and demand generation splits into paid, content, lifecycle and field. The org becomes functional teams under a CRO, with RevOps and GTM engineering as central shared services.
The cost is seams. Every specialisation you add creates another boundary where a deal can lose momentum, and the only thing that keeps that survivable is a strong operations layer with real authority over process and data.
- Reporting lines
- Marketing, sales and customer success under one revenue leader. RevOps reporting to that leader too — not to finance, where it becomes a reporting function instead of an operating one.
- GTM engineering placement
- Inside RevOps or as a peer team, never buried in the product engineering backlog. If GTM engineering competes with customer-facing features for priority, it loses every quarter and the revenue tooling never ships.
- What must stay central
- Definitions, the data model, forecasting methodology, and the tool stack. Let functions own their tactics; do not let them own their own version of the truth.
Where RevOps sits — and why it usually sits wrong
Revenue operations is the one function present in every working structure, and the one most commonly misplaced. Three placements are common and only one of them works well.
Under finance, RevOps becomes a reporting function: accurate, backward-looking, and structurally unable to change how the revenue team operates. Inside sales, it becomes sales operations and marketing data quietly rots. Reporting to the revenue leader with a mandate across all customer-facing functions is the placement that actually delivers.
Signals you have outgrown your current structure
Structural change is disruptive enough that most teams wait too long. These are the signals worth acting on, roughly in the order they appear.
- The forecast is a negotiation
- When leadership routinely adjusts the number reps submit, stage definitions have stopped meaning anything and you need a central operations function with authority.
- The same question gets three answers
- Ask three people for last quarter's win rate. Three different numbers means your data model has outgrown your governance.
- Handoffs need a person to chase them
- If someone spends part of every day making sure leads actually reach the right rep, the routing should be code and the structure should have an owner for it.
- Reps sell across everything
- When AEs cover every segment, size and use case, win rates flatten and nobody develops depth. That is the trigger for segmenting into pods.
- Pods have diverged
- Two pods reporting the same metric differently is the signal to centralise process while keeping ownership local — not to abandon the pod model.
How to run a restructure without losing a quarter
Restructures fail for a predictable reason: they are announced as an org change when the actual work is a data and definitions change. Sequence it in this order and the disruption stays contained.
Freeze and document the current state
Write down today's stage definitions, routing rules, ownership and reporting, however imperfect. You cannot measure whether the change worked without a baseline, and the act of writing it down usually surfaces two or three rules nobody knew were still running.
Agree the new definitions before the new boxes
Stage definitions with exit criteria, qualification thresholds, segment boundaries and handoff SLAs. Sign these off with the people who will be measured on them, in writing.
Rebuild the data model to match
Segment fields, territory assignment, ownership rules and reporting objects updated in the CRM before anyone changes seats. This is the step that needs engineering time and the step teams try to skip.
Migrate the pipeline explicitly
Decide account by account who owns what on the transition date. Ambiguity here produces exactly the kind of dropped deal that makes a restructure look like a mistake.
Move people, then hold the line for a quarter
Announce the structure once the system underneath supports it. Then resist changing it again for at least a quarter — you need one clean measurement period to know whether it worked.
Review against the baseline
Compare conversion by stage, cycle length and handoff SLA compliance against the frozen baseline. If the numbers did not move, the problem was not structural and you have learned something valuable.
Frequently asked questions
What is the ideal GTM team structure?
- There is no single ideal. The right structure is determined by your average contract value, sales cycle length, buying committee size and primary motion. In practice: founder-led up to about €2M ARR, cross-functional pods between €2M and €20M, and specialised functions under a CRO above that.
Should RevOps report to sales or finance?
- Neither. RevOps should report to the revenue leader with a mandate across marketing, sales and customer success. Under finance it becomes a backward-looking reporting function; under sales, marketing and CS data quality degrade.
How many people should be in a GTM pod?
- Four to six is the workable range: one to two account executives, one SDR, a shared demand generation resource and a customer success contact. Larger pods start needing internal coordination, which is the overhead the model exists to avoid.
When should we add a GTM engineering function?
- When integration and automation requests are queuing behind the product roadmap, or when someone in RevOps is spending most of their week on manual data work. That is usually somewhere between €3M and €10M ARR.
How often should GTM structure change?
- Rarely, and never mid-quarter. Most companies need a structural change at each order-of-magnitude jump in revenue. Changing more often than annually usually indicates a definitions or data problem being mistaken for a structural one.
A new org chart will not fix a broken data model
We rebuild the CRM architecture, routing logic and reporting layer that a restructure depends on — so the new structure works from day one instead of quarter three.