How top GTM operators work: 6 habits from their own interviews
Top GTM operators start with the work, not the tool. They watch reps and experts before building, pick tools from what their teams ask for, write their systems down so others can reuse them, review outputs on a fixed cadence, use AI as a supervised assistant, and treat sales as the customer of everything they ship.
Every habit below comes from published interviews, talks and posts by named RevOps leaders, GTM engineers and growth leaders. If you want to hear more operators like these in person, the guide to the best communities for GTM engineers, RevOps operators and B2B creators shows where they gather.
Key points
Strong operators shadow reps and subject experts before they automate anything.
Tool choices follow repeated requests from the teams they support, and new tools often supplement rather than replace.
They keep shared, versioned documentation so new hires do not have to dig through Slack.
They review agent and workflow output closely at launch, then on a set cadence such as quarterly.
They prioritize by patterns across many reps, never by a single loud request.
Who are the operators behind these patterns?
Nine operators across GTM engineering, RevOps, marketing and AI leadership, each quoted from a public page.
Operator | Role (as stated in the source) | Source | Key practice |
|---|---|---|---|
Osman Sheikhnureldin | Head of GTM Engineering, Clay | Clay blog, "Top 1%: Inside GTM Engineering at the GTM Company" | Measures throughput, watches reps work, keeps a shared repo of skills |
Jeanne DeWitt Grosser | COO, Vercel | Shadows the best SDR, runs agents in shadow mode, reviews each agent quarterly | |
Amelia Lerutte | Chief AI Officer, SaaStr | Same SaaStr recap | One number, one goal, one workflow at a time |
Brandon Smith | RevOps Manager, QuotaPath | Buys on peer recommendations and repeated team requests | |
Jen Bergren | Marketing Ops Documentation Professor | Builds a system to keep documentation in use and updated | |
Fivos Aresti | Co-founder, Workflows.io | ICP scoring model, two to three variants per message block | |
Jarod Greene | CMO, Vivun | Feeds AI context from authoritative sources, no proprietary data | |
Gail Axelrod | Senior Content Marketing Director, Jellyfish | Same Growth Unhinged post | Uses AI to pull outlines from call transcripts |
Phil Lakin | Enterprise innovation lead, Zapier | Spreads AI through personal productivity use first |
Do top operators start with the tool or the work?
They start with the work. Before building, the best operators sit next to the people who do the job today and map where the friction is.
Clay's profile of Osman Sheikhnureldin describes how he decides what to build. "His answer starts with throughput, meaning how many leads make it through the funnel, not how many enter it." To find the blockers, "Osman talked with reps and watched them work." He then favors what the article calls compound problems: "issues woven through the system, where a single fix helps several parts of the funnel at once."
Vercel uses the same move at a larger scale. In SaaStr's recap of Jeanne DeWitt Grosser's session, Vercel builds agents with "a tripod: a GTM engineer, a data scientist, and the single best subject-matter expert for that function." For the lead agent, "an engineer literally shadowed Vercel's best SDR for days, watching every tab she opened."
What this looks like in practice:
Measure flow, not volume. Track how many leads move through each stage.
Watch before you ask. People skip steps when they describe their own work.
Model the best person. Vercel built its agent around its top SDR, not the average rep.
Pick fixes that help twice. One change that cleans routing and reporting beats two projects.
How do top operators pick their tools?
They pick tools from repeated pain in the teams they support and fit the tool to the process.
Brandon Smith, RevOps Manager at QuotaPath, describes his first step plainly in QuotaPath's stack write-up: "The way that I buy is I get recommendations from people that have used a tool like it before." Demand from the business sets the priority. "We decide based on what the teams we support are telling us," he says, and "if multiple teams are requesting the same thing, then it becomes a measure of business impact."
He also resists the urge to rip and replace. "Sometimes you don't necessarily want to completely replace a tool or system," Smith says. "We need something to supplement it, not replace it."
Clay's GTM engineers often build rough first. The write-up on Osman says "Building a hacky version first makes sense for a few reasons," and "Sometimes they don't wait for the product at all."
A simple tool filter based on these habits:
Count the requests. The same ask from several teams is a project.
Ask peers who have run it. Operator communities are the quickest way to find production users.
Supplement first. Add a layer before replacing a system customers touch.
Prototype rough. A scrappy internal version proves the workflow before you commit budget.
For a breakdown of what sits in a modern stack, the guide to the GTM engineer tool stack covers each layer.
How do top operators document their systems?
They write their systems down in a shared place that new people can use without asking. Documentation is treated as part of the build, not a cleanup task for later.
Clay's GTM engineering team maintains what its write-up calls "a shared repo of skills and tooling anyone can use." The reason given is practical: Osman "hopes new hires can skip digging through Slack." He also described the direction of this work in his own words: "It's helping us take one step closer to making GTM look more like software engineering."
Vercel puts documentation before automation. In SaaStr's recap, the tripod members "sit shoulder to shoulder and document best practice, then encode it into workflows."
Jen Bergren, who teaches documentation to ops teams, structures her course on MarketingOps.com around the same steps. The modules include "Write a clear process anyone can follow" and "Create a system to keep documentation in use and updated." One reason she gives for documenting is to "stop trying to remember how to do 100 different tasks per day."
Documentation sticks when every layer of the stack has one named owner with clear decision rights.
How do top operators review what they build?
They review closely at launch and then on a fixed cadence. Nothing goes from build to fully trusted in one step.
Vercel's lead agent shows the launch phase. SaaStr's recap says "The agent ran in shadow mode for six weeks with that SDR reviewing every output, until she couldn't improve it anymore." Only after that did the team remove the human from the loop. The same recap reports that the framework went to 30 SDR workflows and "SDR quotas rose 30% that quarter," a figure that comes from SaaStr's account of the session.
Review continues after launch. "Every quarter Jeanne asks whether someone built it better, faster, or cheaper," and if so, the agent is replaced.
Amelia Lerutte, SaaStr's Chief AI Officer, started from a weekly chore. She "was tired of copy-pasting dashboards from marketing, sales, and go-to-market into Notion every Sunday night," so she built a dashboard instead. Her agent advice: "Pick one number and give the agent one goal," and "Read the output, click the links, double-check the first few sends."
Clay adds the loop that makes reviews compound: for AI outbound, Osman wants the system to "trace what happened and the result, then loop it back so the system improves as it runs."
Review stage | What to check | Example from the sources |
|---|---|---|
Launch | Every output, by the best human doing the job | Vercel's six weeks of shadow mode |
First sends | Links, facts and tone in the first batch | Lerutte's "double-check the first few sends" |
Weekly | One number per workflow | Lerutte's single-number rule |
Quarterly | Whether a better, faster or cheaper option exists | DeWitt Grosser's quarterly test |
Reviews do not need a standing meeting. A fixed async cadence with a written update covers the same ground in less time.
How do top operators use AI day to day?
They use AI as a supervised assistant with good context, and they spread it through small personal wins before big programs. None of the operators here describe AI running unchecked.
Phil Lakin, who leads enterprise innovation at Zapier, told Growth Unhinged: "People think you need a big grand vision for how to adopt AI." Instead, "The reality is that you want as many people playing with this on a personal productivity level as possible."
Context quality matters as much as the model. Jarod Greene, CMO at Vivun, said in the same newsletter's ChatGPT roundup: "I didn't share any proprietary data with ChatGPT, but did give it context from authoritative sources (ex: Gartner)" for a positioning exercise. Gail Axelrod, senior content marketing director at Jellyfish, uses it to turn call transcripts into outlines: "What used to take hours" now takes seconds, and "as an internal team of one, ChatGPT is like my little assistant."
Lerutte's rollout rules from the SaaStr recap keep this safe as workflows grow:
Stair-step. "Stair-step the workflows one at a time rather than hooking up everything at once."
Set permissions. "Be explicit about what the agent can do alone versus what needs your approval."
If you are newer to the role, the explainer on what a GTM engineer does shows where this AI work fits.
How do top operators work with sales?
They treat reps as customers, listen more than they talk, and prioritize by patterns across the team.
Brandon Smith's approach in QuotaPath's write-up starts with listening. "When I hear a rep complain about something that I oversee, I make a mental note to look into it," he says. "I do a lot more listening than people realize."
Clay's profile of Osman adds two rules. First: "Never prioritize based on one person, since a single request isn't a trend." Second, when one rep's approach clearly works better, "Sometimes it's useful to scale what they're doing rather than sanding it down."
Fivos Aresti, co-founder of Workflows.io, shows the testing side in his Growth Unhinged playbook: "We defined our ICP and created a scoring model around it," and "We tested two to three variants for each building block of the message." Shared definitions give sales and ops the same facts.
Most revenue teams need this system and rarely have time to build it. I build these systems for my own work and do the same for SaaS revenue teams (lead routing, CRM cleanup, pipeline reporting) in a 90-day AI RevOps Sprint for Series A and B SaaS. Contact me to get yours scoped.
How can you apply these habits this month?
Pick one workflow and run it through all six habits. A single well-run loop teaches more than a stack audit.
Shadow one person. Watch your best rep or CSM do the task for an hour.
Measure one flow number. Count records moving through the stage.
Group repeat requests. List what reps asked for last month.
Ask peers before buying. The guide to Slack groups worth joining for RevOps and GTM lists good places to ask.
Write the doc first. Purpose, trigger, steps, owner and failure modes, in a shared space.
Run in shadow mode. The best human reviews every AI output before anything sends alone.
Set two review dates. A weekly number check and a quarterly "better option?" review.
Find a guide. The guide on finding a RevOps mentor covers how to ask.
When you meet operators in these groups, networking in a Slack community without pitching helps turn a thread into a conversation.
What are the common mistakes when copying top operators?
The most common mistake is copying tools instead of habits.
Buying a stack from a post. Smith starts with peer recommendations for his own need.
Automating before shadowing. You encode the average process instead of the best one.
Acting on the loudest request. A single request is not a trend.
Skipping shadow mode. Vercel kept a human on every output for six weeks.
Wiring everything at once. Lerutte stair-steps one workflow at a time.
Writing docs nobody updates. Bergren treats keeping docs in use as its own system.
FAQ
What do top GTM operators have in common?
They watch the work first, pick tools from repeated team pain, document in shared places and review on a cadence.
How do GTM engineers decide what to build first?
Clay's Osman Sheikhnureldin starts from throughput and looks for compound problems that one fix can solve.
How do RevOps leaders choose new tools?
QuotaPath's Brandon Smith starts with peer recommendations, then prioritizes requests from several teams.
How do operators roll out AI agents safely?
Vercel ran its lead agent in shadow mode for six weeks with its best SDR reviewing every output, per SaaStr's recap.
How often should GTM systems be reviewed?
One number per workflow weekly, plus a quarterly check for a better, faster or cheaper option.
Where can I learn from top GTM operators directly?
Operator communities, podcasts and newsletters; the guide on whether a paid community is worth it compares options.
Want to compare notes on how you run your GTM work?
If you are shaping your own operating habits or deciding which of these to try first, I am glad to swap notes on a short intro call. The tools I build with are listed on my stack page, and the services page shows how I work with teams.
Running revenue at a Series A or B SaaS company? Ask about the 90-day AI RevOps Sprint. I take two clients at a time.
About the author: Kevin Payne is an AI engineer and GTM operator who installs AI workflows for B2B teams. He has 10+ years in B2B SaaS demand generation and RevOps across Techstars, a16z and YC portfolio companies, and his writing has appeared in HubSpot, GetResponse, Outbrain and more.
