Привет! Если ты уже был подписан на этот канал раньше — да, мы пропали на несколько лет.

Не будем врать про «были заняты важными проектами» или «переосмысливали стратегию». Просто не писали. И канал умер. Теперь у канала новые администраторы.

Теперь мы перезапускаемся.

Но уже не так, как раньше. Без дежурных постов раз в полгода и без попыток казаться умнее, чем мы есть. Будет регулярный контент, жёсткий стиль и фокус на том, что реально болит у тех, кто занимается брендом работодателя и DevRel в IT.

Если раньше тебя здесь что-то зацепило — можешь остаться.
Если подписался недавно — просто знай, по какому принципу мы работаем.

Всё.

Пока готовим нормальные посты — держите мем))

«Нам нужен DevRel, который будет и техническим экспертом, и контент-мейкером, и ивент-менеджером, и чуть-чуть sales, и немножко маркетинга»

Перевод: мы не понимаем, чем на самом деле занимается DevRel, поэтому просто сложили все непонятные задачи в одну вакансию.

Зарплата: «рыночная + мотивация от результата»

Может ли DevRel защищать разработчиков, если ему платит компания?

Может. Для этого нужна честно обозначенная позиция: DevRel работает на компанию и отвечает за качество диалога с сообществом.

Три ситуации быстро показывают, есть ли у роли профессиональные границы.

1. Сырой релиз

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

2. Закрытие API или смена условий

Задача DevRel: выяснить, кого затронет решение, сколько времени займёт миграция и какая поддержка потребуется. После анонса важно вернуться с ответами и статусом. Фраза «мы вас услышали» работает, когда за ней следует действие.

3. Критика в сообществе

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

Рабочие правила:

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

Компания платит DevRel зарплату. Сообщество даёт ему доверие. Без доверия эта работа быстро превращается в обычное промо.

Какой из этих случаев, по вашему опыту, самый сложный для DevRel? Расскажите в комментариях.

Что DevRel должен показать за первые 90 дней?

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

Первые 30 дней

Составить карту сообщества и внутренних участников. Определить, кого компания считает активным участником, какое действие считается полезным и кто отвечает за обратную связь. Зафиксировать исходные показатели.

К 60-му дню

Запустить рабочий ритм: контент, встречи, общение в сообществе, передача обратной связи. У каждой активности должны быть гипотеза и метрика.

К 90-му дню

Показать динамику:

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

Кейс удобно собирать по схеме: контекст, действие DevRel, изменение поведения, польза для бизнеса, следующий шаг.

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

Хороший отчёт за 90 дней помещается на одной странице: цель, исходная точка, динамика, кейсы и приоритет следующего квартала.

Что вы считаете хорошим результатом DevRel за первые 90 дней? Напишите в комментариях

Как DevRel влияет на продукт, найм и доверие?

Влияние DevRel проще оценивать через три понятные бизнесу цепочки.

Продукт

DevRel собирает сигналы сообщества, находит повторяющуюся проблему и передаёт её команде с конкретным сценарием. После изменения продукта, документации или SDK команда проверяет, стало ли пользователю проще начать работу.

Метрики: время до первого успешного действия, конверсия в активацию, повторяемость вопросов, количество принятых в работу сигналов.

Найм

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

Метрики: источник знакомства с компанией, количество квалифицированных откликов, конверсия от отклика к интервью и офферу.

Доверие

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

Метрики: доля вопросов без ответа, возвращаемость участников, доля обращений с решением, органические рекомендации, результаты опросов.

В отчётах полезна формулировка «DevRel внёс вклад». MAU, выручка, найм и удержание зависят от нескольких команд.

Для проверки любого проекта достаточно трёх вопросов:

1. Что мы сделали?
2. Чьё поведение изменилось?
3. Какая бизнес-метрика могла сдвинуться и как мы это проверим?

Охват показывает интерес. Ценность появляется на следующем шаге, когда меняется поведение.

Где вклад DevRel заметнее всего: в продукте, найме или доверии? Поделитесь своим опытом в комментариях.

Инженер не хочет выступать. Что делать DevRel?

До дедлайна подачи докладов неделя. Вы пишете сильному инженеру, а в ответ: «Давай без меня». Теперь нужно понять, что стоит за отказом и есть ли смысл возвращаться с предложением.

«У меня нет времени»

Уточните, сколько работы потребует участие, и обсудите это с руководителем инженера. Если подготовку доклада предлагают добавить к полной загрузке, отказ вполне понятен.

Можно зайти так: «Предлагаю начать с короткого интервью. Я соберу структуру, ты проверишь техническую часть. До старта согласуем время на подготовку с твоим лидом».

«Мне нечего рассказывать»

Вместо просьбы придумать тему спросите про недавнюю задачу: где застряли, какие варианты отбросили, что пришлось переделать. Так проще найти опыт, который пригодится другим.

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

«Я не хочу на сцену»

Уточните, интересен ли человеку другой формат: статья по интервью, совместное выступление или короткий внутренний разбор. Возможно, публичность ему вообще не нужна. Это тоже ответ.

Вариант приглашения: «Можем начать с разбора для своей команды. Я помогу со структурой и репетицией. Если формат не подходит, поищем другой».

До старта договоритесь о четырёх вещах:

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

После отказа оставьте человеку возможность вернуться к предложению самому. Давление ради одного доклада усложнит следующий разговор.

Какую причину отказа вы слышите чаще всего?

В чате снова пишет только DevRel. Что проверить?

Вы принесли новость, запустили опрос, пожелали хорошей пятницы. В ответ несколько реакций. Перед следующим постом стоит выяснить, зачем участники вообще открывают этот чат.

Пять вопросов для проверки сообщества.

1. Есть ли у людей общая задача?

