Вебинар "How to Steward Your Career in Community" от Кэрри Мелиссы Джонс (автор книги про сообщества брендов)

Самым полезным оказалось коротенькое вступление от Кэрри Мелиссы: достаточно редко ищут на стартовые позиции, это "узкое место" в профессии - людям трудно начать - поэтому, если у вас есть возможность стать ментором, сделайте это.
Работает ли это у нас? Кажется, что прямо сейчас, когда команды растут, как раз есть шанс у тех, кто хочет начать работу в деврел.

Дальше идет пример, как искала работу гостья (ну это больше про их рынок) и советы от карьерного консультанта (про поиск работы в принципе для тех, кто делает это нечасто).

#communityrelations #карьера #конспект

Developer Relations Career Insights From 7 Industry Leaders

У зарубежных коллег все еще не выпускают готовых DevRel специалистов, так что, откуда они берутся и что делают, не так уж и очевидно (какая знакомая картина). Автор статьи вынес для интересующихся и начинающих полезного из разговоров с состоявшимися профи. Вынесем и мы. В квадратных скобках комментарии про ситуацию в России, ориентируясь на то, что вижу я и на самое свежее на сегодня исследование Жени Голевой (лето 2021).

1)Во многих компаниях это все еще один человек, который делает всё, но в последние несколько лет начали появляться специализации и вообще стало можно говорить о каком-то "карьерном пути" [то есть, мы идем почти в ногу]

2)Откуда приходят: от разработки до маркетинга и продаж [как уже выяснили в свое время, ситуация на русском рынке, где DevRel завязан на рекрутинг и HR-бренд, уникальна, если сравнивать с Европой и Америкой]

3)Дипломов нигде не выдают, но есть набор навыков, которые пригодятся специалисту с любым опытом: эмпатия, коммуникация, умение переключаться между задачами, обучаемость [никаких возражений]

4)Самое сложное в профессии: всё то, что называют среди плюсов(много разных задач, все постоянно меняется, много общения), а еще сложность демонстрации результатов бизнесу [место для срача по поводу метрик]

5)Как начать: все больше специалистов нужно на рынке [в начале 2021 так и у нас было, про 2022 будет понятнее к осени]. Главный совет начинающим: начните. Не дожидаясь изменения названия должности, напишите пост в блог, поучаствуйте в организации митапа и т.п. [Ну прямо с языка сняли! Лучший совет, я проверяла.]

#карьера #конспект

Авторы статьи How to Tell If a Potential Employer Has a Burnout Culture составили список "звоночков" на собеседовании. HBR немного капитанят, но к каждому пункту дают список полезных проверочных вопросов, так что есть материал для подумать. Итак, если есть один или несколько признаков, высоки шансы, что что вас заездят без всякого work-life balance:

Практикуются "высиживание" рабочих часов важнее, чем сделать работу, неожиданная смена планов, авральная работа.

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

Непрозрачность оценки сотрудников: непонятно, что нужно для пересмотра зарплаты и повышения (в идеале все должно быть прописано).

Нет постоянной программы развития сотрудников.

Нет культуры обратной связи, работы с ошибками.

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

Проблемки с ценностями (они как бы есть, но ими не пользуются).
Меня так заинтересовал этот блок, что я даже приведу полный список вопросов по нему:
- Как эта позиция связана с миссией компании?
- Как ценности компании влияют на принятие решений?
- Как работа команды влияет на выполнение целей компании?
- Какие OKR?
- Поддерживает ли компания общественную активность в рабочее время?
- Какой вклад вносит компания в местное сообщество?

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

Посмотрела запись онлайна с Настей Кабищевой, где она рассказала, как начала делать DevRel для армянского банка, где проект, несмотря на удачные первые шаги, поставили на паузу: https://www.youtube.com/watch?v=wJlRaVnV3Zs

Выделила несколько особенно интересных мне “граблей”, на которые может наступить даже самый синьорный синьор, потому что “дело не в тебе, username”.

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

Решение сверху есть, а понимания нет. Так появляются странные метрики (ни с одной из которых запрашивающие не знают, что делать) и бесконечные отговорки на среднем уровне. Мне очень понравилось, как Настя вела от “хорошо бы” к конкретике через серии встреч, итоги каждой из которой четко фиксировались.

Нет понимания, но есть страхи. Многим бы хотелось, чтобы люди на работе работали без всякого вот этого там межличностного. Но так не бывает. Сверху сказали, что мы делаем что-то непонятное, появляется новый важный человек со своими идеями, обсуждает их с твоим руководством… а не подрывает ли это твою репутацию и власть, директор по маркетингу или HRBP? Кое-кто может подумать, что да. И начнет саботировать реализацию задуманного. Тут всегда многое зависит от личностей людей, с которыми нужно договариваться, и нет 100% гарантии, что договориться получится. Хороший пример из записи: как Настя разбирала возражения, пытаясь узнать, откуда (пред)убеждение появилось.

Иногда эти страхи оправдываются. Например, покажут людям на конференциях или курсах какие-то передовые инструменты или процессы, они расстроятся и уволятся. В общем, до того, как начали что-то менять (до вас), тут было лучше. После, как мы понимаем, не означает вследствие, но многих необходимость что-то менять раздражает. Также как и те, из-за кого (ну так все выглядит) это придется делать. Стоит ли оговаривать возможные негативные последствия заранее? Не уверена, что это хорошая идея. Скорее уж поможет трезво оценить вместе с руководством все слабые места. Пример из стрима: поиски архитектора, которого вряд ли заинтересует предложение вместо того, чтобы вырастить человека внутри.

