Ксения Романова | DevRel и другие коммуникации в IT

Practice what you preach

Прошу прощения за англицизм, но только эта фраза помогла мне довести до конца трансмутацию доклада в пост на хабре. Потому что это же я всегда уговариваю спикеров: «Вот ты выступишь, а потом будет видео, и мы еще блог из этого напишем». Что в общем‑то чистая правда — контент должен отработать во всех форматах (в прежней жизни еще бы рилсов нарезала).

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

Редакторы — мои героини — результат нашего совместного труда. Странная картинка — не просто кринжатина какая-то, а оммаж моему любимому стикеру митапов Apache Ignite #этосновабылопыт #opensource

В 2023 глобальные технические компании уволили 262 735 человек. Есть даже специальный сайт, который считает это по официальным заявлениям. Цифра за 2024 год, возможно, будет больше, потому что только в январе это уже 34 250 увольнений. Не все увольнения окончательные (кого‑то взяли обратно на худших условиях, например), но тенденция нервная. Увольняют и DevRel‑специалистов (увы, это функция для сытых времен). Что заставляет некоторых давать довольно мрачные прогнозы. Мы все ещё говорим об американском и глобальном рынке, напомню, но, знаете ли, memento mori.

В моем любимом блоге Avocado bytes Daniel Bryant делится своим взглядом с посте The Death of DevRel (Again?) and the Rise of Product Advocate and Community Roles.

Во время пандемии и сразу после нее, — пишет Даниэль, — всем пришлось обходиться без конференций и бустанул контент для разработчиков, dev‑адвокаты были нарасхват, целью многих DevRel‑команд был рост (не считаясь с расходами). А вот в 2022 компании начали экономить и сменили девиз на «делать больше малыми средствами». Кое‑где попросту избавились от DevRel‑команд или больше части сотрудников. Основная причина — до этого слишком много специалистов наняли в расчете на продолжающийся рост [та же штука, что и с разработчиками, что закономерно]. А вторая причина, как легко догадаться, — отсутствие четкой связи между работой команды и бизнес‑результатами [место для напоминания про серию постов Moving Developer Relations Forward].

Ситуация с увольнениями и наймами выровняется, — считает автор, — но DevRel выйдет из этих испытаний несколько измененным. DevRel ждет смещение функции в сторону dev‑адвокатства и сообществ.

Знакомимся с новым термином: технический SDR (sales development representatives). Продажники недостаточно технические ребята, чтобы разработчики хотели говорить с ними про инструменты разработки [именно их обычно продвигают при помощи Developer Relations на западе], а DevRel‑специалисты недостаточно ориентированы на продажи. Во имя прибыли компаниям ничего не остается, как сблизить эти две функции. Широкие брендовые жесты хороши для крупняка [что не всегда означает, что и там эти деньги предпочтут потратить с более понятной отдачей].

Что касается сообществ, то собрать его вокруг проблемы или продукта или работать с уже сложившимся полезно для продвижения продукта. Тем более что можно одновременно и работать на измеримые метрики (размер сообщества, активность, конверсия в воронку продаж), и быть полезным для участников.

[Так называемого «продуктового DevRel» у нас не так много, так что не у всех есть отдел продаж, куда можно сходить. Но вот если он существует, крайне рекомендую. Часто там люди более мотивированы, чем в маркетинге, и готовы экспериментировать с инструментами. DevRel? Почему бы и нет, если это поможет собрать лидов или продвинуть их по воронке. Во всех остальных случаях полезно подумать, что делает нашу функцию не предметом роскоши, на котором легко в случае чего сэкономить, а неотъемлемой и понятной частью чего‑то важного для компании.] #конспект

А вот на этом месте Алина Боровицкая рассказывает самую главную вещь про весь-весь маркетинг и коммуникации. Не благодарите:

Опубликованы видео докладов DevRel Conf #7, которая прошла 9 декабря.

