DevRel skladно говорит

В процессе обсуждения перебрала свою PR-библиотечку, и нашла сборник эссе Михаила Умарова “PR в реальном времени. Тренды. Кейсы. Правила” 2016 года (на фото в центре). В основном работает до сих пор. Особенное внимание обратила на главу “Как измерить результаты PR”. Пожалуй, уроки пиарщиков и деврелам подойдут. Сделала конспект (чего не сделаешь, чтобы убрать книгу обратно в шкаф уже).

Они еще и квиз сделали по мотивам исследования. Так что если лень читать, начать можно с него: https://commonroomresearch.typeform.com/devrelroles2023 Меня разоблачилиопределили довольно точно

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 (как техпод, только еще лучше, потому что активно ищет, как бы сделать жизнь инженера-пользователя лучше) С одной стороны, старая работа - новые названия. С другой стороны, такие переименования и пересборка "шляп" на отделе (даже если головных уборов по-прежнему больше, чем голов) отражают приоритеты компаний и следить за ними поэтому полезно.

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

Кажется, собирается новый книжный пост. В прошлый раз были книги на английском, теперь фиг знает, как их купить, зато вот эти относительно свежие (третья, про hr brand, только что вышла).

Посмотрела запись онлайна с Настей Кабищевой, где она рассказала, как начала делать DevRel для армянского банка, где проект, несмотря на удачные первые шаги, поставили на паузу: https://www.youtube.com/watch?v=wJlRaVnV3Zs Выделила несколько особенно интересных мне “граблей”, на которые может наступить даже самый синьорный синьор, потому что “дело не в тебе, username”. Это может быть неудачный момент для старта/переформатирования DevRel. Да, наверху могли решить, что DevRel развивать пора. Но на самом деле, все внимание может концентрироваться на более важном по факту для бизнеса проекте. Туда же будут уходить и ресурсы, включая внимание руководства. А для того, чтобы произошли серьезные (и болезненные иногда) изменения, это внимание жизненно важно. Просчитать уместность момента снаружи крайне сложно, особенно, когда нанимающие менеджеры сами недооценивают сложности и транслируют на собеседовании скорее желаемую картину, чем реальную (но про это вы узнаете намного позже). Решение сверху есть, а понимания нет. Так появляются странные метрики (ни с одной из которых запрашивающие не знают, что делать) и бесконечные отговорки на среднем уровне. Мне очень понравилось, как Настя вела от “хорошо бы” к конкретике через серии встреч, итоги каждой из которой четко фиксировались. Нет понимания, но есть страхи. Многим бы хотелось, чтобы люди на работе работали без всякого вот этого там межличностного. Но так не бывает. Сверху сказали, что мы делаем что-то непонятное, появляется новый важный человек со своими идеями, обсуждает их с твоим руководством… а не подрывает ли это твою репутацию и власть, директор по маркетингу или HRBP? Кое-кто может подумать, что да. И начнет саботировать реализацию задуманного. Тут всегда многое зависит от личностей людей, с которыми нужно договариваться, и нет 100% гарантии, что договориться получится. Хороший пример из записи: как Настя разбирала возражения, пытаясь узнать, откуда (пред)убеждение появилось. Иногда эти страхи оправдываются. Например, покажут людям на конференциях или курсах какие-то передовые инструменты или процессы, они расстроятся и уволятся. В общем, до того, как начали что-то менять (до вас), тут было лучше. После, как мы понимаем, не означает вследствие, но многих необходимость что-то менять раздражает. Также как и те, из-за кого (ну так все выглядит) это придется делать. Стоит ли оговаривать возможные негативные последствия заранее? Не уверена, что это хорошая идея. Скорее уж поможет трезво оценить вместе с руководством все слабые места. Пример из стрима: поиски архитектора, которого вряд ли заинтересует предложение вместо того, чтобы вырастить человека внутри. DevRel-бюджет не был заложен в текущий год. И этот пункт тоже про работу с людьми. Можно поискать, вписывается ли трата в маркетинг, HR, обучение или нужно согласовывать ее отдельно (и через кого это будет проще сделать). Очень хороший пример в стриме про согласование DevOps Conf и участия в Highload++ Armenia Актуально для работы в “странах релокации”: для работы с HR-брендом может понадобиться знание местного языка, а для работы с сообществом - местного и английского. И на этом моменте часть спикеров или стендистов (например, владеющие только русским и английским) может просто отвалиться. Очень полезный стрим, есть, над чем подумать.