«Чат для разработчиков» почти ничего не объясняет. «Здесь можно обсудить нагрузочное тестирование и попросить коллег посмотреть сценарий» уже даёт повод обратиться.

2. Легко ли начать разговор?

Проверьте, понимает ли новичок, с чем сюда можно прийти. Покажите пример вопроса, на который сообщество готово ответить. Напишите прямо, нужны ли код, контекст и описание того, что уже попробовали.

3. Что происходит с первым вопросом?

Посмотрите на последние обращения участников: получили ли они содержательные ответы? Для старта можно договориться с несколькими экспертами, кто готов подключаться к вопросам по своей теме. Ответив, оставляйте место другим участникам.

4. Можно ли участвовать без выступления на публику?

Кому-то проще выбрать вариант в опросе, прислать вопрос организатору или дополнить чужое решение. Предложите небольшой шаг, после которого понятно, что будет дальше.

5. Получают ли пользу те, кто молчит?

Спросите нескольких участников лично: что они читают, что уже пригодилось, чего не хватает. Число сообщений не покажет, сколько людей нашли ответ в старом обсуждении.

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

Что в вашем сообществе запускает разговор без участия администратора?

«Нам нужен митап». А зачем?

Заказчик уже выбрал месяц, попросил площадку и предложил заказать мерч. DevRel осталось задать вопрос: что должно измениться после встречи?

До поиска спикеров соберите короткий бриф.

1. Кого зовём?

Нужны конкретные люди с понятной задачей: например, backend-инженеры, которым предстоит миграция сервиса. От этого зависят тема, глубина докладов и каналы приглашения.

2. Зачем участнику тратить вечер?

Что он сможет сделать после встречи: сравнить подходы, разобрать свой случай, поговорить с людьми, которые уже решали похожую проблему? Ответ должен быть понятен из анонса.

3. Какой следующий шаг важен компании?

Попробовать инструмент, присоединиться к профессиональному сообществу, познакомиться с командой как потенциальный кандидат. Выберите основной шаг и предусмотрите, как участник сможет его сделать.

4. Кто выделяет ресурсы?

Уточните бюджет, время инженеров на подготовку и ответственных за приглашения, программу и общение с участниками. Устное «команда поможет» стоит превратить в конкретные договорённости.

5. Как проверим результат?

Зафиксируйте, что будете отслеживать, кто соберёт данные и когда вы их обсудите. Сначала можно оценить посещаемость и обратную связь. Для следующих действий участников понадобится отдельный срок проверки.

Шаблон для рабочего чата:

«Делаем встречу для _. Помогаем им _. Со стороны компании ждём _. Для этого нужны _. После встречи _ отвечает за следующий контакт. Результат проверяем _ по ___».

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

Какого ответа вам чаще всего не хватает в запросе «давайте сделаем митап»?

Кто определяет приоритеты DevRel?

HR просит помочь с наймом. Маркетингу нужны статьи и выступления. Продуктовая команда ждёт обратную связь от разработчиков. У самого DevRel накопились идеи для сообщества.

Так можно заполнить календарь на полгода. Только по этому календарю будет трудно понять, какую задачу решает команда.

Сначала договориться о результате

Допустим, компания развивает инструмент для разработчиков. Регистрации есть, но пользователи бросают настройку до первого рабочего запуска.

DevRel стоит разобраться, где возникают трудности. Пройти путь пользователя, собрать вопросы, обсудить проблемы с инженерами. Возможно, ближайший месяц полезнее потратить на документацию и примеры интеграции.

У компании, которая открывает новое направление разработки, будет другой приоритет. Потенциальным кандидатам нужно познакомиться с командой и её задачами. Здесь пригодятся инженерные статьи, выступления сотрудников и встречи с профессиональным сообществом.

Форматы могут совпадать. Содержание и критерии результата будут разными.

У нового запроса должна быть цена

Если в согласованный план добавляют конференцию, подготовка потребует времени. Придётся перенести статью, отложить исследование или сократить другую работу.

Этот выбор полезно обсуждать с заказчиком запроса. Иначе у каждого отдела будет собственное представление о занятости DevRel, а вся ответственность за сроки останется у одного человека.

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

Как вы решаете, какой запрос к DevRel взять в работу, когда у каждого отдела свой приоритет?

Из чего складывается техническая репутация компании?

Разработчик читает статью компании о свободе инженерных решений. Через неделю приходит на интервью и узнаёт, что каждое изменение согласует один руководитель.

Теперь ему предстоит понять, какое описание ближе к действительности.

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

Какие подробности помогают составить мнение

Фраза «у нас сильная инженерная культура» оставляет слишком много вопросов. Как команда выбирает технологии? Кто отвечает за качество? Что происходит после серьёзного сбоя? Выделяют ли время на технический долг?

В содержательном материале можно разобрать конкретное решение. Показать исходные ограничения, рассмотренные варианты и последствия выбора. Читатель получит возможность оценить ход мысли команды.

Для такого разговора подходят и сложные истории. Например, миграция, которая заняла вдвое больше времени, чем ожидали. В ней стоит разобрать причины задержки и ошибки в оценке. Затем объяснить, что команда изменила в следующих проектах.

Где DevRel может найти расхождения

Можно взять одну тему, например самостоятельность разработчиков, и сравнить её описание в блоге, вакансии и на техническом интервью.

Если обнаружится расхождение, его нужно обсудить с инженерами и рекрутерами. Возможно, текст устарел. Возможно, практики различаются между командами.

В первом случае нужно обновить материал. Во втором стоит прямо объяснить, как распределяются полномочия в конкретной команде. Тогда кандидат сможет оценить условия ещё до выхода на работу.

По каким признакам вы сами оцениваете техническую репутацию компании?