DevRel-бюджет не был заложен в текущий год. И этот пункт тоже про работу с людьми. Можно поискать, вписывается ли трата в маркетинг, HR, обучение или нужно согласовывать ее отдельно (и через кого это будет проще сделать). Очень хороший пример в стриме про согласование DevOps Conf и участия в Highload++ Armenia

Актуально для работы в “странах релокации”: для работы с HR-брендом может понадобиться знание местного языка, а для работы с сообществом - местного и английского. И на этом моменте часть спикеров или стендистов (например, владеющие только русским и английским) может просто отвалиться.

Очень полезный стрим, есть, над чем подумать. #конспект #карьера

Наконец дописала рекап нашего стрима про резюме, собеседования и все такое на джуновые и мидл позиции в DevRel. Получила за это время несколько отзывов, судя по ним, вопросы мы выбрали правильные и ответили на них достаточно развернуто. Намного больше люблю оффлайн, но чтобы собрать таких экспертов, можно и стрим. Теперь со вкусом букв: https://habr.com/ru/articles/738334/ #карьера

A review of DevRel job titles and career progression

Hoopy (DevRel-консультанты и организаторы DevRel Con) выложили результаты исследования на предмет того, какими должностями наделяют ответственных за DevRel. Начнем с теории. В списке основных "ролей" кроме дев-адвокатов и ожидаемого управления сообществами появилось что-то новенькое: Developer Educator. Не волнуйтесь, это знакомая песня на новый лад (и, возможно, ее исполняете именно вы).

Адвокатов поделили на несколько видов:
- outreach-focused (по-старому это "евангелисты")
- product-focused (больше про обратную связь с пользователями продукта для разработчиков, создание или инициация создания удобных доп инструментов и т.п.)
- internal (развитие инженерной культуры внутри, внутренние сообщества, коммуникация между командами и т.п.)

Пока ярче всех сияют outreach-focused адвокаты, менеджеры по развитию сообществ возделывают почву, на которой расцветает developer program (то, что и зачем будут делать с разработчиками в принципе).

До недавнего времени контент для разработчиков чаще всего создавали техписы и тренеры, а дев адвокаты заполняли пробелы менее формальным контентом. Developer educator беспощадно рвет со своим прошлым и в то же время трепещущей рукой сбрасывает таинственный покров будущего разрабатывает learning journeys (как customer, только learning), не чуждаясь новых форматов и педагогических приемчиков.

Для каждого вида специалистов есть примерный список обязанностей (основных и тоже встречающихся), требования и даже обозначено место на "радаре DevRel": Адвокатство, Маркетинг, Сообщество и Успех пользователя (Enablement). Ну и пару страничек посвятили карьерной лестнице.

Кроме трех основных типов должностей в классификацию вошли:
- менеджер программы (как менеджер проекта, только программы)
- операционный менеджер (ежедневная поддержка деятельности DevRel-команды)
- Developer experience engineer (как будто бы выделенная в отдельную роль часть работы дев-адвоката, если пользовательский опыт критически важен для коммерческого продукта)
- Developer success engineer (как техпод, только еще лучше, потому что активно ищет, как бы сделать жизнь инженера-пользователя лучше)

С одной стороны, старая работа - новые названия. С другой стороны, такие переименования и пересборка "шляп" на отделе (даже если головных уборов по-прежнему больше, чем голов) отражают приоритеты компаний и следить за ними поэтому полезно. #тренды #карьера

Принесла вам ложку дегтя в видосике 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 #карьера #конспект

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

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

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

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


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

Чужой опыт и кое‑что о дохлых лошадях

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

По последнему пункту я тут недавно послушала жутких историй (не все из мира DevRel, если что) и каждый раз вспоминала очень удачный пост Татьяны Гороховской (канал PRODUCTHR) про сотрудников‑«маугли». Что мне нравится в продактах, так это их прагматичность на грани цинизма. Если обычно люди начинают говорить о том, что чувствуют: сдаваться неправильно (внутренняя мама осуждает) или жалко вложенных усилий (лошааааадка!), то Татьяна предлагает убрать эмоции и посмотреть на результат: с чем сотрудник, закаленный преодолением, выходит из компании. На руках у него остается запредельное умение терпеть и работать в невыносимых условиях, пока все остальные учились делать классные проекты и росли.

Мне кажется, это идеальный рецепт для определения степени дохлости лошади. Отодвигаем внутренний голос с криками «что теперь, сразу всё бросать, чуть что неудобно?!» и честно спрашиваем себя: с чем ты выйдешь из этой ситуации и как полученный опыт поможет тебе в карьере? Если становишься гуру по хитрым способам обойтись без сна и отпуска, а из обновлений в резюме можно занести только нервный тик, стоит задуматься. Не над тем, плохой ли ты человек, если что‑то бросаешь. Потому что ты не бросаешь, а заботишься о своей стоимости на рынке труда.

Тот самый пост про синдром маугли на канате PRODUCTHR

#карьера

Про переход в DevRel из PR

Пока в декабре 2024 Исследование русскоязычного DevRel еще только оформлялось, подробно обсуждала с Пиархаб тему перехода в DevRel. Отвечала на вопросы о том, что за работа, кто ее делает, надо ли уметь писать код и т.п.

Читать в Журнале Пиархаб

У нашей области есть привлекательные стороны: большая эмоциональная отдача и зарплата. Из того же Исследования мы узнаем, что 80% опрошенных довольны своей работой, хотя и недовольны зарплатой, но объективно медиана по ней в сравнении с другими специализациями в коммуникациях у нас неплохая. К минусам те же пиарщики, как мне кажется достаточно привычные: сложная конфигурация стейкхолдеров, некоторая неопределенность карьерного пути, перегрузки.

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

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