Концепция у ПК была такая: даешь ссылку на плейлист и джун экономит дни (которые пришлось бы провести за сбором опыта старших коллег по чатам и подкастам), а синьор ставит на скорость Х1,5 и оперативно сверяется с лучшими примерами индустрии. В 2022 году девиз был «Власть, бюджеты и хэдкаунт», а в этом — «Бери и делай».

Поделюсь моим личным зрительским топом. Он целиком состоит из докладов про то, как оно там в 2023 году:

Алина Боровицкая (канал что-то на техпиарном) «Дистрибуция контента, и за что они с нами так» — тут поменялось примерно всё за последние года полтора.

Антон Черноусов (подкаст The Art Of Programming и другие) «Давай запустим подкаст... или нет» — доклад с актуальной статистикой и о том, как подходить к подкасту, когда их уже только ленивый не делает (или делает, но лениво)

Алина Каширская «Осторожно, тонкий лед: от IT‑катка до IT‑пикника» — о событиях года (в моем понимании). Раньше такого не было, а в этом году Тинькофф сделали. Странно было бы не обсудить на конференции 2023.

Полный плейлист конференции

#инструменты #devrelconf

Это все-таки не личный блог, поэтому просто ссылка на видео не прошла мой строгий редакторский контроль. Пришлось сделать конспект 😅 #opensource #communityrelations #этосновабылопыт

Конспект |Видео | Слайды со ссылками и материалами

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

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

Ксения Романова | DevRel и другие коммуникации в IT pinned «Этот канал ‒ обязательство! Обязательство регулярно разгребать завалы полезных материалов по Developer Relations и писать хотя бы коротенькие аннотации и мысли по поводу. Кто читает? @ks_romanova ‒ организатор DevRel-завтраков и митапа в Петербурге. На…»

Этот канал ‒ обязательство! Обязательство регулярно разгребать завалы полезных материалов по Developer Relations и писать хотя бы коротенькие аннотации и мысли по поводу.

Кто читает? @ks_romanova ‒ организатор DevRel-завтраков и митапа в Петербурге.

На какие темы читаю? #communityrelations #карьера #тренды #этосновабылопыт #инструменты #метрики #PR #opensource Иногда пишу от себя под тегом #блог

Несколько интересных постов и конспектов, которые стоит просмотреть:
3 новинки и 2 "старинки" с книжной полки
А что есть вместо хабра в глобальном интернете
Метрики сообщества, которые имеет смысл замерять
Как писать документацию, которая нравится разработчикам
Как нанять(ся) на работу DevRel-специалиста
Краткая и пристрастная подборка кейсов PR-премии Loud 2023
Развивая Developer Relations. Конспект в двух частях для популярной статьи в пяти частях ‒ часть 1, часть 2
Подборка докладов с DevRel Conf 2023
Сообщества вокруг технологии: почему быть бесплатным недостаточно


Подборка каналов про DevRel
Подборка каналов про Digital
Подборка каналов про комьюнити-менеджмент

Кажется, пришло время обновить закреп (конечно, дело к ночи, надо написать несколько текстов к DevRel Conf, пора!)

Сообщества вокруг технологии: почему быть бесплатным недостаточно? Расскажет в своем докладе Ксения Романова.
⠀
Важные составляющие успеха опенсорс‑проекта — это сообщество пользователей и сотворчество контрибьюторов. Ксения расскажет, как с помощью инструментов DevRel и маркетинга развивать сообщество, поддерживать совместное творчество и наращивать популярность проекта. А еще поделится списком метрик здоровья опенсорс-сообщества, который она составила и проверила на практике за время работы с Apache Ignite.
⠀
Ждём вас на HighLoad++ 2023 🖐
⠀
✅ Программа опенсорс-трека и билеты на сайте в описании канала @HighLoadChannel

Вообще-то это канал с конспектами, но не могу не заметить, что у нас произошла рекурсия: DevRel на сцене Highload++ 😁

Принесла вам ложку дегтя в видосике Why I Left Developer Relations. Ali Diamond 5 лет работала в DevRel, а потом вернулась на позицию software developer и счастлива. Давайте посмотрим, что ей не нравилось в профессии:

1)Мало писала код [Есть у нас тут пиарщики, которые тоскуют по пресс‑релизам?]

2)Компании сами не знают, чего хотят: заводят функцию из прихоти, предлагают одному человеку делать работу отдела, а с отделами тоже есть подвох, но о нем дальше [Для маркетолога вообще ничего нового, к сожалению]

3)Инфлюенсеры: круто, когда рынок знает человека, но создание контента только часть работы, которую нужно делать. В результате часто случается взаимное разочарование [Это почти что пункт два, когда от самого факта найма ожидают, что всё заколосится. Справедливо также в отношении некоторых других позиций в компании или целых модных направлений, вот, например, с облаками такое было когда‑то]

4)Невозможность отделить личное от рабочего в онлайне: как будто бы ты всегда выражаешь позицию компании или сообщества, никаких легкомысленных и рискованных шутеек [Мне это всегда казалось частью того, за что компания тебя «покупает»]

5)DevRel очень сложно измерить: а в бизнесе сейчас постоянно нужно доказывать, что команда необходима [Вам больше пункт 2 или 5 нравится? Всё такое вкусное! Вот тут как раз у PR и маркетинга есть чему поучиться и собранные на коленке велосипеды могут быть опасны для карьеры]

6)Никто не знает идеальной стратегии: очень все неоднозначно и зависит от конкретной компании и ситуации [Попейте чайку с маркетингом вашим, там уже давно придумали, как вертеться. Или не вашим, если ваш не вертится]

7)Нас увольняют первыми: Али за пять лет трижды увольняли при реструктуризации [Хотелось бы сказать, что пункты 5 и 6 могут вас подстраховать, но нет, иногда это решение никак не связано с продуктивностью, просто отказываются от того, без чего все еще можно функционировать. DevRel — функция для сытых.]

8)Техническая роль, с которой обращаются как с не технической [Это больше про «их нравы», когда DevRel вокруг продукта и надо уметь код прочитать, написать, и сделать яркую демку]

9)Люди: отрасль маленькая, зато эго у людей огого, и это приводит к конфликтам [В начале видео Али говорит: «Считается, что в DevRel (США, как я понимаю) 800 человек, ну теперь 799». Мы когда‑то по чатам на глазок насчитывали 400 человек в России. Наверное, кто‑то кого‑то бесит, отчего нет, но прямо скандалов пока не припомню.]

10)Очень ограниченные карьерные возможности: чтобы найти хорошую компанию, вменяемый менеджмент, где нужны твои навыки, да за них еще и могут достойно заплатить, нужно действительно постараться. Разработчику для этого нужно просто открыть резюме и вариантов будет намного, намного больше. [Абсолютно справедливо и для России, особенно для начальных и синьор+ позиций. Пожалуй, не только для DevRel, но и если интересно делать вещи определенного масштаба или в конкретной области. Обычно те же разработчики, что у нас, что на Западе, кочуют годами между пятью‑десятью банками или телекомами. Чтобы сделать шаг в сторону, нужна изрядная смелость] #професияdevrel #карьера #конспект

Продолжаем читать статью Jeremy Meiss Moving Developer Relations Forward в пяти частях, части 1-3 в предыдущем посте.

Часть 4 - Developer Relations and the customer journey
В этой части автор напоминает нам, что DevRel — это центр затрат, а не генерации прибыли. Так что именно он в начале списка “на чем бы можно было сэкономить в эти непростые времена”. И свою полезность лучше доказывать раньше, чем дело дойдет до этого самого списка. Вот зачем мы задавали вопросы? А вот зачем:

1)Показали себя широко в компании и завели полезные связи;
2)Выяснили потребности и восприятие DevRel до того, как расхождения могли бы вызвать проблемы;
3)Узнали про цели и KPI и кто как отчитывается.

