Про DevRel

А я уже говорила, что ищу себе DevRel-а в команду?)
Сопроводительного текста особо не будет, просто ищу лучшего в лучшую команду эвер. Детали по ссылке:

https://hh.ru/vacancy/121094739?hhtmFrom=employer_vacancies

Часто слышу обсуждения, что мол ну конечно, у компании ХХХ столько денег, поэтому у них и проекты классные и ИТ-бренд сильный. Но на деле — наличие бюджета не является залогом успеха. Ровно как и наоборот.

Если у вас есть бюджет:
1. Классно, можно делать серии митапов с кейтерингом и рекламными анонсами;
2. Ура, можно покупать партнерские пакеты и стоять со стендами на ИТ-конференциях;
3. Супер, можно организовывать собственные ИТ-конференции, через которые продвигать свой бренд.
4. Можно запускать и развивать свое комьюнити;
5. Можно проводить хакатоны;

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

Представим, что в команде 3 деврела. Или 5. Или не важно сколько. И условно — вот вам вместо 1 млн руб в год - 70 млн руб в год. Будет ли этого достаточно для того, чтобы круто сделать все или хотя бы половину из того, что перечислено в пунктах выше?

В продолжение предыдущего поста — про несоответствие заявленной аудитории в партнерских пакетах ИТ-конференций фактическим участникам.

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

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

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

Трехсторонние отношения или деврельский треугольник

Участвовала в апреле в круглом столе на Стачке и мы там затронули тему снова про наполненность стендов на ИТ-конференциях. Думаю, контекст тут близок многим — как соблюсти баланс между экспертизой, через которую показывать продукты и технологии компании, и геймификациями.

И вот собрались на площадке три категории участников “этой ситуации” вокруг стендов:

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

DevRel-ы — условно начали “защищаться”, что мол у нас всегда баланс на самом деле, мы и экспертов зовем и активности с играми делаем, чтобы привлечь трафик на стенд и обеспечить касания с брендом. Что на самом деле в активностях участвуют и хардкорные разработчики и залетные (простите).

Организаторы конференции — держали нейтралитет, но вопросы к ним не уменьшились. Боль же заключается в том, что организаторы показывают нам в партнерских пакетах одно, а на деле аудитория часто не соответствует заявленной (и это не имеет отношение к какой-то конкретной конференции, это в целом частое явление). А от четкой позиции и гарантий качества и количества участников зависит и сетап стенда компании.

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

DevRel-комьюнити и шашлыки

DevRel-комьюнити хоть и небольшое, но существует. В него входят и деврелы и те, кто находится рядом с профессией — активные разработчики и лидеры ИТ-сообществ, подрядчики, те, кто ищет работу в девреле и др. И нет единого места для сообщества, все сидят по разным чатам и каналам. И все собираются по разным площадкам для обмена опытом и нетворка: DevRel Conf, наша МТС DevRel Party, DevRel-завтраки и ужины, и вот теперь — DevRel-шашлыки, которые в первый раз прошли в минувшую субботу.

Думаю, что в ядро деврельского сообщества входят человек 150 — это те, кто ходит по мероприятиям и примерно знает друг друга. Конечно, никто не отменял более кулуарные сообщества внутри сообщества — многие дружат и просто общаются. Или собираются по несколько человек на хаотичных встречах, договариваясь самостоятельно в тех же чатах.

Это я к чему. DevRel-комьюнити — отличный пример профессионального сообщества, которое существует и развивается, как благодаря отдельным активистам, драйвищим встречи, так и само по себе. Ценность у него простая — обменяться друг другом опытом в силу не попсовости профессии. Нас же не тысячи в РФ, пока.

Взаимодействие с разными подразделениями и дочками.

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

Сразу сужу вопрос до острого — как вести совместные проекты, не разругаться и при этом не делать все за других (и эффективно для продвижения бренда).

Есть две тактики:

1. Залидировать и взять процесс в свои руки. Да, кому-то придется это делать и часто лучше занимать такую позицию. В такой тактике можно выступать кем-то по типу и заказчика и агентства в одном лице. В роли заказчика и лидера — вы собираете пазл проекта, определяете его цели и метрики, отвечаете за результат. Мне лично близка именно такая позиция, когда я полностью управляю процессом и уверена в эффективности совместной активности или мероприятия.

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

2. Четко расписать структуру проекта и делегировать ответственность каждого подразделения за себя, не залезая в чужие задачи и не тащя проект на себе. С точки зрения распределения ресурсов — это верная тактика. С точки зрения результата — зависит от большого количества факторов, на которые вы, вероятно, не сможете повлиять. Например, команда "дочки", их загруженность и готовность в полной мере отвечать за свой блок. И часто в четко-разделенных зонах ответственность за результат несут сразу все, а значит никто. Формально — не придерешься, по факту — кому нужны детали, когда проект не получился, хотя ты выполнил свой блок на все 100?

