Положу сюда. Обязательно пригодится!✅ https://netology.ru/blog/prg-tg

Как вы думаете, что это?
Некоторое время моими заказчиками были руководители новых офисов разработки компании в регионах. Для некоторых городов стратегию развития экосистемы необходимо было разработать и реализовать полностью, а где-то я только консультировала по стратегии или участвовала в отдельных проектах.
Мне довелось работать с различными городами: Санкт-Петербург, Нижний Новгород, Новосибирск, Екатеринбург, Иннополис — каждый из них был уникален по своим характеристикам.
На картинке - лепестковая диаграмма, которую я строю, чтобы видеть, как обстоят дела с необходимыми мне ресурсами в конкретном регионе.

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

❓А какие бы вы добавили шкалы в эту диаграмму?
Подробнее в статье https://bit.ly/2SokTpP
Делиться своим мнением зову в параллельный чат https://news.1rj.ru/str/MyDevRelChat ❇️

Недавно в чате devrel зашла речь о текстовом контенте и почему статьи так важны.
Здесь же обсуждались подходы к мотивации разработчиков готовить тексты о своей работе.
Полезный пост-продолжение этой дискуссии подготовила Антонина Татчук в своем канале @Editors_cave. Если интересует, советую почитать.
От себя хочу добавить, что именно с текстов и стоит начинать деврел стратегию, а уже потом браться за доклады и иные активности. Как правило разработчики визуалы, текстовая подача первична: документация, статьи, код, переписка в профессиональных чатах с коллегами. Если что-то надо найти по теме, то сначала будут искать тексты и только потом смотреть видео докладов.

Вовсю идёт обсуждение удалённых форматов работы с аудиторией. Все пытаются перенести митапы в онлайн или как-то их адаптировать.
❌Но спикеры не верят, что их так будут внимательно слушать, что получат желаемую обратную связь, то есть отработают впустую и их труд будет обесценен.
🔓 И, кажется, решение лежит в том, чтобы абстрагироваться от митапов, перестать виснуть в привычном опыте и начать думать про совершенно иной тип контента.

Задача - максимально привязать каждого зрителя к монитору, сделать его частью происходящего.
⁉️Задумайтесь, нужно ли проводить конференции на несколько докладчиков?
❓Что удержит у монитора каждую минуту?
❓Как сэкономленные от офлайн мероприятия средства вложить в удержание внимания каждого отдельного участника у экрана?

✔️Игровые, соревновательные, образовательные форматы - решение в них.

В продолжение темы про мотивацию разработчиков писать статьи.
Немного из своего опыта.

У каждого своя мотивация. Пока её не откопаешь, дело не пойдет. И это применимо как к написанию статей, так и к выступлениям и любым другим активностям.
«Тщеславие - мой самый любимый из грехов!». Желание признания есть у каждого. И тем более у тех, кто рожден, чтобы изменить мир к лучшему (я о разработчиках).
Писать хотят все (ну, или почти все), но вопрос, почему не соглашаются?
Когда я прихожу к разработчикам, то пытаюсь определить, на какой степени опыта, осознанности и готовности находится человек, чтобы писать статьи. Для себя я их классифицирую на четыре категории:
1️⃣Опытный разработчик - опытный автор
2️⃣Опытный разработчик, но мало авторского опыта или его совсем нет
3️⃣Опытный разработчик, но категорически отказывается писать или ленивый
4️⃣Молодой специалист, совсем нет опыта в подготовке статей.

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

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

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

Стоперы
Как правило такие авторы быстро соглашаются на написание статей, однако могут ссылаться на недостаток времени или неуверенность в теме.

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

Продолжаем...
👽Опытный разработчик, но мало авторского опыта или его совсем нет

