Everett Berry is the Head of GTM Engineering at Clay, where he built an infrastructure team to treat revenue operations as a software discipline. He views the field as removing technical bottlenecks from sales using structured data, automation, and AI. This profile breaks down his operational frameworks, covering everything from his pipeline architecture to moving toward AI-native sales organizations.

Visual summary of operating lessons from Everett Berry.

Part 1: Defining GTM Engineering

  1. On the core purpose: GTM engineers eliminate the technical barriers that prevent companies from scaling revenue as quickly as possible. — Reference: GTM Council
  2. On the builder discipline: Rather than acting as a traditional support function, GTM engineering is an infrastructure role that applies product engineering principles like sprints and version control to revenue operations. — Reference: The GTM Engineer
  3. On AI-native jobs: GTM engineering is one of the first truly AI-native professions, as generating creative messaging and researching accounts at massive scale would be impossible without modern models. — Reference: YouTube: Brianne Kimmel
  4. On centralized leverage: Centralizing tedious tasks allows a small, specialized team to operate high-leverage AI tools effectively instead of distributing that operational burden across dozens of individual sellers. — Reference: YouTube: Brianne Kimmel
  5. On uncovering the real bottleneck: The barrier to revenue growth is rarely a lack of ideas; it is the operational friction between a new idea and its execution at scale, which GTM engineers actively compress. — Reference: GTM Council

Part 2: The Core Tech Stack and Infrastructure

  1. On tool consolidation: A tight tech stack minimizes integration work and reduces points of failure. Clay’s internal operations run primarily on just four tools: Clay, Snowflake, Salesforce, and Gong. — Reference: The GTM Engineer
  2. On interface simplicity: Internal GTM engineers manage a Slack application that allows reps to trigger campaigns, view signals, and access research directly, removing the need to navigate multiple browser tabs. — Reference: The GTM Engineer
  3. On flexible standards: Sellers should be allowed to use their preferred point solutions, such as specific meeting recorders or note-taking apps, as long as the underlying data flows back into a centralized transformation layer. — Reference: The GTM Engineer
  4. On infrastructure over point solutions: Companies looking to win will build tailored stacks on flexible data infrastructure rather than trying to configure their unique sales motions into rigid specialty platforms. — Reference: GTM Council
  5. On treating operations like code: GTM workflows and tables should be treated like software engineering products, complete with version control, clear documentation, and formal release notes. — Reference: The GTM Engineer

Part 3: Organizational Design and Reporting

  1. On executive alignment: GTM engineering teams should report directly to founder-level leadership, keeping them free from departmental politics and empowering them to make major architectural decisions. — Reference: The GTM Engineer
  2. On the two types of GTM engineers: The discipline splits into forward-deployed engineers who assist customers directly with implementation, and internal engineers who build the infrastructure powering the company's own sales motions. — Reference: The GTM Engineer
  3. On the hub and spoke model: A central team should own the infrastructure, standard guardrails, and observability, while frontline sellers and business units own use case discovery and iteration within those boundaries. — Reference: RevOps Impact
  4. On avoiding shadow IT: A centralized applied AI team ensures the company captures compounding value from new builds, preventing reps from spinning up duplicate workflows that expose sensitive data without oversight. — Reference: RevOps Impact
  5. On embedded success: Deploying engineers directly into customer environments in a Palantir-style model helps users accurately scope their consumption and prove immediate pipeline value. — Reference: YouTube: Pavilion
  6. On team scale: The primary leverage in this function comes from advancements in AI models rather than scaling headcount; GTM engineering should remain a small tiger team rather than a massive department. — Reference: Apple Podcasts: Stacked GTM

Part 4: Data Quality and the Golden List

  1. On the first priority: The foundational task for any early-stage GTM engineering capability is building the golden list, a continually updated, segmented database of top target accounts. — Reference: Worklife Blog
  2. On testing the list: A high-quality golden list passes the dinner test, where an operator can instantly pull a list of highly qualified executives in a specific city for a founder event without manual research. — Reference: Worklife Blog
  3. On sequencing the build: Organizations must tackle data quality and clean contact information first, then automate existing broken processes, before attempting to build net-new plays. — Reference: GTM Council
  4. On adapting to change: A well-architected data foundation automatically catches when an account matures into the ideal customer profile, avoiding missed opportunities as target companies grow. — Reference: Worklife Blog
  5. On foundational prerequisites: Without systematic transcript capture and clean CRM data, no centralized AI structure can successfully rescue an organization's go-to-market engine. — Reference: RevOps Impact
  6. On expanding the aperture: Go-to-market mechanics are not exclusive to SaaS; flexible data infrastructure allows targeting of adjacent models, like two-sided marketplaces, that share similar operational needs. — Reference: Worklife Blog

