В комментариях разнесли ваш продукт. Отвечать или нет? Разработчик написал, что документация устарела, а пример из квикстарта не запускается. Ниже уже три согласных комментария. Рука тянется ответить сразу, но сначала стоит остановиться. Пройдите по четырём вопросам. 1. Критика по делу? Проверьте, воспроизводится ли проблема. Если да, ваш первый ответ: «Спасибо, нашли ошибку, передали команде». Оправдания и объяснения, почему так вышло, лучше оставить. 2. Что можно исправить прямо сейчас? Иногда хватает поправить строку в документации. Тогда вернитесь в ветку и напишите, что изменилось. Такой комментарий часто весит больше исходного поста. 3. Кто отвечает за решение? Если проблема в продукте, найдите владельца и сообщите автору, когда ждать ответа. Не обещайте сроки, которых не знаете. 4. Это обсуждение или просто эмоции? Если человек раздражён, коротко признайте неудобство и предложите продолжить в личных сообщениях. Спорить с тоном не нужно. Критику стоит собирать в одном месте: темы, частота, статус исправления. По такой таблице видно, что мешает пользователям чаще всего, и её можно показать команде продукта. Какой ответ на критику сработал у вас лучше всего?

Из чего складывается техническая репутация компании Разработчик читает статью компании о свободе инженерных решений. Через неделю приходит на интервью и узнаёт, что каждое изменение согласует один руководитель. Теперь ему предстоит понять, какое описание ближе к действительности. DevRel стоит обращать внимание на такие расхождения. Человек знакомится с компанией через доклады, репозитории, ответы сотрудников, вакансии и собеседования. Каждый следующий контакт может подтвердить или поставить под сомнение предыдущий. Какие подробности помогают составить мнение Фраза «у нас сильная инженерная культура» оставляет слишком много вопросов. Как команда выбирает технологии? Кто отвечает за качество? Что происходит после серьёзного сбоя? Выделяют ли время на технический долг? В содержательном материале можно разобрать конкретное решение. Показать исходные ограничения, рассмотренные варианты и последствия выбора. Читатель получит возможность оценить ход мысли команды. Для такого разговора подходят и сложные истории. Например, миграция, которая заняла вдвое больше времени, чем ожидали. В ней стоит разобрать причины задержки и ошибки в оценке. Затем объяснить, что команда изменила в следующих проектах. Где DevRel может найти расхождения Можно взять одну тему, например самостоятельность разработчиков, и сравнить её описание в блоге, вакансии и на техническом интервью. Если обнаружится расхождение, его нужно обсудить с инженерами и рекрутерами. Возможно, текст устарел. Возможно, практики различаются между командами. В первом случае нужно обновить материал. Во втором стоит прямо объяснить, как распределяются полномочия в конкретной команде. Тогда кандидат сможет оценить условия ещё до выхода на работу. По каким признакам вы сами оцениваете техническую репутацию компании?

Кто определяет приоритеты DevRel HR просит помочь с наймом. Маркетингу нужны статьи и выступления. Продуктовая команда ждёт обратную связь от разработчиков. У самого DevRel накопились идеи для сообщества. Так можно заполнить календарь на полгода. Только по этому календарю будет трудно понять, какую задачу решает команда. Сначала договориться о результате Допустим, компания развивает инструмент для разработчиков. Регистрации есть, но пользователи бросают настройку до первого рабочего запуска. DevRel стоит разобраться, где возникают трудности. Пройти путь пользователя, собрать вопросы, обсудить проблемы с инженерами. Возможно, ближайший месяц полезнее потратить на документацию и примеры интеграции. У компании, которая открывает новое направление разработки, будет другой приоритет. Потенциальным кандидатам нужно познакомиться с командой и её задачами. Здесь пригодятся инженерные статьи, выступления сотрудников и встречи с профессиональным сообществом. Форматы могут совпадать. Содержание и критерии результата будут разными. У нового запроса должна быть цена Если в согласованный план добавляют конференцию, подготовка потребует времени. Придётся перенести статью, отложить исследование или сократить другую работу. Этот выбор полезно обсуждать с заказчиком запроса. Иначе у каждого отдела будет собственное представление о занятости DevRel, а вся ответственность за сроки останется у одного человека. На встречу с руководителем можно принести главный приоритет, оценку доступного времени и список работ, которые получится выполнить. Если появится срочный запрос, вместе решить, какую задачу он заменит. Как вы решаете, какой запрос к DevRel взять в работу, когда у каждого отдела свой приоритет?