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

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

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

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

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

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

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

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

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