Part 5: Automating the Sales Pipeline

  1. On automated presentations: Pulling consumption metrics, call transcripts, and CRM data enables the automatic generation of customized slide decks for kickoff calls and quarterly business reviews. — Reference: The GTM Engineer
  2. On connective infrastructure: A unified internal engineering team can build the bridging systems required to identify self-serve users who are ready to expand into enterprise, sales-led motions. — Reference: The GTM Engineer
  3. On signal-based prompts: GTM automation should monitor external signals like product usage spikes or contract milestones and push actionable notifications directly to reps in their existing workflows. — Reference: The GTM Engineer
  4. On sprint planning: Batching requests into two-week sprints ensures that routine pipeline operations like territory routing do not consume the bandwidth needed for high-leverage infrastructure builds. — Reference: The GTM Engineer
  5. On the next frontier: Progressing from drafting adequate follow-up emails to automatically generating complex proposals and case studies across a multi-month sales cycle represents a top-percentile engineering challenge. — Reference: The GTM Engineer

Part 6: Experimentation and GTM Alpha

  1. On shipping speed: AI has structurally increased the velocity at which revenue teams can deploy campaigns, refine messaging, and execute operational automations without manual coordination slowing them down. — Reference: N2Growth
  2. On finding GTM alpha: Go-to-market tactics inevitably expire, and AI tooling accelerates this commoditization; the true competitive advantage is building a system that continuously discovers new edges. — Reference: YouTube: Brianne Kimmel
  3. On shifting focus: "Growth becomes less about finding one perfect motion and more about building a machine that can learn faster than competitors." — Reference: N2Growth
  4. On sourcing new plays: The best ideas for scaled automations often come from rep ride-alongs, observing the highly effective manual tactics that individual top performers use to exceed quota. — Reference: GTM Council
  5. On testing assumptions: AI drastically lowers the cost of launching new campaigns, shifting organizations away from conservative planning toward a model of real-time testing and feedback. — Reference: N2Growth

Part 7: AI Implementation and Failure Culture

  1. On structural adaptation: Traditional software forces the company to adapt to the product, but AI adoption requires shaping the system around how the company works and where human judgment is needed. — Reference: N2Growth
  2. On pilot expectations: The most successful AI implementations begin with the explicit expectation that early versions will fail or fall short. — Reference: N2Growth
  3. On iterating past failure: Organizations extract the most value from GTM engineering when they allow a project enough iteration cycles to reach version four, rather than killing it after a rocky first month. — Reference: GTM Council
  4. On reading the messiness: Organizations that stall during pilots mistakenly view uneven metrics and initial friction as proof the technology does not work, rather than a normal phase of refining the use case. — Reference: N2Growth
  5. On tracking adoption: Teams should employ analytics to measure internal tool usage and field engagement, allowing them to systematically kill failing automation and double down on what works based on data rather than opinion. — Reference: Worklife Blog
  6. On hiring criteria: The foundational skill for a GTM engineer is systems thinking; they must understand programmatic logic and how downstream services integrate, even if they are not traditional programmers. — Reference: Worklife Blog

Part 8: The Future of Sales and Revenue

  1. On evolving organizational design: Revenue organizations may converge into two distinct roles: highly technical operators managing scaled systems, and human sellers deployed exclusively where judgment, trust, and relationships matter. — Reference: N2Growth
  2. On hyperspecialization: Alternatively, organizations could divide the sales motion into narrow areas of expertise, with AI seamlessly managing the handoffs between human specialists. — Reference: N2Growth
  3. On the changing rep profile: The most effective sellers of the future will rely less on manual prospecting and more on deep industry expertise and credibility, utilizing automation to handle list building and research. — Reference: N2Growth
  4. On bifurcation of the buying motion: Simpler commercial purchases will increasingly be handled via self-serve or AI agents, while complex enterprise deals will push human sellers into longer-term, relationship-centric roles. — Reference: N2Growth
  5. On API-first product design: As AI agents increasingly operate software interfaces, product and pricing logic must evolve toward consumption-based, API-first primitives designed for automated systems rather than just human seats. — Reference: N2Growth

