MyDevRel – Telegram
MyDevRel
844 subscribers
102 photos
5 videos
1 file
106 links
Канал про опыт в DevRel/Tech Marketing и Employer Brand for Tech Talents.
В сфере DevRel с 2013 года. Ex Head of Devrel в SberDevices, DevRel-партнер GigaChat.
ExYa. Пишу про свой опыт, сохраняю полезные ссылки, делюсь практиками. Слежу за трендами.
Download Telegram
​​В начале апреля я уже делилась своим мнением на счёт онлайн-форматов мероприятий для разработчиков и о том, что просто перенести митап в интернет кажется не очень правильной идеей. Важно идти от первоначальной задачи, а может быть даже и её пересмотреть.
Вот и Кирилл Анастасин в своём видео рассуждает в том же ключе и убеждает аудиторию помнить о целях, ценности контента и пользе для целевой аудитории. А то, каким образом задача будет решена, может кардинальным образом отличаться от привычных форматов.
​​Хочу сегодня рассказать о своей системе, по которой я работаю с компаниями по вопросам аудита бренда работодателя для технических талантов и devrel стратегии.
По сути это микс особенностей коммуникаций с технологической аудиторией и стандартных маркетинговых подходов.

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

В комплексе компоненты позволяют увидеть слабые зоны и возможности для развития программы коммуникаций с разработчиками.
Каждое направление схемы нуждается в дополнительной проработке и создания концепции. Например, необходимо разработать и протестировать EVP для технических талантов, оптимизировать сайт о карьере, вакансиях и жизни компании под ИТ-талантов, сформулировать политику взаимодействия с профильными комьюнити и конференциями, определить концепцию технологического контента для собственных и партнерских каналов и т.д.
Каждый из компонентов включает в себя набор инструментов, подобранных индивидуально с учетом целевой аудитории, технологического стека, особенностей взаимодействия внутри профессионального сообщества и т.д. И как нет одинаковых компаний, так нет единого универсального подхода и решения для всех.
Это непосредственно связано и с Tech Candidate journey, так как я уверена, что путь разработчика в компанию начинается задолго до его контакта с рекрутером. Об этом я ещё напишу пост.

И когда я работаю с компаниями, то меня интересует всё: от разрабатываемого продукта, стека технологий, планов на найм, проблем процесса найма до поиска тех харизматичных и талантливых разработчиков в команде, кто может стать амбассадором бренда. В каждом из моих опросников для CTO, HRD, рекрутера, тимлидов и разработчиков около 50 вопросов. И, конечно, не подумайте, что я прошу заполнять их письменно 😉. Встречи с заинтересованными сторонами - это глубинные интервью, когда можно раскрыть потенциал людей, компании и одновременно увлечь задачей и мотивировать участвовать в devrel программе.

Если интересно узнать больше об аудите, пишите!
В процессе работы приходится очень подробно разбирать процесс рекрутмента, так как это тоже часть работы с репутацией компании как работодателя и напрямую влияет на результат найма. Если здесь есть проблемы, то они могут потянуть вниз за собой весь бренд.
Модное сейчас направление MarHR адаптировало под свои нужды Customer journey map. Так, в распоряжении рекрутеров теперь есть Candidate или Employee journey map. В основном всё крутится вокруг процесса найма от момента, когда с кандидатом связался рекрутёр до принятия или отказа кандидата от оффера.
Как это выглядит:
Рекрутёр публикует вакансию на карьерном сайте или ресурсе вакансий —> заинтересованные кандидаты, увидев вакансию, изучают компанию и отправляют своё резюме. Другой вариант - рекрутёр, опубликовав описание вакансии, ищет кандидатов сам —> находит профиль потенциально интересного кандидата —> связывается с человеком по e-mail/message/phone call —> кандидат отказывается сразу или соглашается посмотреть на описание вакансии.
Если описание заинтересовало, то кандидат начинает искать информацию о компании: карьерный сайт, каналы в социальных сетях, публичный корпоративный блог, новости и даже финансовые показатели. Все эти ресурсы - точки соприкосновения кандидата с брендом. В расширенной карте путешествия кандидата уделяется внимание и отзывам знакомых, работающих в настоящий момент в компании, и отзывы бывших сотрудников, и даже тех, кто уже проходил собеседования.
Дальше кандидат принимает решение, идти ли на собеседования, выполнять ли тестовое задание и пр. Последующими важными этапами в этом путешествии является то, какие впечатления останутся у кандидата от встречи с рекрутером, нанимающим менеджером, потенциальным руководителем и т.д. Это приводит либо к принятию оффера, либо к отказу от предложения.
В процессе возможны варианты, так как на этом пути могут быть обучающие программы, как старт карьеры в компании, известность бренда как производителя известных продуктов, услуг и т.д.

