Nataliya Makarova, [14.04.20 15:57]
Кажется, немного стоит пояснить мысль двух предыдущих постов.
В первую очередь речь идёт о компаниях, для которых технологии не являются основным бизнесом и которые только сейчас начинают трансформироваться и нанимать большие команды разработчиков.

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

Если менеджеры по бренду этой компании не сталкивались с задачей найма технарей, то им будет не просто сразу перейти на новые рельсы. В рамках бренда работодателя необходимо развивать дополнительное направление - developer relations, которое будет отвечать за технологическую репутацию компании, а также поддерживать внутренние и внешние коммуникации между it-специалистами, помогать компании встраиваться в технологическую экосистему.

А такие атрибуты как комфорт и плюшки - это даже не мотивация, а просто проявление заботы работодателя о сотруднике, которое демонстрирует уровень компании.

Еще одна распространённая ошибка касается непосредственно коммуникации с разработчиками вовне. Это контент который компания производит, желая привлечь внимание технологической аудитории.
Заявляя громко о своем технологическом преображении, пиар-службы начинают радостно публиковать новости об уникальных разработках. Стиль изобилует громкими маркетинговыми заголовками, официозными формулировками, пытаясь привлечь внимание модными технологиями, типа: IoT, искусственный интеллект, нейронные сети, AR, VR и т.д.

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

Почему это происходит?
NDA? Неуверенность в том, что есть чем гордиться и чем поделиться? Пиар, отвечающий за блоги на Хабре, не способен оценить прелесть и ценность технического изложения?
Причины разные, надо разбираться с каждой ситуацией отдельно.

Глобальный опрос за 2019 год от HackerRank подтвердил, что для разработчиков на первом месте стоят профессиональное развитие и обучение, а вот компенсация труда только на третьем. Более того, важно именно приобретение новых технических навыков. Это в два раза важнее, чем новые обязанности и расширение зоны ответственности и в четыре раза важнее, чем развитие soft skills.
Коррелируется это и с другим аспектом: в своём большинстве разработчики хотят расти в сторону технологического лидерства, например, стать главным архитектором. И гораздо меньше интересуются управлением людьми в роли менеджера.

Организаторы конференций оказались подвержены большому удару от пандемии. Они всячески стараются адаптироваться, перенести всё в онлайн. И их понять можно, так как это их основной хлеб. Но и многим деврелам, кто привык делать ставку на конференции и митапы, тоже кажется, что это беда. Но какое же это замечательное время вспомнить про истинную природу коммуникаций в среде разработчиков, которая с самого зарождения была основана на документации, полезных кейсах, онлайн-переписке, форумах и чатах, распределенных хакатонах и т.п.
Здорово, что появились инструменты для интерактивных онлайн-встреч, но я согласна с автором, что хорошо бы обратить внимание на основы.
https://bit.ly/MyDevRel63

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

Более семи лет я работаю в области продвижения технологий и tech employer brand. Разрабатываю стратегии и проекты, которые помогают компании построить технологическую репутацию и стать желанным работодателем для IT-талантов.

Мой принцип - правильно и точно сформулировать задачу, идею и метрики, зажечь ими разработчиков компании, и эффективные инструменты приложатся.

Я могу помочь:

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

За семь лет в области devrel и tech employer brand я работала с очень разными технологическими аудиториями и проектами, среди которых:

📌 C++ и Mobile DevRel Programs
📌формирование технологических комьюнити
📌поиск разработчиков-звезд и их поддержка
📌развитие региональных экосистем для новых офисов разработки
📌программный менеджмент научных конференций ШАД по ML
📌продвижение технологий и open-source.
📍Большое место в моей работе было уделено теме метрик и исследованиям, как активности devrel влияют на внутренний и внешний HR бренд, выстраиванию процесса, позволяющего оценить влияние мероприятий на прямой и отсроченный найм и многое другое.

Кому мой опыт будет полезен

❇️Молодым технологическим компаниям и стартапам
❇️Компаниям не IT сектора, но трансформирующим бизнес и нанимающим разработчиков
❇️It-лидерам, у кого стоит задача пересмотреть свою стратегию в области Devrel и Tech Employer brand

Как я работаю

Вы присылаете мне запрос с кратким описанием проблемы. Мы договариваемся о времени и способе коммуникации. Встречаемся или созваниваемся и более подробно проговариваем потребности и задачи - это бесплатно.
Если я понимаю, что могу помочь достичь ваших целей, то продолжаем работать в порядке платных консультаций.

