The flaw in your AI GTM org design

You cut the team and added the tools. Two quarters in, nothing moved.

4 Sep 2026 · Josh Morse & Edwin Abl

The flaw in your AI GTM org design

"You are asking the wrong question. 'How can I use AI to expand the impact of my existing team?' assumes that they are the right people."

It was my headline message in a GTM strategy review session on Tuesday, directed at the newish Sales and Marketing leaders of a SaaS company sitting at almost £9m in ARR. They had come in looking for the answer to higher performance in the tactics and the tech, and had made most of the changes you would expect. They trimmed their teams. They put AI into how the smaller teams worked. Marketing moved spend towards GEO, personalised campaigns and events.

The company last raised 18 months ago. The board has not seen the expected increase in growth rate, and the GTM motion that was supposed to deliver it has become less effective each quarter. Buyers behave differently. The market is noisier. Everyone knows this, and for the last year the move to an AI GTM has been iterative. Some people changed, the strategy changed, then both changed again. The two leaders across the table arrived this year to speed it up and fix performance that had stalled everywhere.

Two quarters in, commercial performance is where it was.

At the moment, I am having some version of this conversation roughly once a week. The tools have changed. The teams are smaller. But when you look underneath, the organisation has not really changed at all.

They started from the team they had

Look at the company up close and the pattern is familiar. Marketing is smaller and AI sits inside the workflow. The team know the MQL belongs to a buyer who no longer exists, and they still report MQLs because that is the number in the board pack. Sales development is the same shape with new tools. Each function is running its own transition. Marketing is moving to an AI GTM. Sales is moving to an AI GTM. Nobody is moving the GTM.

The two leaders I sat with mostly think about execution. That is not a criticism, it is what the SaaS era hired for. Run the playbook. Build the team underneath it. Improve conversion. Add capacity when you need more output. Put managers over the capacity to keep quality up. Until recently, those assumptions did not need much examination because the model worked.

So when the brief became "move the organisation to AI", they did what their experience told them. They started with the team they had and asked how AI could close the performance gap.

That is the flaw.

They redesigned the execution without redesigning the organisation. The team they started from was built for a different economic problem: scale execution through people, organised into functions, with management layers preserving enough quality as the work moved down. Your classic bow tie.

The classic SaaS-era GTM org chart: a CRO above Marketing, SDR, Sales and Customer Success leaders, each with a large team beneath them, scaling execution through people and management layers.

I wrote in The end of the bow tie that the old GTM model is finished. Buyers do not move neatly through functional stages anymore, and the handoffs between Marketing, Sales and Customer Success make less sense when the customer is moving across all three at once. But the bow tie did more than organise work. It also determined where the best thinking sat.

Usually that was towards the top. Work moved down. Managers translated, checked and corrected. More people created more execution capacity, and the layers existed partly to stop quality degrading on the journey to the customer. A weaker marketer could produce a limited amount of average work. A weaker seller could make a limited number of calls. The manager's job was to catch enough of it.

AI changes the economics of that model because execution is no longer the scarce part. Start with the old organisation and add AI, and the most likely outcome is a cheaper version of what you had before. Same assumptions, fewer people, more output.

It is the bow tie with a lower payroll.

The same SaaS-era GTM org with AI bolted on: a CRO above Marketing, SDR, Sales and Customer Success leaders, each function reduced to a single person plus an AI tool, with the same structure and fewer people but no different outcome.

Fewer only works if better

This is where the headcount conversation goes wrong. Fewer people is not the strategy. If the people left behind understand the customer no better, make the same decisions and create the same customer experience, the organisation has not improved. It has only become smaller.

I learned this painfully at CloudSense. We were UK headquartered and had started winning some decent enterprise deals in the US with two UK sellers flying in and out. The win rate was in the mid thirties and there were plenty of ICP accounts for us to go after, so we hired a small sales team on the ground. On paper they were doing the same job. Similar territory, same product, same deal sizes. They came in with enough years of sales experience.