Но в любом случае помним, что DevRel — это про коммуникации. Добавим чуточку клиентоориентированности для общего результата.

Возвращение в большой DevRel. А точнее из большого DevRel с постами в Телеграм-канал.

Всем привет! Меня зовут Настя, я больше года руковожу DevRel в МТС Диджитал, а до этого у меня было DevRel-агенство. Собственно во время агентства я и создавала этот канал, который пришлось отложить после выхода в МТС. И поверьте, за этот год перехода из собственного дела в найм и лидирования DevRel-а в большой компании у меня накопился контент и есть что рассказать.

Поэтому я воскрешаю этот канал, спасибо, что не разошлись ☺️

Планирую писать о:
— DevRel-е в компании с более 10 тыс ИТ-специалистов;
— Применении предпринимательского/агентского опыта в корпоративном мире - какого это по ту сторону забора;
— Формировании и управлении командой;
— В целом о DevRel-практике.

В общем, Stay tuned. Постараюсь, чтобы вам было полезно и не скучно❤️

Уже завтра седьмая, а для этого состава ПК - вторая, DevRel Сonf. Было сложно выбрать из такого количества заявок (аж 43!). Были и споры, и попытки утрамбовать поплотнее (в результате у нас набралось довольно много 15-минуток), пришлось и отказаться от некоторых хороших докладов (ждите анонсы следующего DevRel-митапа). Так что программа выстраданная и, как просили в прошлом году, очень практичная, ну прямо бери и делай (а в некоторых случаях, не делай). Единственное, пожалуй, исключение, рассказ про IT-каток и IT-пикник. Ну просто мы никак не могли пройти мимо настолько большого для отрасли события. Думаю, даже если ваш бюджет не похож на бюджет Тинькофф, все равно интересно, зачем они это сделали.

Начнем в 12:30, так чтобы до оффлайна доехали пассажиры Сапсана, а москвичи нормально выспались. Программа и регистрация на онлайн (да, места на оффлайн уже нет): https://devrelconf.ru/

Хотела написать какой-то итоговый пост после HighLoad++, поделиться впечатлениями.

Но в голове только одно – гуси! 🙂

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

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

⚡️И это идея на следующий Хайлоад – произвести пакет, на котором так и написать: “Пакет для мерча” и забрендировать его. Профит! Успех гарантирован, компания не останется незамеченной и получит лучи лояльности от участников конференции.

А если сделать пакет в виде сумки или большого шопера, который компактно складывается, то успех повторится и на других конференциях;)

Про спецпроекты🔭

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

А какими вообще могут быть спецпроекты, направленные на узнаваемость техбренда:

1. Спецпроекты в медиа. 
Например на Типичном программисте или на Хабре. Брендированный лонгрид, опрос, анимированная игрушка, лендинг и т.д. Рекламный СП на ЦА - айти-специалисты. Я бы рассматривала только с точки зрения имиджа. 

2. Спецпроекты в Телеграме. 
Это могут быть проекты на основе посевов, спецпроекты в аккаунтах техбрендов с внешним продвижением, спецпроекты с конкретными сообществами и др. Тут важно, что для таких СП у техбренда должен быть свой ТГ-канал, куда будет идти трафик.

3. Event-спецпроекты. 
Какая-то особая активность, отличающаяся от стандартных форматов вроде конференции или митапа. Возможно, связанная с конкурсами и/или образовательной частью. 

4. Спецпроекты 360 градусов. 
Когда проект охватывает различные каналы и форматы, но при этом объединен единой концепцией.

Появился агентский опыт во внутреннем девреле. Каково это оказаться внутри компании, являясь сотрудником агентства? 
 
Вот 5 инсайтов касаемо выполнения локальных задач: 
 
1. Про стейкхолдеров. 
Не увидела принципиальных отличий в работе с стейкхолдерами, когда ты снаружи или внутри. В любом случае – в коммуникациях почти всегда ориентир на запросы заказчика активности. 
 
2. Про коммуникацию с командой исполнителей. (деврелы, внутриком и др).
В классическом сотрудничестве, когда агентство во вне, есть границы все-таки, которые связаны с тем, что компания может доверить агентству и с тем, что агентство готово на себя взять по договору. Внутри – вы все команда.

3. Про закупки. 
Открылся чудный мир процесса закупок, когда тебе надо запустить ХХХ здесь и сейчас, но ты не можешь просто так отдать задачу подрядчику. Со стороны агентства этот процесс, происходящий на стороне клиента, казался проще.

4. Про согласования. 
Внутри сильно заметен микроменеджмент, в то время как снаружи его почти не видно. Ну или он тебя не так касается) Допускаю, что дело в конкретном проекте, команде.
 
5. Про количество проектов в работе. 
Офигеть, как много всего есть еще в девреле, рассчитанное на внутренние IT-сообщества. Как вы справляетесь?) 
 
