GTM-инженер: почему большинство строит неправильную систему и что с этим делать

Два года назад «GTM-инженер» не значился ни в одном хантинговом списке. Сейчас он есть в планах найма каждой команды роста. Если вы разработчик, вы наверняка видели эту вакансию в ленте и думали: это вообще инженерная работа или маркетолог, который выучил Zapier?

Честный ответ: это работа по проектированию систем. Самое интересное начинается, когда объектом системы оказываетесь вы сами — разработчик.

Что такое GTM-система на самом деле

Если отбросить хайп, GTM-инженер строит одну вещь: конвейер, который превращает сырые данные о потенциальных клиентах в разговоры, приносящие revenue. Людей в середине — минимум.

Эталонная архитектура выглядит так:

1. Ingest: сбор данных о prospects и аккаунтах из обогащающих сервисов, телеметрии продукта и публичных сигналов: раунды финансирования, смена работы, активность в репозиториях.
2. Transform: дедупликация, соединение и скоринг. Плохие соединения отравляют всё дальше по конвейеру. Поэтому data-грамотность — это 80% работы.
3. Act: запуск последовательностей, маршрутизация лидов, черновики персонализированных сообщений. Всё чаще этот слой — LLM-агенты с ревью-гейтами.
4. Write back: логирование всего в CRM, чтобы система оставалась наблюдаемой.

Если это звучит как обычный ETL-пайплайн, только в роли стораджа CRM, вы всё поняли правильно. Канонический инструмент оркестрации — Clay, клей — n8n или Make, а новый слой — агенты.

Вот где всё ломается: эта эталонная архитектура заточена под sales-led подход: большие объёмы, широкий таргетинг, настойчивость как фича. Примените её к разработчикам — и система провалится на этапе контакта.

Разработчики оценивают инструменты технически, по умолчанию не доверяют маркетинговому языку и общаются друг с другом. «Персонализированное» письмо, собранное из вашего LinkedIn-скрейпинга, не ощущается как личное. Оно ощущается как шаблон с подставленными переменными. Потому что это буквально так и есть. И разработчик, который получает такое письмо, сам когда-то писал такие же шаблоны.

Версия этой дисциплины, которая работает на технических покупателях, переворачивает цели дизайна:

• Качество сигнала важнее объёма контактов. Отклик, вызванный реальным использованием продукта или событием в репозитории, может быть полезным. Отклик, вызванный строкой «работает в компании на 50–200 сотрудников», — нет.
• Артефакты важнее сообщений. Документация, бенчмарки, рабочие примеры, калькуляторы зарабатывают доверие так, как не заработает ни одна последовательность писем. Задача системы — производить и распространять эти артефакты, а не отправлять больше имейлов.
• Ревью-гейты как первоклассный компонент. Агенты уверенно отправят в мир неверный и не соответствующий бренду контент в промышленных масштабах. Инженерная работа здесь — дизайн гейтов, а не генерация.

Почему это касается вас

Причины две.

Первая: если вы строите или продаёте дев-тул, разница между этими двумя архитектурами — это разница между тёплым комьюнити и вашим доменом в спаме у каждого разработчика.

Вторая: если вы разработчик, поглядывающий в сторону карьеры — эта роль платит реальные деньги. В американских вакансиях база обычно $110–180 тыс. У неё нет credential-барьера. И она вознаграждает ровно то суждение, которое у разработчиков уже есть: какая автоматизация полезна, а какая — шум. Большинство людей в этой роли пришли из growth или RevOps и выучили технический слой. Разработчики, идущие с другой стороны, имеют преимущество, о котором никто не говорит: вы уже знаете, как работают системы, осталось понять, что стоит автоматизировать.

Как перестроить систему для разработчиков: чек-лист

Не нужно выбрасывать конвейер. Достаточно пересобрать его под другую логику. Вот что меняется:

Из этого списка я бы выделил одно: ревью-гейты. В традиционной системе их нет вовсе — там правят объёмы. А в системе для разработчиков они становятся обязательным слоем, потому что агенты без контроля разнесут по базе тонны уверенного мусора. Правило простое: если генерацию делает агент, то проверку должен делать человек или второй агент с жёсткими критериями.

Типичная ошибка — пытаться «улучшить» персонализацию, добавляя в шаблон ещё больше переменных. Не помогает. Разработчик видит паттерн, а не данные. Работает обратное: меньше касаний, но каждое — с реальным контекстом. Одно письмо после того, как человек запустил ваш CLI, стоит десяти писем после скоринга по числу сотрудников.

Что делать, если вы хотите стать GTM-инженером

Вход в эту профессию не через курсы, а через сборку собственных маленьких конвейеров. Начните с того, что автоматизируйте себе лидогенерацию из публичных данных: GitHub-события, вакансии, изменения в документации. Важно не инструменты, а умение соединять данные и отличать мусор от сигнала.

Дальше — найдите наставника из RevOps или growth. Там живут не технические, а доменные знания: как устроен sales-процесс, что такое стадии воронки, как считать конверсию. Именно этой части разработчикам обычно не хватает. Техническую часть они уже умеют.

И да, держитесь подальше от вакансий, где ищут «маркетолога со знанием Zapier». Это не та работа. Вам нужна позиция, где система — в центре, а сообщения — лишь один из выходов.

GTM-инженер — это профессия про архитектуру доверия. В неправильной системе вы строите конвейер, который генерирует шум. В правильной — конвейер, который генерирует полезное. Разница заметна по одному признаку: разработчики либо отвечают, либо молча добавляют ваш домен в блок-лист.