DevRel (Developer Relations)

Также называют: Developer Relations, DevRel Engineer, Developer Advocate, Developer Evangelist, Head of DevRel.

Кто такой DevRel и чем он занимается?

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

• пишет туториалы, примеры кода, демо-приложения и улучшает документацию;
• выступает на конференциях и митапах, ведёт стримы и вебинары;
• отвечает разработчикам в сообществе, на GitHub, в Discord или Slack и разбирает, где они застревают;
• собирает обратную связь и приносит её Product Manager и инженерам в виде конкретных проблем;
• измеряет, как разработчики находят продукт, начинают им пользоваться и остаются.

Когда компании нужен DevRel?

DevRel нужен, когда продукт покупают или выбирают разработчики, а рост зависит от того, насколько быстро они его осваивают: devtools, API, облачные и инфраструктурные сервисы, open source с коммерческой версией, AI-платформы. Частые триггеры: у продукта есть бесплатный тариф или open source, но регистрации не превращаются в активное использование; инженеры тратят время на ответы в сообществе; маркетинг не может говорить с разработчиками на их языке. Первым DevRel часто становится инженер, который уже выступает и пишет. Роль не сработает, если продукт продаётся руководителям через отдел продаж, а разработчики его не выбирают: там больше пользы принесёт Solutions Engineer.

Чем DevRel отличается от маркетинга?

DevRel отличается от маркетинга тем, что работает на успех разработчиков с продуктом, а не на число лидов: он учит, отвечает и чинит путь пользователя, а не продвигает. Маркетинг отвечает за охват и воронку, DevRel — за то, чтобы разработчик дошёл до работающей интеграции и рассказал о ней другим. От Solutions Engineer его отличает масштаб: DevRel работает с сообществом, а Solutions Engineer — с конкретным клиентом в сделке.

DevRel и смежные роли: сравнение

Почему DevRel сложно нанять?

DevRel сложно нанять, потому что нужен инженер, который любит выступать и писать, а таких мало и в инженерии, и в маркетинге.

• Под названием DevRel компании ищут очень разное: от автора контента до инженера, пишущего SDK, и кандидаты не понимают, на что откликаются.
• Сильные инженеры редко хотят каждую неделю выступать и отвечать в чатах, а хорошие спикеры часто не дотягивают по коду, и сообщество это сразу видит.
• Результат DevRel трудно измерить, поэтому по резюме сложно отличить человека, который влиял на рост продукта, от того, кто просто много публиковался.
• Известные DevRel обычно связаны со своим сообществом и технологией и неохотно переходят на продукт, в который сами не верят.

Что выяснить до найма DevRel?

• Что должно измениться через год? Активация новых разработчиков, размер сообщества и качество документации — разные цели, и под каждую нужен свой профиль.
• Кому DevRel будет подчиняться: продукту, инженерии или маркетингу? От этого зависит, что от него будут требовать, и неправильный выбор часто приводит к тому, что DevRel превращают в автора постов.
• Какой технический уровень нужен? Писать примеры кода и разрабатывать SDK — разная глубина, и требовать обоих сразу значит искать очень долго.
• Есть ли у продукта сообщество или его надо создать с нуля? Запуск сообщества и развитие существующего — разные задачи и разный опыт.

Где искать DevRel?

DevRel чаще всего приходят из компаний, которые продают продукт разработчикам: облачные платформы, API-компании, devtools, базы данных, AI-платформы, open source-проекты с коммерческой моделью; часть растёт из разработки, Solutions Engineering и технического писательства. Сильный сигнал в профиле — публичная работа, которую можно оценить: выступления, статьи, репозитории с примерами, активность в сообществе вокруг технологии. NEWHR ищет таких кандидатов по результатам работы, а не по откликам на вакансию.

Как проверить DevRel на интервью?

DevRel проверяют практическим заданием: короткий туториал или демо на продукте компании, которое кандидат готовит и показывает, как на митапе, плюс технический разговор с инженером. Со стороны компании обычно участвуют руководитель, которому будет подчиняться DevRel, ведущий инженер продукта и Product Manager.

Сильные сигналы:

• в демо сам находит неудобные места продукта и предлагает, что поправить;
• объясняет сложное просто, не теряя технической точности;
• говорит о результатах своей прошлой работы через поведение разработчиков, а не через число просмотров.

Красные флаги:

• не может ответить на технический вопрос глубже, чем в собственной презентации;
• измеряет успех только количеством постов, выступлений и подписчиков;
• не пользовался продуктом компании перед интервью.

Сколько длится поиск DevRel?

Первых кандидатов на роль DevRel показываем через 5–7 дней после брифа.

Смежные роли

• Solutions Engineer — помогает конкретному клиенту внедрить продукт в рамках сделки.
• Technical Product Manager — решает, что строить в продукте для разработчиков, и получает от DevRel обратную связь.
• Content Engineer — строит систему производства контента, а не отношения с сообществом.
• Growth Lead — растит ключевую метрику продукта через эксперименты по всей воронке.
• GTM Engineer — автоматизирует продажи и маркетинг, а не работу с разработчиками.