✋Буду рада обсудить ваш проект!
📨Пишите мне в личные сообщения @NataMakarova!

Благодарю за перепосты! ⏩

Актуально ли сейчас вкладываться в бренд работодателя для технических специалистов?

Сейчас не очень понятно, что будет с наймом, планами на найм и перераспределением рабочей силы на рынке в случае сокращений. Все это определённо затронет и бренд работодателя, и работу с ним. Крупные компании могут пересмотреть и сократить бонусные программы, привилегии, льготы, мероприятия и активности, направленные на выстраивание коммуникаций с внешними разработчиками.
Где-то это вызвано реальными проблемами с финансами, но в какой-то степени это поможет компаниям как бы «обнулить» расширенный пакет льгот, чтобы снова его поднимать, тем самым повышая лояльность сотрудников.

Но то, как компании позаботятся о своих сотрудниках сейчас, может определить их бренд как работодателя на ближайшие десятилетия.

Многие IT-компании или команды могут продолжить работать полностью или частично удалённо и после официальных послаблений. А это значит, что дольше сохранится необходимость в продолжении специализированных корпоративных онлайн-программ и льгот для сотрудников.
В то время как какие-то компании приостановят найм или даже подумают о сокращениях, другие планируют расширять штат, воспользовавшись выходом на рынок хороших специалистов.
И у тех и у других есть возможность использовать это время и интенсивно инвестировать в свой бренд как работодателя для технических талантов. Как это сделать? Просто больше об этом рассказывать публично в своих сетях, каналах мессенджеров, блогах, Хабрахабре.

Вот только несколько идей, что может привлечь внимание технарей:

📍Рассказывайте публично в открытом блоге компании о том, что сейчас происходит у вас внутри, как вы организуете работу и заботитесь о сотрудниках: консультации психолога, йога, конкурсы рабочих мест, домашних животных и т.д.
📍 Повествуйте о технологических особенностях удалённой работы: как вы организовали техническую базу, с какими сложностями столкнулись и как их успешно преодолели, как ваши безопасники пришли в ужас, но пришли в себя и внезапно быстро всё разрулили.
Пара примеров: Яндекс , Вымпелком
📍Поделитесь успешными историями от своих тимлидов и менеджеров о процессах распределенной работы, которые помогли разработчикам эффективно взаимодействовать из дома. Примеры: Ланит, снова Яндекс
📍Пишите истории о неформальных вечеринках для разработчиков. Возможно, вы организовали zoomdevmeetup с интерактивными докладами, нетворкингом и скидками для каждого участника на доставку пиццы и пива на дом.
📍 Сделайте открытую телеконференции с известным разработчиком из иностранной компании , где он рассказывает, как проходит работа у них. А заодно пусть не только разработчики вашей компании, но и все желающие смогут её посмотреть. А вопросы, например, в качестве привилегии смогут задавать только сотрудники. Хотя формат за вами.
📍Откройте доступ и попиарьте уникальные образовательные программы, доступные только для ваших сотрудников.
📍Пусть ваш CTO записывает регулярные вдохновляющие и поддерживающие короткие видео для сообщества разработчиков, которые вы опубликуете в своих социальных сетях.
📍Может быть вы организуете онлайн хакатон на отвлеченную тему, или игру, или флешмоб тимлидов с отжиманиями по утрам и обливаниями холодной водой.

А ещё лучше спросите самих разработчиков, как им по душе отвлечься и развлечься. И не забывайте рассказывать об этом правильно, помня о том, кто ваша целевая аудитория 😉

​​В начале апреля я уже делилась своим мнением на счёт онлайн-форматов мероприятий для разработчиков и о том, что просто перенести митап в интернет кажется не очень правильной идеей. Важно идти от первоначальной задачи, а может быть даже и её пересмотреть.
Вот и Кирилл Анастасин в своём видео рассуждает в том же ключе и убеждает аудиторию помнить о целях, ценности контента и пользе для целевой аудитории. А то, каким образом задача будет решена, может кардинальным образом отличаться от привычных форматов.

​​Хочу сегодня рассказать о своей системе, по которой я работаю с компаниями по вопросам аудита бренда работодателя для технических талантов и devrel стратегии.
По сути это микс особенностей коммуникаций с технологической аудиторией и стандартных маркетинговых подходов.