Конечно, это все только субъективные наблюдения за небольшой период. Но для меня они ценны тем, что такой опыт поможет больше понимать клиентов и делать проекты еще лучше:) И люди, занимающиеся DevRel-ом прекрасны, всегда❤️

Конференций для деврел-сообщества у нас в стране мало, для интересующихся — анонсирована DevRel Conf. Открыт прием заявок на доклады, детали тут: https://cfp.devrelconf.ru/

А регистрация для участников на основном сайте: https://devrelconf.ru/

Конференция пройдет 9 декабря в Москве, очно. Здорово, что есть площадка для обмена опытом:)

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

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

Теряется ответ на вопрос: Зачем?

И я не про бизнес-задачи, связанные с продвижением ИТ-брендов. А про задачи в контексте активности. Зачем условному дата сайентисту рассказывать в Хабр-статье про использование даты в компании. Зачем андроид-разработчику участвовать в митапе по системной разработке и какая ценность для ИТ-сообщества. И т.п. 

Сталкиваюсь с тем, что в компаниях часто нет «технологии» по работе с экспертизой сотрудников-инженеров. Отсюда возникают сложности с деврел-активностями. Вроде как активности есть, но их ценность для ИТ-специалистов внутри и снаружи размыта.

Близится HighLoad++ и многие компании сейчас заняты подготовкой к участию. Среди наиболее частых форматов: выступления спикеров и..конечно стенды. 

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

Попалась статья на Хабре с обзором стендов и мерча на Saint HighLoad++ 2023. Показалось полезной для вдохновения, делюсь) 

Читать здесь

Небольшая подборка актуальных курсов, деврелам в помощь. 

1. Для начинающих есть курс на Отусе, который так и называется DevRel. Тут можно узнать о базе, посмотреть какие форматы коммуникаций есть в девреле, как работать со стейкхолдерами и амбассадорами бренда и др. В качестве преподов действующие деврелы из компаний (Альфа, Сибрур, Яндекс и др.). Старт 26 октября, 👉ссылка

2. Бренд-марафон для HR. Курс о бренде работодателя — как он создается, работает и из чего состоит. Авторы курса и его преподаватели из эмплоер-брендингового агентства makelove agency. Старт 27 сентября, 👉ссылка

3. Комьюнити-менеджер. Курс от Нетологии по системной работе с сообществами. Много практики и наработок от действующих комьюнити-менеджеров. Можно научиться запуску, развитию и спасению сообществ, поиску партнеров и монетизации и др. Старт 25 сентября, но набор еще идет, а следующий поток стартанет в конце ноября. Ссылка 👉

Сегодня про DevRel-ретейнер. 

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

Что может включать DevRel-ретейнер: 

1. Написание технических и экспертных статей. 
2. Ведение корпоративных блогов (Хабр, VC, например).
3. Ведение аккаунтов ITHR или tech-брендов в соцсетях.
4. Координация и сопровождение участия спикеров во внешних IT-ивентах. 
5. Пакеты продвижения деврел-активностей. 

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

Наблюдение про названия хакатонов. Многие в нейминге хакатона используют название компании с приставками: Hackathon, Hack, Challenge, Digital Challenge, Cup. И, кажется, впервые в названии соревнования я увидела сокращенную приставку Champ. Оставлю на заметку.

Понравилось определение функции DevRel — деврел помогает специалисту проявить себя как специалист. Такое определение услышала на выступлении одного из деврелов, который работает инхаус. 

Будто бы каждый по своему воспринимает деврел, в зависимости от задач, с которыми непосредственно работает.

Например: 

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

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

Деврел продвигает технологический продукт, также через ивенты, контент, сообщества и  др. Дает определение, что строит знание о техбренде. 

И все определения верные и все определения дополняют друг друга.

Про агентские сложности с клиентами
 
DevRel-сфера все-таки достаточно новая в РФ. Не смотря на то, что компаний с деврел-задачами становится все больше, их скорее десятки, чем сотни. 
 
А агентств, которые оказывают услуги еще меньше и все с разным бэкгранудом. Скорей всего не было такого, что кто-то бац и стал сразу деврелом заниматься, нет. 
 
Фаундеры и команды агентств пришли или из разработки, или из HR-маркетинга, или из PR, или как мы  — из корпоративных инноваций. Но каждый так или иначе стал прокачиваться в девреле, подстраиваясь под запросы бизнеса. 
 
Одно из возражений, с которым мы сталкиваемся — это отсутствие большого количества кейсов по некоторым деврел-форматам. И получается замкнутый круг — чтобы компании заказывали услуги им нужны кейсы, чтобы были кейсы нужно, чтобы компании заказывали услуги. 
 
Все верно, это закон рынка, всем нужны кейсы. Но! Деврел-кейсов по отдельным услугам физически не может быть прям много и чтобы метрики были ВАУ. А иногда отсутствие кейсов это тоже ок, особенно если компания хочет запускать что-то новое. При выборе провайдера надо все-таки смотреть на совокупность и учитывать бэкграунд агентства.