Это помогает занять свое место в организации и обосновать ценность. И место это нужно искать внутри Developer Journey (Пути разработчика). В смысле, узнайте, как его видят в компании сейчас (искать надо где-то между маркетингом и продуктами обычно), найдите там свои активности и перестройте отчетность. Каждый пункт подробно развернут. Рекомендую читать целиком, там всё нужное, включая DevRel Qualified Leads мои любименькие. Это, конечно, про классический DevRel, но и на HR-бренд можно переложить, просто карта нужна другая - employee journey map.

Часть 5 — Positioning DevRel as a resource within your company
Раз вы про отношения с важной целевой аудиторией, значит, — делает вывод автор, — будьте ресурсом для всех, кому он нужен. Даже, — смело замахивается он, — для рекрутинга!

Например, продажам нужны вебинары и воркшопы — отлично, DevRel может помочь. Маркетингу нужны истории успешного использования продукта? [о да! моя любимая история: и вот два инженера из компании *** нахваливают продукт на нашей онлайн-конференции, а только представьте, куда бы послал нас их маркетинг, если бы мы попытались согласовать кейс обычным путем…]. А также можно использовать связи специалиста по DevRel с коллегами или разработчиками из других компаний для каких-то совместных активностей. В общем, мы не продажи и маркетинг, но мы — чертовски полезный ресурс.

В бизнесе ты или делаешь штуки, или продаешь штуки. Выстраивать свои цели нужно соответственно (или ты без работы). Если никто не пользуется продуктом, — ты без работы. Пришло время относиться к этому по-взрослому [to grow the fuck up, чтобы быть точными] и показывать бизнесу свою ценность там, где она есть, не дожидаясь вопросов “Так что вы делаете?” и “А какой от вас ROI?”.

А кто будет делать вид, что далек от бизнеса, добьется своего, и уже бизнес дистанцируется от DevRel-команды. #конспект

Ну как вам, откликается? 🔥 если да.

В англоязычном DevRel-сообществе весь сентябрь расходится ссылка на статью Jeremy Meiss Moving Developer Relations Forward в пяти частях. Там все, как я люблю: с особым маркетинговым цинизмом и волнением за профессию. Почитаем и мы.

Часть 1 — Moving Developer Relations Forward
Последние лет пять (может быть и дольше, но все что было до ковида сейчас кажется несколько туманным) активно обсуждают, что DevRel это вам не: продажи/маркетинг/пони и радуги/ваш вариант. И это обсуждение ведет профессию в никуда. Просто потому, что определение через “не” никак не помогает сформулировать то, что настолько сильно варьируется от компании к компании.

Часть 2 — The foundations of Developer Relations
Джереми вспоминает, что вообще-то DevRel существует уже лет 30, правда начинает не с Apple, как многие из нас привыкли, а с Netscape. Долго ли коротко ли, а DevRel — это организационная функция.

Часть 3 - Asking the right questions for DevRel impact
Здесь автор напоминает нам о прекрасной книге Первые 90 дней (Майкл Уоткинс, издательство МИФ) и собственном посте о том, как преуспеть на новом месте. Но также и дает вопросы, которые стоит задать ДО того, как принимать офер:

1)Как компания зарабатывает и где теряет деньги?
2)К какому отделу относится DevRel-команда?
3)Какие крупные цели у отдела и всей компании на этот квартал/год?
4)Откуда эти цели берутся и кто присматривает за их реализацией?
5)Что от нового специалиста ожидают в ближайшие 30/60/90 дней?
6)Зачем им тут вообще DevRel?

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

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

ТГ-каналы про Developer Relations и коммуникации в IT:

Говорите громче! - канал Жени Голевой про работу деврелом, публичные выступления, обратную связь и обучение взрослых

My DevRel - канал Натальи Макаровой про работу в DevRel

не доводи спикера - канал Адель Макашовой про работу со спикерами и не только

Логово редактора - канал Тони Татчук про контент-маркетинг в технологической сфере.

что-то на техпиарном - канал Алины Боровицкой про осознанный SMM, техпиар и софт-скиллы <3

Geek Relations - коммуникации и образование в ИТ. DevRel. TechComm. Knowledge management. ITHR. Немного BigData и AI.