Здесь я писала о том, как анализировала региональную экосистему. Похожую методику я разработала и для сканирования эффективности программы коммуникаций бренда с технологической аудиторией. Комплекс состоит из восьми компонентов:
EVP
Корпоративный климат и лояльность сотрудников
Контент
Каналы
Мероприятия
Карьерный сайт
Взаимодействие с сообществами
Конкурентная среда

В комплексе компоненты позволяют увидеть слабые зоны и возможности для развития программы коммуникаций с разработчиками.
Каждое направление схемы нуждается в дополнительной проработке и создания концепции. Например, необходимо разработать и протестировать EVP для технических талантов, оптимизировать сайт о карьере, вакансиях и жизни компании под ИТ-талантов, сформулировать политику взаимодействия с профильными комьюнити и конференциями, определить концепцию технологического контента для собственных и партнерских каналов и т.д.
Каждый из компонентов включает в себя набор инструментов, подобранных индивидуально с учетом целевой аудитории, технологического стека, особенностей взаимодействия внутри профессионального сообщества и т.д. И как нет одинаковых компаний, так нет единого универсального подхода и решения для всех.
Это непосредственно связано и с Tech Candidate journey, так как я уверена, что путь разработчика в компанию начинается задолго до его контакта с рекрутером. Об этом я ещё напишу пост.

И когда я работаю с компаниями, то меня интересует всё: от разрабатываемого продукта, стека технологий, планов на найм, проблем процесса найма до поиска тех харизматичных и талантливых разработчиков в команде, кто может стать амбассадором бренда. В каждом из моих опросников для CTO, HRD, рекрутера, тимлидов и разработчиков около 50 вопросов. И, конечно, не подумайте, что я прошу заполнять их письменно 😉. Встречи с заинтересованными сторонами - это глубинные интервью, когда можно раскрыть потенциал людей, компании и одновременно увлечь задачей и мотивировать участвовать в devrel программе.

Если интересно узнать больше об аудите, пишите!

Обсуждаем в @MyDevRelChat

В процессе работы приходится очень подробно разбирать процесс рекрутмента, так как это тоже часть работы с репутацией компании как работодателя и напрямую влияет на результат найма. Если здесь есть проблемы, то они могут потянуть вниз за собой весь бренд.
Модное сейчас направление MarHR адаптировало под свои нужды Customer journey map. Так, в распоряжении рекрутеров теперь есть Candidate или Employee journey map. В основном всё крутится вокруг процесса найма от момента, когда с кандидатом связался рекрутёр до принятия или отказа кандидата от оффера.
Как это выглядит:
Рекрутёр публикует вакансию на карьерном сайте или ресурсе вакансий —> заинтересованные кандидаты, увидев вакансию, изучают компанию и отправляют своё резюме. Другой вариант - рекрутёр, опубликовав описание вакансии, ищет кандидатов сам —> находит профиль потенциально интересного кандидата —> связывается с человеком по e-mail/message/phone call —> кандидат отказывается сразу или соглашается посмотреть на описание вакансии.
Если описание заинтересовало, то кандидат начинает искать информацию о компании: карьерный сайт, каналы в социальных сетях, публичный корпоративный блог, новости и даже финансовые показатели. Все эти ресурсы - точки соприкосновения кандидата с брендом. В расширенной карте путешествия кандидата уделяется внимание и отзывам знакомых, работающих в настоящий момент в компании, и отзывы бывших сотрудников, и даже тех, кто уже проходил собеседования.
Дальше кандидат принимает решение, идти ли на собеседования, выполнять ли тестовое задание и пр. Последующими важными этапами в этом путешествии является то, какие впечатления останутся у кандидата от встречи с рекрутером, нанимающим менеджером, потенциальным руководителем и т.д. Это приводит либо к принятию оффера, либо к отказу от предложения.
В процессе возможны варианты, так как на этом пути могут быть обучающие программы, как старт карьеры в компании, известность бренда как производителя известных продуктов, услуг и т.д.

Такая стандартная карта пути кандидата в компанию вполне себе работает для большинства специальностей, но только не для разработчиков. Почему?

Разработчики крайне редко откликаются на вакансии сами - их надо искать и хантить. Сложности подстререгают рекрутёров на всех этапах, но большинство проблем начинается с первого контакта - письма или звонка, когда разработчики не отвечают или отказываются рассмотреть вакансию. В воронке поиска разработчиков такие отказы - это львиная доля и, в зависимости от репутации бренда, процент отказов может доходить до 90%.

