Keerthi runs growth engineering at Omni, an AI analytics platform that lets teams query their data through natural language across any modality (in-product, MCP, CLI, Slack, etc) and receive governed and auditable answers.
Keerthi joined Omni as the founding growth engineer when the company was 40 people, and in two years it has grown to over 200 employees and 40x’d their revenue. Before Omni, Keerthi was the second growth engineer at Rippling, joining around 500 employees and staying for three and a half years as the company scaled headcount past 3,500. At Rippling, he inherited an existing GTM infrastructure rather than building it from scratch, but at Omni Keerthi has been able to make foundational infrastructure decisions himself from day one.
In this podcast, we discuss:
Why high-growth B2B companies need an exhaustive view of their total addressable market
How to architect a three-layer GTM data system that ingests, normalizes, and activates data
The 5 key pillars to getting your GTM data foundations right, including why querying a database beats needing to make API calls
How to choose the primary keys in your CRM
How Omni’s BDRs use natural language queries against live data to stack rank accounts and build prospect lists in minutes
Why Keerthi thinks working in GTM is a very valuable, often overlooked path for engineers
Episode highlights:
Keerthi explains that for companies expected to double revenue year over year, knowing their full addressable market is a non-negotiable. Doubling revenue requires more than doubling the spend, because returns on ad platforms are non-linear and LinkedIn in particular needs audience depth for spend to compound. Without full market visibility, pipeline runs dry faster than expected and paid channels lose efficiency, since both depend on having enough potential buyers to reach.
Keerthi walks through the three-layer architecture he built at Omni. The first layer is ingestion, handling data from APIs, S3 dumps, Snowflake shares, and webhooks. The second is normalization. Keerthi uses a DBT modeling layer that enforces standard formats for companies, people, and events across all sources. The third is activation, where clean data flows into the CRM, ad platforms, and email tools through configuration-driven workflows.
Keerthi chooses to buy datasets outright rather than pay for API access wherever economically feasible. When data lives in a database, running 20 targeting hypotheses means just 20 SQL queries. When it comes through an API, each hypothesis requires fetching fresh data first. At millions of records, that difference becomes a meaningful tax on the business.
Keerthi shares that most GTM data problems trace back to CRM hygiene, and the straightforward fix is enforcing primary keys. LinkedIn URL is the ideal primary key for contacts, and company domain plus LinkedIn company page is the ideal key for accounts. Without enforced primary keys, duplication rates of 5 to 10 percent are common, which at scale can erode sales trust in the data quality. With clean records, LLM pipelines can extract structured signals from unstructured data and agentic monitors can fire Slack alerts when key accounts change.
Keerthi points to Omni’s 30 BDRs as the clearest proof of what a well built GTM data system enables. Nearly all are daily active users of Claude connected to Omni via MCP. A BDR can ask which intent signals most commonly precede a qualified meeting, get their accounts stack ranked, then build a sequence in Amplemarket, all in one natural language session. Reps describe the experience as something that has never existed at any of their previous companies.
Where to find Keerthi:
Transcript details:
(00:00) Intro
(03:13) Career journey from Rippling to Omni
(05:54) Why GTM needs engineering
(07:32) Scaling data systems to handle TAM & the value of building an exhaustive TAM
(13:20) Ingesting, normalizing, and activating data
(21:45) The 5 GTM data foundation pillars
(31:23) BDRs using Omni daily
(33:45) Going direct to source vendors
(36:20) How AI has changed GTM data
(40:24) Underrated reason why data is more easily accessible than ever
(42:27) The value of growth engineers for companies + individuals
(46:40) What Keerthi thinks about the GTM engineer title
(48:35) Favorite underrated tool, growth hacks, and wrap-up
This episode of the gtm engineer is brought to you by Dust
Most AI agent tools are built for individuals. Dust is built for teams by putting AI agent building on multiplayer mode and connecting to your company’s knowledge across platforms like Slack, Google Drive, Notion, GitHub, Salesforce, and Snowflake.
Anyone can build agents that draw on that knowledge to handle tasks like researching accounts, answering customer questions, or drafting prospect emails. Dust also gives ops and IT the governance controls (permissions, SSO/SCIM, audit logs, role-based access) they actually need to confidently roll something like this out across an org.
The agent builder itself is no-code, so anyone with a Dust seat can prototype an agent in an afternoon without ever opening Terminal, and you can give your entire team access to semantic search on top of your sales and marketing data.
Profound used Dust to automate over 1,800 hours per month of CSM work across account research, slide deck creation, meeting follow-ups and more. We wrote a deep dive on exactly how they did it.
If you want to check out Dust, you can use code “THEGTMENG” for your first month free
For inquiries about sponsoring the podcast and to recommend any guests, email noah@thegtmengineer.ai