Part 9: Additional lessons on AI Readiness and Data Foundations

  1. On organizational AI readiness: Assess your data quality, technical infrastructure, and leadership readiness before beginning any AI implementation. — Reference: https://hgcapital.com/insights/the-blueprint-for-ai-gtm-adoption-a-three-level-framework-from-clay-and-hg
  2. On the root cause of pilot failures: The majority of early AI initiatives stall not because of tooling limitations, but due to foundational gaps like fragmented data across disconnected systems. — Reference: https://hgcapital.com/insights/the-blueprint-for-ai-gtm-adoption-a-three-level-framework-from-clay-and-hg
  3. On individual AI access: Rather than flooding the organization with complex automation tools, start by giving sales reps, marketers, and executives direct access to conversational AI. — Reference: https://hgcapital.com/insights/the-blueprint-for-ai-gtm-adoption-a-three-level-framework-from-clay-and-hg
  4. On role-specific training: Train individuals based on their specific use cases, as engineers, SDRs, and project managers will all require different approaches to the same AI platform. — Reference: https://hgcapital.com/insights/the-blueprint-for-ai-gtm-adoption-a-three-level-framework-from-clay-and-hg
  5. On preventing AI skepticism: Lack of early training often leads users to expect perfect outputs from basic prompts, creating doubt around the tool's value when results inevitably fall short. — Reference: https://hgcapital.com/insights/the-blueprint-for-ai-gtm-adoption-a-three-level-framework-from-clay-and-hg
  6. On documenting success and failure: Track both successes and failure modes during the initial adoption phase to effectively guide the broader organization. — Reference: https://hgcapital.com/insights/the-blueprint-for-ai-gtm-adoption-a-three-level-framework-from-clay-and-hg

Part 10: Additional lessons on Founder Discovery and Product Trials

  1. On validating the market need: Conduct extensive customer discovery—such as interviewing more than 100 retail operators—to confirm operational challenges before building a solution. — Reference: https://www.purdue.edu/newsroom/archive/releases/2016/Q4/purdue-graduates-developing-user-friendly,-cost-effective-retail-analytics-software.html
  2. On reducing trial friction: Minimize the cost and time required for installation so that retailers face lower risks when piloting new camera and analytics systems. — Reference: https://www.purdue.edu/newsroom/archive/releases/2016/Q4/purdue-graduates-developing-user-friendly,-cost-effective-retail-analytics-software.html
  3. On extracting actionable metrics: Translate computer vision data into specific operational metrics, such as customer navigation paths, popular store locations, and display dwell times. — Reference: https://www.purdue.edu/newsroom/archive/releases/2016/Q4/purdue-graduates-developing-user-friendly,-cost-effective-retail-analytics-software.html

Part 11: Additional lessons on Technical Growth Systems

  1. On centralizing event data: Send useful product events directly into a shared system so the growth team can iterate on campaigns without waiting for engineering tickets. — Reference: https://medium.com/@epberry/programmatic-messaging-with-customer-io-7df42927ec10
  2. On tailoring the user journey: Customize onboarding flows based strictly on the actions a user has already completed, generating fewer total emails but better engagement. — Reference: https://medium.com/@epberry/programmatic-messaging-with-customer-io-7df42927ec10
  3. On separating message types: Distinctly separate lifecycle campaigns, transactional messages, and broadcast emails within your architecture to maintain clarity and control. — Reference: https://medium.com/@epberry/programmatic-messaging-with-customer-io-7df42927ec10

Part 12: Additional lessons on Cloud Economics

  1. On unifying cost tracking: Implement a single pane of glass to unify cost visibility across major cloud platforms, observability tools, and AI providers. — Reference: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/cutting-costs-in-cloud-with-everett-berry/
  2. On software vs. consulting: View cost-management software and bespoke cloud economics consulting as complementary rather than competing services. — Reference: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/cutting-costs-in-cloud-with-everett-berry/
  3. On focusing optimization efforts: Prioritize attacking the largest cloud cost pools first before spending cycles trying to optimize smaller expenses. — Reference: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/cutting-costs-in-cloud-with-everett-berry/