Такая стандартная карта пути кандидата в компанию вполне себе работает для большинства специальностей, но только не для разработчиков. Почему?

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

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

Задолго до того, как на технического специалиста вышел рекрутёр, он должен уже как-то пересекаться с брендом. Желательно, чтобы это были точки соприкосновения в контексте технологической репутации:
📍статьи и посты на Хабре и других ресурсах о технологиях(GitHub, Reddit и т.д.)
- технологические конференции
📍митапы компании для разработчиков
📍профессиональные чаты и т.д.
- сообществах для разработчиков и др.

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

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

Путь технического кандидата в компанию (Tech Candidate Journey) тернист и многовариативен. Иногда это мне напоминает детские квесты :)🤣
​​Не кодом единым или как разработчику написать статью: интервью с Антоном Полухиным

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

Антон Полухин — эксперт-разработчик C++ в Яндекс.Такси, представитель России в международном комитете по стандартизации C++, автор статей и книги “Boost C++ Application Development Cookbook”.
Антон — один из самых известных российских разработчиков C++ и уже вошел в историю своими предложениями в стандарт языка. Яркий докладчик, гуру стандартизации, помогает разработчикам готовить предложения в стандарт и защищает их на заседаниях международного комитета.
Меня всегда удивляла неистощимая энергия Антона в направлении авторства статей, выступлений, работы в комитете и т.д. Захотелось попробовать раскрыть этот феномен. Надеюсь, это поможет деврелам мотивировать разработчиков делиться опытом, а разработчикам вдохновиться писать не только код, но и статьи, а также выступать и развиваться.

"...Ты автор книги про библиотеку Boost C++ , которая уже вышла во втором издании в Лондоне. Как вообще возникла идея её написать?
Идея пришла ко мне в почту со словами: “Привет! Я работаю на издательство и вижу что ты активный разработчик библиотек Boost. А не хочешь ли написать книгу?!”. В этот момент у нас шёл ремонт, и это был идеальный повод откосить от выравнивания полов своими силами!
Позже, я поднапрягся и сделал так, чтобы примеры из книги можно было модифицировать, компилировать и запускать онлайн http://apolukhin.github.io/Boost-Cookbook/
Первое издание людям понравилось, поэтому через пару лет издательство пришло за вторым.
Сейчас книга переводится на русский язык и должна появиться на полках в этом году.

Как ты работаешь над структурой, формой?
Тут все как на уроках литературы: у каждой статьи должна быть завязка, кульминация, развязка. Для технических статей первое и последнее должно быть минимальным по размеру.

Как подбираешь кейсы, примеры кода, иллюстрации для статей?
Если пишем “статью-ужастик”, то в завязке надо показать страшный кусок кода, в кульминации всячески с ним бороться, улучшать и показывать как сделать правильнее, а в развязке показать как все стало хорошо.
Если же пишем “статью-документалку” о прошедшем мероприятии, то в завязке надо нагнать интриги, полусловом обмолвившись об интересных вещах. В кульминации описываем всё как есть, сосредоточившись на самом интересном и значимом. Ну а в развязке подводим краткий итог и делаем намёк на сиквел..."