Именно поэтому я утверждаю, что путь разработчика начинается задолго до звонка рекрутёра. У разработчиков всегда есть выбор: предложения о работе прилетают к ним с завидной регулярностью. И зря рекрутеры думают, что что-то сильно зависит от их оригинального захода, заманивающего стиля сообщения. Даже хорошо составленное описание вакансии может не произвести впечатления.

Задолго до того, как на технического специалиста вышел рекрутёр, он должен уже как-то пересекаться с брендом. Желательно, чтобы это были точки соприкосновения в контексте технологической репутации:
📍статьи и посты на Хабре и других ресурсах о технологиях(GitHub, Reddit и т.д.)
- технологические конференции
📍митапы компании для разработчиков
📍профессиональные чаты и т.д.
- сообществах для разработчиков и др.

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

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

Путь технического кандидата в компанию (Tech Candidate Journey) тернист и многовариативен. Иногда это мне напоминает детские квесты :)🤣

​​Не кодом единым или как разработчику написать статью: интервью с Антоном Полухиным

"Если пишем “статью-ужастик”, то в завязке надо показать страшный кусок кода, в кульминации всячески с ним бороться, улучшать и показывать как сделать правильнее, а в развязке показать как все стало хорошо".

Антон Полухин — эксперт-разработчик C++ в Яндекс.Такси, представитель России в международном комитете по стандартизации C++, автор статей и книги “Boost C++ Application Development Cookbook”.
Антон — один из самых известных российских разработчиков C++ и уже вошел в историю своими предложениями в стандарт языка. Яркий докладчик, гуру стандартизации, помогает разработчикам готовить предложения в стандарт и защищает их на заседаниях международного комитета.
Меня всегда удивляла неистощимая энергия Антона в направлении авторства статей, выступлений, работы в комитете и т.д. Захотелось попробовать раскрыть этот феномен. Надеюсь, это поможет деврелам мотивировать разработчиков делиться опытом, а разработчикам вдохновиться писать не только код, но и статьи, а также выступать и развиваться.

"...Ты автор книги про библиотеку Boost C++ , которая уже вышла во втором издании в Лондоне. Как вообще возникла идея её написать?
Идея пришла ко мне в почту со словами: “Привет! Я работаю на издательство и вижу что ты активный разработчик библиотек Boost. А не хочешь ли написать книгу?!”. В этот момент у нас шёл ремонт, и это был идеальный повод откосить от выравнивания полов своими силами!
Позже, я поднапрягся и сделал так, чтобы примеры из книги можно было модифицировать, компилировать и запускать онлайн http://apolukhin.github.io/Boost-Cookbook/
Первое издание людям понравилось, поэтому через пару лет издательство пришло за вторым.
Сейчас книга переводится на русский язык и должна появиться на полках в этом году.

Как ты работаешь над структурой, формой?
Тут все как на уроках литературы: у каждой статьи должна быть завязка, кульминация, развязка. Для технических статей первое и последнее должно быть минимальным по размеру.

Как подбираешь кейсы, примеры кода, иллюстрации для статей?
Если пишем “статью-ужастик”, то в завязке надо показать страшный кусок кода, в кульминации всячески с ним бороться, улучшать и показывать как сделать правильнее, а в развязке показать как все стало хорошо.
Если же пишем “статью-документалку” о прошедшем мероприятии, то в завязке надо нагнать интриги, полусловом обмолвившись об интересных вещах. В кульминации описываем всё как есть, сосредоточившись на самом интересном и значимом. Ну а в развязке подводим краткий итог и делаем намёк на сиквел..."

Продолжение https://bit.ly/MyDevRel72

Знаете ли вы, что деврелу есть дело до всего, что происходит в компании?

РЕКРУТМЕНТ

Особенно если задачи заточены под Employer Brand.
Деврел должен изучить весь процесс найма: от стиля описания вакансии и реальной потребности в том или ином специалисте до качества собеседований, продолжительности цикла найма и условий оффера. А еще важно понимать специфику HR-аналитики, в которую надо грамотно встроиться.

Почему?
Можно строить репутацию и рассказывать, как здорово в компании, а на деле, к примеру, кандидату не очень понятны требования и то, как он может связать свой опыт с тем, что хочет компания в конкретном случае. Кандидат также может столкнуться с токсичной средой на интервью или приходится бесконечно долго ждать ответа рекрутера.

