И, кстати, кто не знаком с замечательной Аней Крюковой и хочет ещё поспрашивать про мероприятия в Европе, добавляйтесь к ней в линкедин, Аня разрешила 😘
Аня живёт сейчас в Барселоне и поднимала DevRel и Employer Brand с нуля в Manychat.

https://www.linkedin.com/in/meowsphere

Насколько заранее вы начинаете готовиться к участию во внешних конференциях, а ваши спикеры — подавать заявки на доклады?

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

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

Уверена, если вы опытный деврел, то вы:

- Держите руку на пульсе и настраиваете разработчиков на конференции за 7-10 месяцев.

- Помните: чем раньше подан доклад, тем больше шансов попасть в программу, потому что организаторы сами заинтересованы поскорее наполнить сетку интересными темами и начать промо.

- Знаете, кто из ПК ответственен за нужные вам стримы. Заранее ищете возможность познакомиться и посоветоваться: как лучше «упаковать» вашу экспертизу и повернуть тему, чтобы она зашла и организаторам, и участникам.

- Выстроили процесс внутри компании и «продали» разработчикам идею, почему им (и бизнесу) важно участвовать в конференциях.

- Заранее знаете о сильных технических и продуктовых релизах (закладываете их в свой план) и чётко понимаете, с какой темой на какую конференцию идти.

Есть и другие лайфхаки, но эти считаю базой. Поделитесь своими в комментариях, если открыли для себя что-то новое!

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

DevRel и два CTO: разговор, который начался с одного простого вопроса 💬

Не так давно делала презентацию про DevRel — для CEO и CTO нескольких стартапов. Стояла и ловила себя на мысли, что объясняю, что вода мокрая. 💧 А потом вспомнила этот разговор и поняла — да, мокрая, но напоминать полезно. Записала почти дословно.

CTO №1: У нас честно — никто ничего не постит. Не потому что запрещено, просто у людей нет времени, а у меня тем более.

Я: А если бы время появилось — кто-то стал бы?

CTO №1: Не уверен. Скорее всего испугались бы. У нас команда не публичная вообще, все привыкли молчать и кодить.

CTO №2: У нас похожая история. Я вот думал нанять DevRel-человека, чтобы он это разрулил. Пусть выступает, пишет, представляет нас.

Я: А что бы он рассказывал?

CTO №2: Ну... про продукт. Про стек. Что мы вообще есть.

Я: А он у вас в коде разбирается, в архитектурных решениях?

CTO №2: Нет, это же не его работа.

Я: Вот тут обычно и начинается проблема. Если нанять человека со стороны, который не варился в вашей инженерной кухне — он максимум сделает красивую упаковку. А разработчики на рынке такое считывают моментально. Это не DevRel, это пиар с техническими словами.

CTO №1: Так а что тогда, мне самому этим заниматься? У меня продакшн, найм, роадмап — это уже перебор. 😵‍💫

Я: Не заниматься одному. Но без тебя — никак не начнётся. Культура идёт сверху. Если ты сам ни разу не рассказал, как вы решали какую-то задачу, не показал, что это нормально — команда тем более не начнёт, а уж тем более не начнёт наёмный человек со стороны, которому вы поручили "быть голосом компании". 🗣️

CTO №2: Но я правда не умею и не люблю писать посты. Это не моё.

Я: Речь не про то, чтобы ты вёл блог. Речь про то, чтобы твоя инженерная экспертиза и твоя позиция были видны — хотя бы иногда. Пост, комментарий на конфе, тред в чате с командой, где ты объясняешь, почему приняли то или иное решение. Люди в команде это видят и считывают: ага, оказывается, можно.

CTO №1: А если я скажу что-то не так и это выйдет боком?

Я: Вот это и есть настоящий вопрос, а не "нужен ли нам DevRel". Страх обычно живёт именно здесь — не в отсутствии времени, а в том, что непонятно, где граница и что будет, если ошибёшься.

CTO №1: Честно — да. Проще молчать, чем потом разгребать.

Я: И это нормальная реакция, если никто в компании явно не сказал: вот что можно говорить, вот где граница, и если ошибся — это не катастрофа. Без этого разговора команда будет молчать сколько угодно, наймите вы хоть трёх DevRel-менеджеров.

CTO №2: Хорошо, а сам DevRel-человек тогда вообще зачем, если начинать надо не с него?

Я: Затем что построить всё в одиночку, без выделенного человека, тоже почти невозможно — у тебя нет на это времени, у команды нет привычки, и это должно быть чьей-то явной задачей: организовать, подготовить, довести до системы. Просто этот человек должен опираться на то, что уже задаёте вы — идеологию, позицию, готовность делиться. А не придумывать её за вас с нуля.

CTO №1: То есть сначала мы, потом он.

Я: Или вместе, но точно не вместо. Если нанять человека и полностью отойти в сторону — считай, вы наняли пресс-службу. А если начать хотя бы с малого — сам рассказал, сам поддержал того, кто рискнул выступить, — DevRel-человек потом это масштабирует. Но фундамент — КУЛЬТУРА — это всегда изнутри и сверху, не снаружи.

CTO №2: У нас, получается, ещё даже фундамента нет.
Я: У вас есть инженеры, которые молчат не потому что нечего сказать, а потому что непонятно, можно ли. Это уже отправная точка. Дальше вопрос, кто первый скажет "можно" — и покажет это не словами, а собственным примером.

Почему тебе надо в техпиар, а не в DevRel...

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

Но чем крупнее компания — тем сложнее эта конструкция.
Особенно если компания изначально технологическая или активно держит путь на трансформацию.
Нужно показать очень широкой аудитории:
🔸 какие технологии ваша компания создаёт;
🔸 что в них действительно нового, в чем прорыв;
🔸 почему вашим решениям можно доверять;
🔸 что умеют ваши рпзработчики!
🔸и главное — почему всё это должно быть интересно человеку, который вообще не разбирается в технологиях?

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

Но это всё-таки не DevRel.
И, кстати, ко мне довольно часто приходили пиарщики и спрашивали:
— А может, мне пойти в DevRel? Кажется, DevRel сейчас востребованнее обычного PR.

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

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