Продолжение https://bit.ly/MyDevRel72
Знаете ли вы, что деврелу есть дело до всего, что происходит в компании?

РЕКРУТМЕНТ

Особенно если задачи заточены под Employer Brand.
Деврел должен изучить весь процесс найма: от стиля описания вакансии и реальной потребности в том или ином специалисте до качества собеседований, продолжительности цикла найма и условий оффера. А еще важно понимать специфику HR-аналитики, в которую надо грамотно встроиться.

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

HR и ВНУТРЕННИЕ КОММУНИКАЦИИ

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

ПРОДУКТ

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

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

МАРКЕТИНГ

Однажды мне пришлось доказывать нашему главному по маркетингу, почему мы тоже не просто плюшки на мероприятиях проедаем. Когда директор по маркетингу мыслит целевой аудиторией в миллионах пользователей, а стоимость контакта в его видении должна стремиться к 0,5-3 рублям, то ему кажется немыслимым, что ёмкость рынка разработчиков конкретной специализации может насчитываться парой десяткой тысяч человек всего, а стоимость контакта доходит порой до 15К в зависимости от ценности, редкости специалиста и инструментов коммуникации.
Мы используем принципы и инструменты маркетинга: проводим исследования, сегментируем, анализируем, строим эффективные коммуникации, достигаем целей. Просто аудитория у нас дорогая, а задачи нетривиальные.
Кажется, убедить удалось :)

PR

Работать в коммуникациях и быть отстроенным от общей стратегии PR компании невозможно. Синхронизация с информационными поводами по выпуску продуктов, услуг и технологий позволяет вовремя рассказывать об особенностях разработки сервисов, что увеличивает синергитический эффект восприятия бренда в том числе технологической аудиторией.
ЮРИСТЫ

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

ФИНАНСЫ

Здесь очевидно, что речь идет про бюджеты. В какой момент и как правильно формировать бюджет и как его защищать перед CFO, чтобы его не урезали. Как провязать эффективность своей работы не только с качеством и количеством, но еще и с финансовыми показателям компании в целом. Таким образом деврел должен быть в курсе финансового состояния компании и того, какую дополнительную стоимость он привносит.

Кому-то везёт и часть функций распределяется между специальными подразделениями компании, однако и в этом случае помнить обо всем этом нужно деврелу самому.
​​Мои правила работы с профессиональными сообществами разработчиков
на примере взаимодействия с C++ User Group Russia

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

Почему компаниям важно работать с комьюнити?
Для своей работы я вижу такие базовые плюсы, как:
📌возможность проведения различных исследований рынка;
📌получение честного и прямого фидбэка на технологию, продукт, идею, проект;
📌влияние на внутренний и внешний employer бренд;
📌взаимодействие с лидерами мнений в конкретном технологическом направлении и влияние через них на более широкую аудиторию и др.

Что я считаю самым важным при работе с технологическими сообществами?

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

16 июля в 15:00 пройдёт вебинар от Codenrock «Инструментарий Developer Relations для решения HR-задач», где эту тему раскроет подробнее Алексей Долгушев.

"Представьте: вы спрашиваете у кандидата на вакансию, что он знает о вашей компании, а он отвечает, что слышал доклады от ваших инженеров на конференциях и читал статьи о вас на Хабре. По статьям и докладам думает, что вы в компании занимаетесь интересными задачами, что ему нравятся ваши ценности, технологии и как организован процесс. Что в целом откликнулся на вакансию, потому что уже что-то знает о вас и эта информация ему нравится."
На вебинаре пойдет речь о том:
Какие бывают разновидности DevRel?
Как отправить своих сотрудников рассказывать истории во внешнем мире в рамках DevRel;
Как синхронизировать DevRel и HR.

Участие бесплатное, но необходимо зарегистрироваться https://bit.ly/30aERZ0

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