HR и ВНУТРЕННИЕ КОММУНИКАЦИИ

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

ПРОДУКТ

В случае любых задач devrel должен хорошо изучить продукт, его ценность, плюсы и минусы.

Почему?
Зная достоинства и недостатки, планы и перспективы развития продукта, деврел сможет разрабатывать более убедительные сообщения, создавать правдивое и аутентичное ценностное предложение, работать со стереотипами и т.д. А также быть готовым правильно отвечать на вопросы типа: «А почему у вас такой ужасный продукт?» :)

МАРКЕТИНГ

Однажды мне пришлось доказывать нашему главному по маркетингу, почему мы тоже не просто плюшки на мероприятиях проедаем. Когда директор по маркетингу мыслит целевой аудиторией в миллионах пользователей, а стоимость контакта в его видении должна стремиться к 0,5-3 рублям, то ему кажется немыслимым, что ёмкость рынка разработчиков конкретной специализации может насчитываться парой десяткой тысяч человек всего, а стоимость контакта доходит порой до 15К в зависимости от ценности, редкости специалиста и инструментов коммуникации.
Мы используем принципы и инструменты маркетинга: проводим исследования, сегментируем, анализируем, строим эффективные коммуникации, достигаем целей. Просто аудитория у нас дорогая, а задачи нетривиальные.
Кажется, убедить удалось :)

PR

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

ЮРИСТЫ

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

ФИНАНСЫ

Здесь очевидно, что речь идет про бюджеты. В какой момент и как правильно формировать бюджет и как его защищать перед CFO, чтобы его не урезали. Как провязать эффективность своей работы не только с качеством и количеством, но еще и с финансовыми показателям компании в целом. Таким образом деврел должен быть в курсе финансового состояния компании и того, какую дополнительную стоимость он привносит.

Кому-то везёт и часть функций распределяется между специальными подразделениями компании, однако и в этом случае помнить обо всем этом нужно деврелу самому.

​​Мои правила работы с профессиональными сообществами разработчиков
на примере взаимодействия с C++ User Group Russia

Для кого:
пост может быть полезен деврелам, эйчарам, лидерам технологических сообществ.
Чем интересен:
пишу о принципах взаимодействия компании с независимым сообществом, о логике принятия решений, ожиданиях и результатах.

Почему компаниям важно работать с комьюнити?
Для своей работы я вижу такие базовые плюсы, как:
📌возможность проведения различных исследований рынка;
📌получение честного и прямого фидбэка на технологию, продукт, идею, проект;
📌влияние на внутренний и внешний employer бренд;
📌взаимодействие с лидерами мнений в конкретном технологическом направлении и влияние через них на более широкую аудиторию и др.

Что я считаю самым важным при работе с технологическими сообществами?

Открытость и взаимное уважение целей и интересов.
Я сразу стараюсь понять цели сообщества, его лидеров и организаторов, ведущих участников. Важно, чтобы были пересечения с задачами того проекта, который я веду.
Продолжение...

26 мая у меня на канале был пост про путь кандидата в компанию и точки соприкосновения IT-специалиста с брендом потенциального работодателя до контакта с рекрутером.

16 июля в 15:00 пройдёт вебинар от Codenrock «Инструментарий Developer Relations для решения HR-задач», где эту тему раскроет подробнее Алексей Долгушев.

"Представьте: вы спрашиваете у кандидата на вакансию, что он знает о вашей компании, а он отвечает, что слышал доклады от ваших инженеров на конференциях и читал статьи о вас на Хабре. По статьям и докладам думает, что вы в компании занимаетесь интересными задачами, что ему нравятся ваши ценности, технологии и как организован процесс. Что в целом откликнулся на вакансию, потому что уже что-то знает о вас и эта информация ему нравится."
На вебинаре пойдет речь о том:
✅ Какие бывают разновидности DevRel?
✅Как отправить своих сотрудников рассказывать истории во внешнем мире в рамках DevRel;
✅Как синхронизировать DevRel и HR.

Участие бесплатное, но необходимо зарегистрироваться https://bit.ly/30aERZ0

Партнерский пост

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

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

Когда компании нужен devrel специалист?
===========