Within three quarters, the US win rate was in the low teens and US growth had stalled. Nothing material about the opportunity had changed. What changed was who was in the seat. The two UK sellers had a depth of context around the product and the industry that the new hires did not, and a level of skill I had underestimated because I saw it every day. It cost us a year in a major growth market.

That is what treating people as interchangeable units of capacity costs. The org chart says the seats are equivalent. The customer finds out that they are not.

AI makes that difference more important, not less. If execution is cheap, more of the value sits with the person deciding what should be done, what matters to the customer and whether the output is any good. Giving someone more capacity does not make them better at any of those things.

The question is no longer how many people one manager can supervise. It is how far one person's judgement can reach before it starts to degrade.

I think of that as span of leverage.

Span of leverage

Span of control counted the people a leader could effectively supervise. Span of leverage is how much of the customer's world one person can carry, and how far you can extend what they know and do without making it worse.

Span of control org chart: a leader at the top over six managers, whose context is translated and passed down through execution to the customer at the bottom, so distance from the customer grows as work moves down.

You can see it in a deal review. Give the best people limited information and they can anticipate the customer's situation. They know which part of the discovery matters and which part is noise. They can tell you what is really important to a customer, rather than repeat what the customer told them. Put an AI-generated output in front of them and they spot immediately that it is technically correct but commercially useless.

The old model worked because you could put more people underneath the ones who knew what they were doing. Inevitably, some of what they knew got lost on the way down. The ICP got broader. Discovery got worse. Marketing produced something that looked fine until somebody closer to the customer read it. So we added managers, in part, to spot those things before the customer did.

That trade looks different when execution gets much cheaper. I want the people who understand the customer best spending more time with them, not managing the people who do. A strong marketer can run far more activity than before if they own the direction and review what comes back. A strong seller can lose a lot of the preparation work and spend that time in actual customer conversations. Bring in outside expertise for the narrow things neither should be expected to know.

Span of leverage diagram: one operator at the centre extending their judgement across AI workflows, content and campaigns, analysis and insights, RevOps systems and data, preparation and research and external expertise, while staying close to customers.

It also means making harder calls on people. Some of the people who were good enough for the old model will not be good enough for this one. Teaching them to use AI does not change that. If anything, it makes the gap more visible because they can now produce more work without getting better at deciding what the work should be.

And I would not automatically protect the management layer. A lot of those jobs existed because companies had large numbers of people producing work that needed direction, checking and correction. Remove enough of that work and you have to ask what the manager is there to manage. In some cases the person you want instead will be able to set the direction and execute it themselves.

That does not mean replacing the pyramid with a handful of heroes. If your best seller has built their own collection of prompts, tools and workflows and it all leaves when they do, you have made the seller more productive. You have not made the company better.

This is where I see the RevOps job changing. Your best enterprise seller should not also have to build the machinery that gets them further. RevOps can take what works, build it into the workflows and data, and make it available to the rest of the team.

The system still has to be the asset.

Design for span of leverage

1. Start with the moments that matter to the customer. Don't start by moving boxes around the org chart. Work through how your customers actually buy and find the handful of moments where being better really counts. The first serious conversation. The point where they need to believe your proof. A difficult commercial discussion. A renewal that could go either way. These are the places where I want my best people involved, because getting one of them wrong matters far more than producing another hundred pieces of activity.

Stages were the bow tie's unit of organisation because the company needed somewhere to put the work. Marketing owned one part. Sales owned another. Customer Success inherited what was left. The customer never agreed to that arrangement. At each of the moments that really matters, ask who you would trust to handle it on their own. Then ask what they know that makes you trust them. That is a much better place to start designing the team.

2. Put the right person in the seat before you add the leverage. Only now should you look at the people you have. Would you trust them to make the important call without somebody checking it afterwards? Can they see what matters when the information is incomplete? Do they understand the customer well enough to challenge them? Can they tell the difference between polished output and useful output?