📌осознает, что писать важно
📌писать хочет
📌либо имеет очень маленький опыт, либо не самый удачный
📌не умеет генерировать темы или, наоборот, идей для тем слишком много, сложно на чём-то остановиться/не уверен в себе или не знает, с какой темы лучше начать
📌статьи могут не быть осознанным приоритетом
📌следит за чужими публикациями
📌комментирует других
📌если совсем нет опыта, но мечтает засветиться на Хабре/другом профессиональном ресурсе
📌готов начать писать.

Стоперы

⚠️тяжело даётся форма и оформление
⚠️нет понимания, о чём можно написать
⚠️«синдром самозванца»
⚠️может прятаться за формулировками: «это не работает», «кому это нужно?», «если писать, то писать о чём-то очень важном, а так не хочу», «а что, если не получится» и т.д.

Как работаем

❇️Учим технологии избавления от «синдрома самозванца»
❇️Просим озвучить темы, на которые готов писать.
❇️Привлекаем его руководителя и команду, либо собираем виртуальную команду для обсуждения и выбора темы и помощи в подготовке плана и кейсов.
❇️Делаем подборки образцовых статей для анализа их успеха.
❇️Если есть необходимость и возможности, заручаемся помощью профессионального редактора и дизайнера.
❇️Обсуждаем целевую аудиторию, ценность статьи для ЦА, пользу и ценность для компании и команды.
❇️Определяем сроки, выделяем время, поощряем и подбадриваем сами и устами его руководителя и коллег.
❇️К вычитке привлекаем все заинтересованные стороны внутри компании.

Если есть что добавить, рада обсудить в чате https://news.1rj.ru/str/MyDevRelChat

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

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

✅Это мой любимый тип разработчиков. За счет такого критического подхода, эти специалисты могут предлагать наиболее прорывные идеи, темы, форматы. Шанс, что он станет что-то писать минимален (хотя все же есть). Но это ценный ресурс для того, чтобы определить самые хардкорные, острые и актуальные темы.

Как работаю

❇️Привлекаю в качестве эксперта-консультанта:
- прошу подобрать интересные, на его взгляд, статьи по его направлению
- поучаствовать в генерации тем, в критике в процессе мозгового штурма
- поучаствовать в вычитке статей коллег
- прошу накидать острых вопросов для интервью и к статье, в том числе «для затравки» при публикации
- советуюсь при поиске внешних лидеров мнений, гуру и звезд
- обсуждаю спорные вопросы и подводные камни, связанные с тем, как целевая аудитория может отреагировать на наши внешние активности, контент и т.д.
❇️Если позволяет себя так вовлечь, то изредка можно спрашивать, не появилось ли желание написать что-то самому. Главное, благодарить, ценить то, что уже делает и не спугнуть.

❓Поделитесь в @MyDevRelChat, как часто вам приходится сталкиваться с таким типом?

Молодой специалист, совсем нет опыта в подготовке статей

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


Как работаем

❇️Благодатная почва, чтобы растить его, как автора, аккумулирующего опыт команды и излагающего в тексте.
❇️Внушать, что писать необходимо, развивать желание писать.
❇️Большую роль здесь должны сыграть руководитель и команда: моральная и профессиональная поддержка, подбор и обсуждение тем, кейсов, плана статьи.
❇️Привлекаем опытного автора для консультаций. Даже если нет внутри команды, можно консультироваться и у внешних лидеров мнений.
❇️Если есть необходимость и возможности, заручаемся помощью профессионального редактора и дизайнера.
❇️Делаем подборку образцовых статей и анализируем вместе с ним.
❇️Сопровождаем и поддерживаем на протяжении всего цикла подготовки статьи, ищем и даем ответы на любые его вопросы.
❇️Важно по-возможности как можно быстрее подготовить статью, чтобы процесс не показался человеку затяжным и слишком трудоемким.

Итог:

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

Только личная мотивация,
заинтересованность и стимулы в виде ясного понимания пользы и выгоды. А еще важно, чтобы человек почувствовал эмоциональный драйв в процессе и по итогу.
Это моё личное мнение «и опыт - сын ошибок трудных» и успехов.

