Наталия Макарова про технобренд и DevRel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Как работаем

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

Итог:

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

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

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

Добро пожаловать в чат https://t.me/MyDevRelChat

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

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

Как работаю

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

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

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

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

Стоперы

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

Как работаем

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

Если есть что добавить, рада обсудить в чате https://t.me/MyDevRelChat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​​Дорогие читатели моего канала!
В уходящем году я начала писать о своем опыте в сфере developer relations. Благодарю вас за поддержку, вопросы и комментарии!
Не всё задуманное удалось подготовить и опубликовать. Так, из не освещенных тем оказались:
🔹история запуска ClickHouse в open-source и интервью с ключевым создателем и разработчиком Алексеем Миловидовым;
🔹первый митап ClickHouse заграницей: как я анализировала технологическую экосистему Берлина, искала профильные комьюнити, целевую аудиторию и т.д.;
🔹зачем крупные компании открывают региональные офисы разработки и как выстроить локальную технологическую экосистему вокруг офиса: здесь я хотела поделиться своей системой аналитики инфраструктуры и построения стратегии развития региональных экосистем;
🔹мой опыт организации международной конференции по Machine Learning в Берлине в 2015 году, где в том числе расскажу, как я лично отправила более 120 приглашений иностранным докладчикам, из которых в итоге приняли участие 40 выдающихся людей. А ещё о том, что такие мероприятия могут дать компании.
🔹мысли о влиянии devrel на найм: опыт большой, но не всем смогу, к сожалению, поделиться. Поэтому напишу в формате "мысли и идеи". Надеюсь порассуждать с вами вместе.
🔹обзор книг про devrel и другой профессиональной литературы из смежных областей, которая мне помогала в свое время расти как профессионалу.
🎄Желаю себе времени и вдохновения написать хорошие посты на вышеуказанные темы и не только. А ещё мечтаю познакомится с неравнодушным к этой теме пишущего редактором себе в помощь.
💫А вам желаю в новом году удовольствия от работы, энергетической отдачи от коммуникации с вашей целевой аудиторией и вдохновения от общения с коллегами!
До встречи в 2020! 😍

Python - лидирует, C++ в шестерке самых популярных языков. Интересно, что ждёт нас в будущем.
https://www.facebook.com/108525613197229/posts/419456495437471/

В 2016 году в России мы запустили национальную рабочую группу по стандартизации языка C++.
Для меня - это успешный проект в рамках программы развития российской экосистемы C++ и эффективный формат работы с международным и российским сообществом. Как менеджер проекта, в статье я делюсь подробностями создания рабочей группы от идеи до запуска. http://bit.ly/cppstdwg21

Если есть вопросы, задавайте их специальном чате в телеграм https://t.me/MyDevRelChat

Регистрироваться или нет?! ⚠️
Насколько подробной должна быть регистрационная анкета на мероприятие для разработчиков. Есть мнение, что технари не любят заполнять анкеты. Это связано как с осознанием ценности персональных даных, так и в целом нежеланием, чтобы их «посчитали».
Вопрос остается холиварным как для участников, так и для организаторов.
Мое мнение - должна быть длинной настолько, насколько можем себе позволить в том или ином случае.
http://bit.ly/2msIsRV
А обсуждаем здесь https://t.me/MyDevRelChat