ПРОДУКТОВЫЕ И БИЗНЕС-ЗАДАЧИ
—————————————————-
📍Когда разработчики и вообще IT-специалисты в том числе являются потенциальными клиентами/ покупателями или просто пользователями продуктов компании: технологий, инструментов, сервисов и т.д.
Например, JetBrains, JFrog, Red Hat и др.

📍У компании есть интересные наработки или идеи, хочется доработать их в формате open-source, привлекая внешнее комьюнити.
Так, Google дорабатывал свои проекты Chromium, Android, Tensor Flow и др.


НАЙМ И УДЕРЖАНИЕ
———————————
📍У компании есть планы сильно растить команду разработки и нанимать сильных специалистов. Если речь идёт о 5-ти людях в год, то деврел - не та история. Но если предполагается привлекать более 15 человек в год, то "заметность" компании в профессиональном информационном пространстве будет помогать рекрутёрам нанимать.

📍Для IT-компаний выстраивать коммуникации с разработчиками является органичной практикой. Но сейчас все больше компаний, чей бизнес далек от IT, трансформируют свои процессы и им необходимо нанимать айтишников. И здесь как никогда необходима помощь деврел-специалиста.

📍Для профессионального "социального поглаживания" разработчиков компании.
У сотрудников есть возможность писать статьи, выступать на конференциях, помогая компании, и, вместе с тем, продвигая свой личный бренд. Разработчикам приятно, если его друзья, бывшие коллеги или просто знакомые говорят, что "я слышал про вашу компанию - интересные вещи делаете".

📍Для улучшения внутренней культуры, когда профессиональное развитие сотрудников признается ценностью.

📍Для обмена знаниями и улучшения профессиональной коммуникации между разработчиками внутри компании.


РЕПУТАЦИОННЫЕ ЦЕЛИ
————————————
📍Формирование и поддержание технологической репутации для повышения капитализации и нематериальной стоимости компании. Как правило речь идёт о патентах и инновациях, но и рассказ об этом вовне тоже будет добавлять плюсов в глазах стейкхолдеров.

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

ИНТЕРЕСНЫЙ ФАКТ
——————————
❇️Согласно исследованиям, Apple Inc. воспринимается как самая инновационная компания, однако занимает лишь 43 - е место по своим расходам на НИОКР.

Наболело
===============

Кажется, пришло время это написать.

После очередного вебинара от рекрутера, найденного мной на просторах сети про то, как нанимать с помощью деврел, я поняла, что меня переполняет возмущение.
==========
Друзья, DEVREL - это не инструмент MarHR и рекрутмента!
==========
DevRel - это принцип, лежащий в основе бизнеса и менеджмента компании в целом. DevRel - это не про то, как показать разработчикам, какие мы хорошие и заманить их к себе на работу. DevRel - про то, как создавать продукт и сервис, которыми гордятся сами разработчики, а также про то, какими должны быть процессы работы над созданием этого продукта внутри компании.
DevRel - это как фундамент для репутации, к которой стремятся технологические компании. Если фундамента нет, то все может рассыпаться в непредвиденный момент. Если технари на рынке признАют и станут уважать компанию за уровень разработки, качество кода, прозрачность и вклад в развитие сообщества (через полезные штуки в open-source, обучающие и открытые доклады и статьи, работу над стандартами и др.), то не будет проблем ни с наймом, ни с продажей продукта.

В предыдущем посте я писала о том, когда нужно нанимать devrel специалиста и в том числе указывала на hr-задачи. Однако это не значит, что devrel должен быть исполнителем для рекрутмента.
DevRel влияет на многие процессы и ему есть дело до всего - см. выше.
✅А это значит, что DevRel - стратегическая функция и игра в долгую.

Поддержите, кто со мной согласен!

✋Всем привет!
Весь октябрь я хочу посвятить тому, чтобы встречаться и общаться с коллегами из разных компаний.
Если вы хотите:
🔅посоветоваться
🔅разобрать кейсы
🔅обсудить новую стратегию или
🔅 у вас просто есть вопросы про деврел, пишите.

Мы встретимся с вами онлайн тет-а-тет за чашкой кофе и обсудим наши профессиональные темы.

Встречи абсолютно бесплатны, конфиденциальны и дружественны.
Напишите мне в личку @NataMakarova, чтобы договориться о дате и времени встречи.
📝Увидимся!

Мой первый опыт участия в подкасте. Буду рада узнать ваше мнение, ответить на вопросы и даже поспорить 🤗 https://news.1rj.ru/str/huntflow/467