❓Мне было бы интересно и полезно узнать о вашем опыте, с какими типами авторов и трудностями, не описанных здесь, приходится сталкиваться вам.

Добро пожаловать в чат https://news.1rj.ru/str/MyDevRelChat

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

Когда разработчик не был уверен в своих силах выступать с докладом(вживую), например, сомневаясь, что не захватит внимание аудитории, то я напоминала ему про статистику:
⏩«Исследования показывают, что в среднестатистической аудитории её
благожелательная и активная часть, чье внимание оратору обеспечено,
обычно составляет 25-30%, негативные слушатели - 10%, а 60-65% -
аудитории—это индифферентные слушатели.
Если оратору в ходе выступления удастся увеличить активную часть
аудитории до 50 - б0%, то этого будет вполне достаточно, чтобы
выступление можно было считать успешным» (И.А. Стернин).

Это, как правило, успокаивает докладчика.

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

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

Моя работа процентов на семьдесят завязана на задачи поддержания репутации компании как технологического лидера, что, в том числе, должно влиять на желание разработчиков работать в компании. При этом мы никогда не говорили об этом как об employer brand. Однако сейчас я все больше погружаюсь в эту тему.
Много читаю, изучаю, смотрю доклады. Интересно наблюдать за тем, как отдельно друг от друга существуют и обсуждаются две области: devrel и employer brand.

Конечно, в IT компаниях прекрасно осознают, что технологическая репутация является важным, а иногда и решающим фактором влияния на желание технического специалиста работать в той или иной компании: технологический стек, репутация, влияние на индустрию и т.д. - являются частью employer brand. Тем не менее брэнд-менеджеры мало погружаются в технологические нюансы, а devrel отстраивается от остальных вопросов бренда работодателя.
Буду делиться здесь ссылками на видео, которые мне кажутся полезными.

Видео еще 2017 года, но с интересными кейсами, инсайтами и статистикой.

Спикеры подтверждают многое из того, что мы уже знаем. Например, что разработчики предпочитают компании, которые вкладываются в технологическое комьюнити и развивают индустрию, предпочитают уникальные продукты и проекты, взаимодействовать с внешней технологической аудиторией должны разработчики компании (for devs - by devs) и др. И что это все - часть общей программы бренда работодателя.
https://youtu.be/Ais3wnnSZLM

Продолжаю делиться докладами, которые мне понравились.
Два выступления одного докладчика - Екатерины Дробот, MacPow.

▶️HR-брендинг. Как и зачем.
bit.ly/hrbrandMacPow

📌Бренд - это эмоция
📌Самые простые идеи рождают самые сильные эмоции
📌Отличаться от других компаний
📌Ориентироваться на стратегию топ-менеджмента
📌Рассказывать о том, что есть, а не заворачивать «сами знаете что» в красивую обертку.
📌Отсюда вывод - начинать создавать хорошие условия и атмосферу внутри компании.
📌Развивать внутренние инициативы сотрудников
📌Выстроить удобный фидбэк с сотрудниками и всегда калиброваться с мнением сотрудников как про внутренние инициативы, так и про внешние активности
📌Метрики(по убыванию значимости):
- коэффициент удержания
- качество кандидатов
- стоимость найма
- количество кандидатов

▶️ Внутренний бренд работодателя
bit.ly/CorpCultMacPow

Лайтовый доклад об опыте конкретной компании с интересными практиками, которые могут вдохновить на новые идеи.
Компания IT, поэтому многое применимо для нашей сферы.