Мемчики и провокационные заголовки — это тонкий лед. Всегда найдется тот, кого это раздражает. Нужно быть на одной волне с теми, кто это читает."
Так вот дело в том, что Катерина очень крутой рекрутер очень хардкорных команд и, говоря про шуточки, мемы, знает, какими они должны быть, чтобы зацепить разработчиков.
Когда компании нужен devrel специалист?
===========

ПРОДУКТОВЫЕ И БИЗНЕС-ЗАДАЧИ
—————————————————-
📍Когда разработчики и вообще IT-специалисты в том числе являются потенциальными клиентами/ покупателями или просто пользователями продуктов компании: технологий, инструментов, сервисов и т.д.
Например, JetBrains, JFrog, Red Hat и др.

📍У компании есть интересные наработки или идеи, хочется доработать их в формате open-source, привлекая внешнее комьюнити.
Так, Google дорабатывал свои проекты Chromium, Android, Tensor Flow и др.


НАЙМ И УДЕРЖАНИЕ
———————————
📍У компании есть планы сильно растить команду разработки и нанимать сильных специалистов. Если речь идёт о 5-ти людях в год, то деврел - не та история. Но если предполагается привлекать более 15 человек в год, то "заметность" компании в профессиональном информационном пространстве будет помогать рекрутёрам нанимать.

📍Для IT-компаний выстраивать коммуникации с разработчиками является органичной практикой. Но сейчас все больше компаний, чей бизнес далек от IT, трансформируют свои процессы и им необходимо нанимать айтишников. И здесь как никогда необходима помощь деврел-специалиста.

📍Для профессионального "социального поглаживания" разработчиков компании.
У сотрудников есть возможность писать статьи, выступать на конференциях, помогая компании, и, вместе с тем, продвигая свой личный бренд. Разработчикам приятно, если его друзья, бывшие коллеги или просто знакомые говорят, что "я слышал про вашу компанию - интересные вещи делаете".

📍Для улучшения внутренней культуры, когда профессиональное развитие сотрудников признается ценностью.

📍Для обмена знаниями и улучшения профессиональной коммуникации между разработчиками внутри компании.


РЕПУТАЦИОННЫЕ ЦЕЛИ
————————————
📍Формирование и поддержание технологической репутации для повышения капитализации и нематериальной стоимости компании. Как правило речь идёт о патентах и инновациях, но и рассказ об этом вовне тоже будет добавлять плюсов в глазах стейкхолдеров.

📍Технологическая репутация привлекает внимание потребителей. Покупатели предпочитают приобретать продукты более раскрученных технологически компаний. Однако, мы говорим о технологической аудитории. Именно признание разработчиками «технологичности» той или иной компании является фундаментом для более широкой инновационной репутации.

ИНТЕРЕСНЫЙ ФАКТ
——————————
❇️Согласно исследованиям, Apple Inc. воспринимается как самая инновационная компания, однако занимает лишь 43 - е место по своим расходам на НИОКР.
Наболело
===============

Кажется, пришло время это написать.

После очередного вебинара от рекрутера, найденного мной на просторах сети про то, как нанимать с помощью деврел, я поняла, что меня переполняет возмущение.
==========
Друзья, DEVREL - это не инструмент MarHR и рекрутмента!
==========
DevRel - это принцип, лежащий в основе бизнеса и менеджмента компании в целом. DevRel - это не про то, как показать разработчикам, какие мы хорошие и заманить их к себе на работу. DevRel - про то, как создавать продукт и сервис, которыми гордятся сами разработчики, а также про то, какими должны быть процессы работы над созданием этого продукта внутри компании.
DevRel - это как фундамент для репутации, к которой стремятся технологические компании. Если фундамента нет, то все может рассыпаться в непредвиденный момент. Если технари на рынке признАют и станут уважать компанию за уровень разработки, качество кода, прозрачность и вклад в развитие сообщества (через полезные штуки в open-source, обучающие и открытые доклады и статьи, работу над стандартами и др.), то не будет проблем ни с наймом, ни с продажей продукта.