DevRel Склад - канал Ксении Романовой с краткими конспектами и комментариями по материалам о Developer Relation и Community Management (в основном зарубежным)

23derevo - канал Лёши Федорова из JUG Ru Group о работе над IT-конференциями (самый движ происходит в чате канала)

Это работа для DevRel’a - канал @svetlanada с вакансиями для DevRel-менеджеров, Tech PR, редактуров технических текстов и IT HR

Деврел-бюро - канал, где Алексей Долгушев и Мишаня Сторожилов иногда рассказывают про DevRel и постят вакансии

Про DevRel - канал Анастасии Аткиной, CEO, Hack Agency Russia. Анастасия пишет про DevRel с агентской стороны

IT-brand rules - канал про IT-HR-бренд от команды исследования IT-брендов Хабра и Экопси

Технотекст - канал от команды Хабра о том, как писать и редактировать технические статьи (прежде всего на Хабр)

Решила обновить закреп и поняла, что с июля месяца списочек каналов успел немного вырасти, обновляю тут тоже:

Зачем оценивать, на какой стадии зрелости DevRel-функция в компании или отдельном направлении? Например, чтобы “штаны не порвать”, широко шагая в своем планировании через ступеньку. В статье The Developer Relations Capability Maturity Model Jordan Violet сформулировал путь, который проходит DevRel, таким образом:

1)Неорганизованные усилия, большая вовлеченность конкретных людей, часто в свободное время: на этом этапе жизненно важно найти сторонников в менеджменте, которые могут сказать “да, мы будем заниматься DevRel” (то есть, поручиться перед остальным руководством, что в этом есть смысл для компании)
2)Простые, но достижимые цели, 1-3 человека в команде: выбираем легко достижимые цели, чтобы доказать свою полезность
3)Сформулированы цели и задачи DevRel program [интересно, что у нас кальки с этой концепции никто не использует], бизнес признает пользу от вас: на этом этапе обычно появляется возможность расширить команду, тут важно не забыть периодически синхронизироваться с целями компании
4)На этом уровне уже запущены все ключевые проекты, но они могут как работать, так и стухнуть: если вы добрались до этого уровня, значит, прошло определенное время, но это не повод почивать на лаврах [просто вы ближе к пенсии на несколько лет мухаха, от описания автора возникает ощущение легкой заболоченности, что же, возможно, что сотрудники уже устали гореть, и да, это момент, когда команда может поменяться]
5)Ценность отношений с разработчиками понятна, а усилия можно измерить [вообще там написано “измерить количественно”, но я бы сказала просто измерить]: пик развития. главное продолжать делать всякие новые вещи на этом вашем новом уровне.

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

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

В общем, скорее пост — хороший повод для размышлений, но не прямо “бери и пользуйся”. #конспект

Cо мной тут поделились статьей Eight years of organizing tech meetups (привет, Стэн!) и спросили, что я думаю. Я думаю, что это офигенная статья, в первую очередь, по форме. Интернет переполнен историями успеха. И если дочитать до конца, то и эта могла бы называться «Как я создал большое клевое сообщество на дискорде». Но 90% статьи занимает рассказ про то, как автор раз за разом пробовал что‑то оффлайн организовать и бросал.

И это делает статью намного полезнее! Во‑первых, понятно, что организовывать что‑либо это достаточно серьезная дополнительная нагрузка (автор пишет про это прямым текстом).

Во‑вторых, что «что‑нибудь поделать» — недостаточно хорошая причина для разработчиков, чтобы собраться и тем более продолжать собираться регулярно. Охотнее всего люди собираются для закрытия своих потребностей. Например, у автора замечательно сработала группа для совместного чтения и обсуждения книг и статей про распределенные системы. Люди хотели разобраться в теме и группа дала им такую возможность.

Этих двух мыслей вполне достаточно, чтобы всячески советовать читать статью по ссылке. Третьей причиной, пожалуй, может быть знакомство с форматом paper reading club, которые не так уж распространены у нас, а жаль. #инструменты