If the answer is no, giving them more capacity does not solve the problem. It gives the problem more capacity too. This is where the difficult people decisions start. Companies naturally keep the structure they recognise, which can mean cutting junior capacity while leaving most of the management layer untouched. You end up with fewer people but much the same shape.

Don't default to keeping the managers. If the job existed to direct, check and correct a layer of human execution that has now disappeared, work out what is left. Some of the people you need instead will be able to set the direction and do the work in the same head.

3. Extend how your best people work, not just what they produce. Once the right people are in the important seats, use AI to make more of what makes them good available to everyone else. A strong marketer should be able to turn one customer insight into far more execution than before, but the insight and review still need to be theirs. A strong seller should spend less time preparing generic work and more time with customers. RevOps should build underneath both.

Take the AI away for a moment. Can you still point to the people whose thinking makes the work good? Now imagine one of those people leaves. Does everything they built leave too? If it does, you have made an individual more productive without fixing the organisation.

4. Look for it in the boardroom. I wouldn't ask for an AI adoption dashboard. I would want to know which three or four people we most trust in front of an important customer, and whether they are spending more time there than they were a year ago. What work have we taken away from them? What have we built around the way they work so other people get better too?

Then look at the board pack you already have. If headcount is down, every function has an AI story and you are still discussing the same MQL chart, you have probably changed less than you think.

You have automated the bow tie.

What it looks like when you get it right

The difference shows up in where people spend their time. The people you trust most are closer to customers. Leaders are in more of the decisions that matter and fewer meetings about the volume of work happening underneath them. RevOps is building around how those people work rather than spending most of its time reporting on the activity.

The old structure also hid quite a lot. A manager rewrote the campaign before it went out. A good seller got dragged into a deal when it started to wobble. Someone more experienced fixed the work before the customer saw it. And there was only so much of it one person could produce anyway. The same person can now put far more work into the market, without being any better at knowing what good looks like.

The bow tie was built around the cost of execution. The organisation replacing it has to be built around the value of judgement.

This Week’s Tangible Prompt

Have you redesigned GTM for AI, or automated the bow tie?

If you want to test your AI GTM transition, here is a prompt you can run using what you already know about the company.

First, questions:

  1. What GTM people changes have been made in the last 12 months?

  2. Which management roles or layers have been removed, added, or left unchanged?

  3. What has the leadership team said it is doing with AI?

  4. Is there one AI GTM strategy, or separate plans for Marketing, Sales, and Customer Success?

  5. What GTM measures still dominate the board conversation?

Then produce:

  1. The assumptions about our AI GTM transition that I should test.

  2. Up to seven questions to ask the GTM leadership team at the next board meeting.

  3. For each question, one sentence on what a strong answer should demonstrate.

  4. The legacy GTM measures I should challenge, and what I need to understand before replacing them.

  5. The one question I should ask first if meeting time is limited.

Do not assume that reducing headcount or adopting AI means the GTM organisation has changed. Test whether the company has reconsidered which people should have more leverage, where its best people spend their time, which management roles are still required, and what RevOps is building around them.

Do not recommend AI tools or invent missing information. Where there is not enough information to reach a conclusion, turn the gap into a question for the leadership team.

Here is what I know about the company:

[Paste your answers to the five questions here.]

That’s all for this week.

See you next Sunday.

Cheers,

Ed & Josh


Demand Karma works with boards, investors and GTM leaders dealing with this now. If you have cut the GTM team, added AI and the number has not moved, the answer may not be another tool.

The AI GTM Leadership Kickstart is a short, structured programme for leadership teams to work through what changed, what still works and what no longer does, applied to their live GTM challenges. Leadership Development sustains it. Both are for the people who carry the number.

demandkarma.com

← All essays

Josh Morse & Edwin Abl

Reading is free. Waiting isn't.

If an essay hit a nerve, that nerve is usually worth an audit.

Book a call
×

Get the essays before your competitors do.

New essays land here first. Free, weekly, unsubscribe whenever.