В предыдущем посте я писала о том, когда нужно нанимать devrel специалиста и в том числе указывала на hr-задачи. Однако это не значит, что devrel должен быть исполнителем для рекрутмента.
DevRel влияет на многие процессы и ему есть дело до всего - см. выше.
А это значит, что DevRel - стратегическая функция и игра в долгую.

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

Мы встретимся с вами онлайн тет-а-тет за чашкой кофе и обсудим наши профессиональные темы.

Встречи абсолютно бесплатны, конфиденциальны и дружественны.
Напишите мне в личку @NataMakarova, чтобы договориться о дате и времени встречи.
📝Увидимся!
Неповторимый 2020 уходит. По степени счастья он был разным для каждого. Но всем принес небывалые вызовы в отношениях, работе и мировоззрении.
Перед нами, devrel профессионалами, этот год поднял неожиданные вопросы и поставил в сложные условия. Выводы пока делать рано. Но этот год точно сделал меня сильнее. А вас?
🎄С наступающим вас 2021, друзья!
Давайте будем ближе друг к другу и радоваться каждой минуте общения вне зависимости от формата :)😘
Всем привет!
Возможно, вы уже знаете из фейсбука, что я теперь работаю с новым классным проектом SmartMarket в компании SberDevices.

SmartMarket - это платформа для разработчиков навыков/смартапов для виртуальных ассистентов Салют.
В моей команде открываются три позиции:

🖌Devrel на организацию технологических ивентов (митапы, хакатоны, конференции и т.д.) - https://hh.ru/vacancy/42074026
🖌DevRel на лидирование обучающих оффлайн/онлайн/видео программ и проектов для разработчиков - https://hh.ru/vacancy/42640970
🖌DevRel - менеджер по развитию каналов коммуникации с технологической аудиторией - https://hh.ru/vacancy/42641562
  
То, чем предстоит заниматься в нашей команде - это продвижение целой технологической экосистемы - платформы с большим потенциалом, набором удобных инструментов для разработчиков для создания, тестирования и продвижения приложений с виртуальными ассистентами. Цели амбиционзные, задачи нестандартные, темп работы и развития всего супер-скоростной.

Кому интересно - с радостью расскажу подробнее.
👋Привет!
Давно не писала, и вот теперь есть чем поделиться.

Когда я пришла в декабре 2020 года в SberDevices в роли деврела платформы SmartMarket, то была поражена высоким уровнем работы с сообществом разработчиков SmartMarket Studio. Уже в тот момент процесс был простроен на высоте: скорость поддержки и ответов на вопросы, отношение к разработчикам и забота о них, внимание к потребностям и желание быстро реализовать нужные функции по запросу от участников сообщества - такого нигде не видела.
Предложила написать об этом на VC.ru. Уверена, будет полезно тем, кто строит и развивает комьюнити вокруг продукта и технологий.

"Как за полгода добиться роста сообщества в три раза, какие инструменты для этого мы использовали и почему без терпения здесь не обойтись"
https://vc.ru/dev/280881-komyuniti-smartmarket-vyrastit-soobshchestvo-v-tri-raza-i-uderzhat-v-nem-razrabotchikov-bez-pravil-pochtо
В Сбере я познакомилась с удивительным человеком - Викторией Евдокимовой. Вика - профессионал техномаркетинга! Но для меня также стал открытием ее выдающийся опыт в области предпринимательства.
И проект Meet for Charity - сложно понять, что важнее - стать благотворителем или прокачать нетворкинг через знакомство с ведущими экспертами интересующей сферы.
В любом случае не упустите шанс, если есть возможность, познакомиться с супер-профессионалом, обсудить вопросы devrel и продвижения технобренда с Викторией Евдокимовой.
Вам нужны аргументы, чтобы убеждать разработчиков писать статьи?
Берите мотивационные ключи и статистику из этой статьи или просто дайте им ее почитать!
https://bit.ly/3hkPBxh