В продолжение темы про новые форматы онлайн-взаимодействия с аудиторией. Чуть раньше я делилась мнением, что стоит абстрагироваться от привычных форматов и не спешить переносить офлайн-мероприятия в онлайн.
Ивенты, в том числе их онлайн вариации, это всего лишь один из инструментов devrel или marhr. Каждый раз стоит возвращаться к первоначальной цели и задаваться вопросом, какой инструмент или формат взаимодействия с аудиторией будет наиболее эффективным в данном случае и условиях. Может быть даже, цели и задачи стоит пересмотреть.
Иногда можно увлечься красивой идеей "общение разработчиков" и выдавать её за цель. Это большая ловушка. Кроме этого, есть опасность перенасыщения событиями информационного пространства, что приводит к обесцениванию такого дорогого формата, как мероприятие. При чём как онлайн, так и офлайн.
Как раз попалась заметка с похожим мнением коллеги из Google.
https://www.thinkwithgoogle.com/intl/ru-ru/event-marketing-plan/

🔎Когда я провожу аудит employer brand и devrel, то часто вижу повторяющиеся ошибки.
Речь идёт в первую очередь о тех компаниях, которые ещё вчера не относились к it-индустрии, а сегодня им необходимо перестраивать свой бизнес и нанимать большую команду разработчиков.
⚒Имея порой сильнейший штат маркетологов и рекрутеров, выстроенные hr-процессы и эффективный внутренний employer бренд, такие компании вдруг сталкиваются со сложностью привлечения it-специалистов.
Так, например, менеджменту бывает сложно принять культуру it-people, а точнее такие её ценности как:
- свобода
- потребность влиять на бизнес
- комфорт

Cвобода предполагает необходимость не быть привязанным к рабочему месту 100% рабочего времени или иногда работать из дома (может быть условия карантина расширят понимание менеджментом, что это вполне выполнимо).
Это также относится и к желанию решать более сложные и творческие задачи, совместно и открыто с командой, выбирать решения, а не фиксить баги или тупо выполнять то, что прилетает в тикеты. Практически невозможным иногда оказывается внушить не техническому руководству, что C++ разработчику может понадобиться три дня мыслительного процесса, чтобы написать три строчки кода. То есть, разработчику необходима свобода для творчества, чтобы найти наилучшее креативное инженерное решение.
И я уже не говорю о том, как важно поощрять и поддерживать разработчиков в их желании делиться удачными решениями в формате open-source.
Продолжение следует…

❓Напоминаю, что вопросы можно задавать в связанном чате https://news.1rj.ru/str/MyDevRelChat или в личку.

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

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

А необходимость создания чрезвычайно комфортных условий работы повергает менеджмент в ступор.
Конечно, не у всех есть возможность создать такую домашнюю обстановку как в Google или Яндексе. Не все могут позволить себе так заботиться о сотрудниках как it-гиганты. Но есть уже определенный must have минимум, который любая компания должна обеспечить, а дальше расширить своими уникальными плюшками. Так, недавно, от одного из гендиректоров услышала: «Мы только недавно поставили кофе машины. Пусть скажут спасибо. Но они же уже просят печеньки!». Бывает и такое 😂

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

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

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

Но для разработчиков не менее важны:
❇️самореализация
❇️интересные нетривиальные задачи
❇️актуальные современные технологии или хардкор
❇️технологическая репутация и влияние компании на it-индустрию
❇️уровень команды в целом и есть ли в компании «звезды».

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

Продолжение следует…

Nataliya Makarova, [14.04.20 15:57]
Кажется, немного стоит пояснить мысль двух предыдущих постов.
В первую очередь речь идёт о компаниях, для которых технологии не являются основным бизнесом и которые только сейчас начинают трансформироваться и нанимать большие команды разработчиков.

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

Если менеджеры по бренду этой компании не сталкивались с задачей найма технарей, то им будет не просто сразу перейти на новые рельсы. В рамках бренда работодателя необходимо развивать дополнительное направление - developer relations, которое будет отвечать за технологическую репутацию компании, а также поддерживать внутренние и внешние коммуникации между it-специалистами, помогать компании встраиваться в технологическую экосистему.

А такие атрибуты как комфорт и плюшки - это даже не мотивация, а просто проявление заботы работодателя о сотруднике, которое демонстрирует уровень компании.