Привет, HR-специалисты, DevRel-гуру и мастера Employer Brand! 🌟
Этот канал теперь ваш надежный ресурс для всего, что связано с поиском IT-талантов, техно-PR и построением сильного HR-бренда. Здесь будут:
✅ Лайфхаки по привлечению разработчиков,
✅ Мероприятия,
✅ Кейсы из мира DevRel,
✅ Инсайды по техно-медиастратегиям,
✅ Идеи для Employer Branding в IT,
✅ и многое другое!
Этот канал теперь ваш надежный ресурс для всего, что связано с поиском IT-талантов, техно-PR и построением сильного HR-бренда. Здесь будут:
✅ Лайфхаки по привлечению разработчиков,
✅ Мероприятия,
✅ Кейсы из мира DevRel,
✅ Инсайды по техно-медиастратегиям,
✅ Идеи для Employer Branding в IT,
✅ и многое другое!
❤6🔥5🎉1
О чем интересней всего читать?
Anonymous Poll
37%
Лайфхаки по привлечению разработчиков
37%
Анонсы мероприятий
39%
Вакансии в индустрии
39%
Кейсы из мира DevRel
18%
Инсайды по техно-медиастратегиям
35%
Идеи для Employer Branding в IT
12%
Другое
👍8🔥3
Привет! Если ты уже был подписан на этот канал раньше — да, мы пропали на несколько лет.
Не будем врать про «были заняты важными проектами» или «переосмысливали стратегию». Просто не писали. И канал умер. Теперь у канала новые администраторы.
Теперь мы перезапускаемся.
Но уже не так, как раньше. Без дежурных постов раз в полгода и без попыток казаться умнее, чем мы есть. Будет регулярный контент, жёсткий стиль и фокус на том, что реально болит у тех, кто занимается брендом работодателя и DevRel в IT.
Если раньше тебя здесь что-то зацепило — можешь остаться.
Если подписался недавно — просто знай, по какому принципу мы работаем.
Всё.
Не будем врать про «были заняты важными проектами» или «переосмысливали стратегию». Просто не писали. И канал умер. Теперь у канала новые администраторы.
Теперь мы перезапускаемся.
Но уже не так, как раньше. Без дежурных постов раз в полгода и без попыток казаться умнее, чем мы есть. Будет регулярный контент, жёсткий стиль и фокус на том, что реально болит у тех, кто занимается брендом работодателя и DevRel в IT.
Если раньше тебя здесь что-то зацепило — можешь остаться.
Если подписался недавно — просто знай, по какому принципу мы работаем.
Всё.
🔥1
Пока готовим нормальные посты — держите мем))
«Нам нужен DevRel, который будет и техническим экспертом, и контент-мейкером, и ивент-менеджером, и чуть-чуть sales, и немножко маркетинга»
Перевод: мы не понимаем, чем на самом деле занимается DevRel, поэтому просто сложили все непонятные задачи в одну вакансию.
Зарплата: «рыночная + мотивация от результата»
«Нам нужен DevRel, который будет и техническим экспертом, и контент-мейкером, и ивент-менеджером, и чуть-чуть sales, и немножко маркетинга»
Перевод: мы не понимаем, чем на самом деле занимается DevRel, поэтому просто сложили все непонятные задачи в одну вакансию.
Зарплата: «рыночная + мотивация от результата»
❤2
Может ли DevRel защищать разработчиков, если ему платит компания?
Может. Для этого нужна честно обозначенная позиция: DevRel работает на компанию и отвечает за качество диалога с сообществом.
Три ситуации быстро показывают, есть ли у роли профессиональные границы.
1. Сырой релиз
DevRel собирает воспроизводимые проблемы, оценивает риски вместе с продуктовой командой и добивается понятного предупреждения. Разработчики должны знать ограничения и обходные пути до запуска.
2. Закрытие API или смена условий
Задача DevRel: выяснить, кого затронет решение, сколько времени займёт миграция и какая поддержка потребуется. После анонса важно вернуться с ответами и статусом. Фраза «мы вас услышали» работает, когда за ней следует действие.
3. Критика в сообществе
Угрозы, травля и публикация личных данных удаляются. Содержательная критика остаётся видимой. По ней назначают ответственного внутри компании.
Рабочие правила:
• ограничения названы прямо;
• у обещаний есть владелец и срок;
• обратная связь получает статус;
• личные сообщения, цитаты и контакты используют только с согласия автора.
Компания платит DevRel зарплату. Сообщество даёт ему доверие. Без доверия эта работа быстро превращается в обычное промо.
Какой из этих случаев, по вашему опыту, самый сложный для DevRel? Расскажите в комментариях.
Может. Для этого нужна честно обозначенная позиция: DevRel работает на компанию и отвечает за качество диалога с сообществом.
Три ситуации быстро показывают, есть ли у роли профессиональные границы.
1. Сырой релиз
DevRel собирает воспроизводимые проблемы, оценивает риски вместе с продуктовой командой и добивается понятного предупреждения. Разработчики должны знать ограничения и обходные пути до запуска.
2. Закрытие API или смена условий
Задача DevRel: выяснить, кого затронет решение, сколько времени займёт миграция и какая поддержка потребуется. После анонса важно вернуться с ответами и статусом. Фраза «мы вас услышали» работает, когда за ней следует действие.
3. Критика в сообществе
Угрозы, травля и публикация личных данных удаляются. Содержательная критика остаётся видимой. По ней назначают ответственного внутри компании.
Рабочие правила:
• ограничения названы прямо;
• у обещаний есть владелец и срок;
• обратная связь получает статус;
• личные сообщения, цитаты и контакты используют только с согласия автора.
Компания платит DevRel зарплату. Сообщество даёт ему доверие. Без доверия эта работа быстро превращается в обычное промо.
Какой из этих случаев, по вашему опыту, самый сложный для DevRel? Расскажите в комментариях.
❤2👍2🔥2
Что DevRel должен показать за первые 90 дней?
К концу третьего месяца бизнесу важно увидеть три вещи: DevRel понимает свою аудиторию, запустил устойчивый процесс и может показать первые признаки вклада.
Первые 30 дней
Составить карту сообщества и внутренних участников. Определить, кого компания считает активным участником, какое действие считается полезным и кто отвечает за обратную связь. Зафиксировать исходные показатели.
К 60-му дню
Запустить рабочий ритм: контент, встречи, общение в сообществе, передача обратной связи. У каждой активности должны быть гипотеза и метрика.
К 90-му дню
Показать динамику:
• новые и вернувшиеся участники;
• переход к полезному действию: заявке, запуску продукта, отклику или контрибьюции;
• медианное время содержательного ответа;
• повторяющиеся проблемы и их статус;
• один или два ранних кейса.
Кейс удобно собирать по схеме: контекст, действие DevRel, изменение поведения, польза для бизнеса, следующий шаг.
Выручка, качество найма и удержание часто требуют более длинного цикла. Охваты и подписчики остаются вспомогательными показателями.
Хороший отчёт за 90 дней помещается на одной странице: цель, исходная точка, динамика, кейсы и приоритет следующего квартала.
Что вы считаете хорошим результатом DevRel за первые 90 дней? Напишите в комментариях
К концу третьего месяца бизнесу важно увидеть три вещи: DevRel понимает свою аудиторию, запустил устойчивый процесс и может показать первые признаки вклада.
Первые 30 дней
Составить карту сообщества и внутренних участников. Определить, кого компания считает активным участником, какое действие считается полезным и кто отвечает за обратную связь. Зафиксировать исходные показатели.
К 60-му дню
Запустить рабочий ритм: контент, встречи, общение в сообществе, передача обратной связи. У каждой активности должны быть гипотеза и метрика.
К 90-му дню
Показать динамику:
• новые и вернувшиеся участники;
• переход к полезному действию: заявке, запуску продукта, отклику или контрибьюции;
• медианное время содержательного ответа;
• повторяющиеся проблемы и их статус;
• один или два ранних кейса.
Кейс удобно собирать по схеме: контекст, действие DevRel, изменение поведения, польза для бизнеса, следующий шаг.
Выручка, качество найма и удержание часто требуют более длинного цикла. Охваты и подписчики остаются вспомогательными показателями.
Хороший отчёт за 90 дней помещается на одной странице: цель, исходная точка, динамика, кейсы и приоритет следующего квартала.
Что вы считаете хорошим результатом DevRel за первые 90 дней? Напишите в комментариях
❤2👍2🔥2
Как DevRel влияет на продукт, найм и доверие?
Влияние DevRel проще оценивать через три понятные бизнесу цепочки.
Продукт
DevRel собирает сигналы сообщества, находит повторяющуюся проблему и передаёт её команде с конкретным сценарием. После изменения продукта, документации или SDK команда проверяет, стало ли пользователю проще начать работу.
Метрики: время до первого успешного действия, конверсия в активацию, повторяемость вопросов, количество принятых в работу сигналов.
Найм
Технический контент, выступления инженеров и открытые дискуссии помогают кандидату понять команду до отклика. Так появляется более точный самоотбор.
Метрики: источник знакомства с компанией, количество квалифицированных откликов, конверсия от отклика к интервью и офферу.
Доверие
Честное описание ограничений, содержательные ответы и обратная связь по проблемам делают поведение компании предсказуемым.
Метрики: доля вопросов без ответа, возвращаемость участников, доля обращений с решением, органические рекомендации, результаты опросов.
В отчётах полезна формулировка «DevRel внёс вклад». MAU, выручка, найм и удержание зависят от нескольких команд.
Для проверки любого проекта достаточно трёх вопросов:
1. Что мы сделали?
2. Чьё поведение изменилось?
3. Какая бизнес-метрика могла сдвинуться и как мы это проверим?
Охват показывает интерес. Ценность появляется на следующем шаге, когда меняется поведение.
Где вклад DevRel заметнее всего: в продукте, найме или доверии? Поделитесь своим опытом в комментариях.
Влияние DevRel проще оценивать через три понятные бизнесу цепочки.
Продукт
DevRel собирает сигналы сообщества, находит повторяющуюся проблему и передаёт её команде с конкретным сценарием. После изменения продукта, документации или SDK команда проверяет, стало ли пользователю проще начать работу.
Метрики: время до первого успешного действия, конверсия в активацию, повторяемость вопросов, количество принятых в работу сигналов.
Найм
Технический контент, выступления инженеров и открытые дискуссии помогают кандидату понять команду до отклика. Так появляется более точный самоотбор.
Метрики: источник знакомства с компанией, количество квалифицированных откликов, конверсия от отклика к интервью и офферу.
Доверие
Честное описание ограничений, содержательные ответы и обратная связь по проблемам делают поведение компании предсказуемым.
Метрики: доля вопросов без ответа, возвращаемость участников, доля обращений с решением, органические рекомендации, результаты опросов.
В отчётах полезна формулировка «DevRel внёс вклад». MAU, выручка, найм и удержание зависят от нескольких команд.
Для проверки любого проекта достаточно трёх вопросов:
1. Что мы сделали?
2. Чьё поведение изменилось?
3. Какая бизнес-метрика могла сдвинуться и как мы это проверим?
Охват показывает интерес. Ценность появляется на следующем шаге, когда меняется поведение.
Где вклад DevRel заметнее всего: в продукте, найме или доверии? Поделитесь своим опытом в комментариях.
❤2👍2🔥2
Инженер не хочет выступать. Что делать DevRel?
До дедлайна подачи докладов неделя. Вы пишете сильному инженеру, а в ответ: «Давай без меня». Теперь нужно понять, что стоит за отказом и есть ли смысл возвращаться с предложением.
«У меня нет времени»
Уточните, сколько работы потребует участие, и обсудите это с руководителем инженера. Если подготовку доклада предлагают добавить к полной загрузке, отказ вполне понятен.
Можно зайти так: «Предлагаю начать с короткого интервью. Я соберу структуру, ты проверишь техническую часть. До старта согласуем время на подготовку с твоим лидом».
«Мне нечего рассказывать»
Вместо просьбы придумать тему спросите про недавнюю задачу: где застряли, какие варианты отбросили, что пришлось переделать. Так проще найти опыт, который пригодится другим.
Например: «Ты рассказывал про сложную миграцию. Давай обсудим, какие решения вы приняли и что посоветовали бы команде в похожей ситуации».
«Я не хочу на сцену»
Уточните, интересен ли человеку другой формат: статья по интервью, совместное выступление или короткий внутренний разбор. Возможно, публичность ему вообще не нужна. Это тоже ответ.
Вариант приглашения: «Можем начать с разбора для своей команды. Я помогу со структурой и репетицией. Если формат не подходит, поищем другой».
До старта договоритесь о четырёх вещах:
• зачем это самому инженеру;
• сколько времени он готов выделить;
• какую работу берёт на себя DevRel;
• кто и когда проверит материал перед публикацией.
После отказа оставьте человеку возможность вернуться к предложению самому. Давление ради одного доклада усложнит следующий разговор.
Какую причину отказа вы слышите чаще всего?
До дедлайна подачи докладов неделя. Вы пишете сильному инженеру, а в ответ: «Давай без меня». Теперь нужно понять, что стоит за отказом и есть ли смысл возвращаться с предложением.
«У меня нет времени»
Уточните, сколько работы потребует участие, и обсудите это с руководителем инженера. Если подготовку доклада предлагают добавить к полной загрузке, отказ вполне понятен.
Можно зайти так: «Предлагаю начать с короткого интервью. Я соберу структуру, ты проверишь техническую часть. До старта согласуем время на подготовку с твоим лидом».
«Мне нечего рассказывать»
Вместо просьбы придумать тему спросите про недавнюю задачу: где застряли, какие варианты отбросили, что пришлось переделать. Так проще найти опыт, который пригодится другим.
Например: «Ты рассказывал про сложную миграцию. Давай обсудим, какие решения вы приняли и что посоветовали бы команде в похожей ситуации».
«Я не хочу на сцену»
Уточните, интересен ли человеку другой формат: статья по интервью, совместное выступление или короткий внутренний разбор. Возможно, публичность ему вообще не нужна. Это тоже ответ.
Вариант приглашения: «Можем начать с разбора для своей команды. Я помогу со структурой и репетицией. Если формат не подходит, поищем другой».
До старта договоритесь о четырёх вещах:
• зачем это самому инженеру;
• сколько времени он готов выделить;
• какую работу берёт на себя DevRel;
• кто и когда проверит материал перед публикацией.
После отказа оставьте человеку возможность вернуться к предложению самому. Давление ради одного доклада усложнит следующий разговор.
Какую причину отказа вы слышите чаще всего?
В чате снова пишет только DevRel. Что проверить?
Вы принесли новость, запустили опрос, пожелали хорошей пятницы. В ответ несколько реакций. Перед следующим постом стоит выяснить, зачем участники вообще открывают этот чат.
Пять вопросов для проверки сообщества.
1. Есть ли у людей общая задача?
«Чат для разработчиков» почти ничего не объясняет. «Здесь можно обсудить нагрузочное тестирование и попросить коллег посмотреть сценарий» уже даёт повод обратиться.
2. Легко ли начать разговор?
Проверьте, понимает ли новичок, с чем сюда можно прийти. Покажите пример вопроса, на который сообщество готово ответить. Напишите прямо, нужны ли код, контекст и описание того, что уже попробовали.
3. Что происходит с первым вопросом?
Посмотрите на последние обращения участников: получили ли они содержательные ответы? Для старта можно договориться с несколькими экспертами, кто готов подключаться к вопросам по своей теме. Ответив, оставляйте место другим участникам.
4. Можно ли участвовать без выступления на публику?
Кому-то проще выбрать вариант в опросе, прислать вопрос организатору или дополнить чужое решение. Предложите небольшой шаг, после которого понятно, что будет дальше.
5. Получают ли пользу те, кто молчит?
Спросите нескольких участников лично: что они читают, что уже пригодилось, чего не хватает. Число сообщений не покажет, сколько людей нашли ответ в старом обсуждении.
На ближайшую неделю выберите один эксперимент: например, разбор задачи, которую принёс участник. Заранее договоритесь с экспертом об ответе. После проверьте, помог ли разбор автору, подключились ли другие и появились ли новые вопросы.
Что в вашем сообществе запускает разговор без участия администратора?
Вы принесли новость, запустили опрос, пожелали хорошей пятницы. В ответ несколько реакций. Перед следующим постом стоит выяснить, зачем участники вообще открывают этот чат.
Пять вопросов для проверки сообщества.
1. Есть ли у людей общая задача?
«Чат для разработчиков» почти ничего не объясняет. «Здесь можно обсудить нагрузочное тестирование и попросить коллег посмотреть сценарий» уже даёт повод обратиться.
2. Легко ли начать разговор?
Проверьте, понимает ли новичок, с чем сюда можно прийти. Покажите пример вопроса, на который сообщество готово ответить. Напишите прямо, нужны ли код, контекст и описание того, что уже попробовали.
3. Что происходит с первым вопросом?
Посмотрите на последние обращения участников: получили ли они содержательные ответы? Для старта можно договориться с несколькими экспертами, кто готов подключаться к вопросам по своей теме. Ответив, оставляйте место другим участникам.
4. Можно ли участвовать без выступления на публику?
Кому-то проще выбрать вариант в опросе, прислать вопрос организатору или дополнить чужое решение. Предложите небольшой шаг, после которого понятно, что будет дальше.
5. Получают ли пользу те, кто молчит?
Спросите нескольких участников лично: что они читают, что уже пригодилось, чего не хватает. Число сообщений не покажет, сколько людей нашли ответ в старом обсуждении.
На ближайшую неделю выберите один эксперимент: например, разбор задачи, которую принёс участник. Заранее договоритесь с экспертом об ответе. После проверьте, помог ли разбор автору, подключились ли другие и появились ли новые вопросы.
Что в вашем сообществе запускает разговор без участия администратора?