Наталия Макарова про технобренд и DevRel

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

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

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

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

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

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

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

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

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

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

ЮРИСТЫ

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

ФИНАНСЫ

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

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

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

РЕКРУТМЕНТ

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

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

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

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

ПРОДУКТ

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

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

МАРКЕТИНГ

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

PR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более семи лет я работаю в области продвижения технологий и 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!

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

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

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

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

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

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

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

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

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

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

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

Так, стандартный набор атрибутов бренда работодателя содержит:
📌зарплату и бонусы
📌возможности развития, образования и ростаусловия работы:
📌удобство офиса и его расположение, рабочий и бытовой комфорт
📌корпоративную культуру

Но для разработчиков не менее важны:
❇️самореализация
❇️интересные нетривиальные задачи
❇️актуальные современные технологии или хардкор
❇️технологическая репутация и влияние компании на it-индустрию
❇️уровень команды в целом и есть ли в компании «звезды».

Об этом часто не задумываются, не знают или не принимают в расчёт ответственные за бренд менеджеры.
Таким образом технологическая составляющая для бренда работодателя должна быть неотъемлемой частью EVP.

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

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

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

А необходимость создания чрезвычайно комфортных условий работы повергает менеджмент в ступор.
Конечно, не у всех есть возможность создать такую домашнюю обстановку как в Google или Яндексе. Не все могут позволить себе так заботиться о сотрудниках как it-гиганты. Но есть уже определенный must have минимум, который любая компания должна обеспечить, а дальше расширить своими уникальными плюшками. Так, недавно, от одного из гендиректоров услышала: «Мы только недавно поставили кофе машины. Пусть скажут спасибо. Но они же уже просят печеньки!». Бывает и такое 😂

Но приводя статистку, как влияет сильный employer brand на удержание, скорость и стоимость найма, получается постепенно менять парадигму мышления менеджмента.
Продолжение следует…

Наталия Макарова про технобренд и DevRel pinned «🔎Когда я провожу аудит employer brand и devrel, то часто вижу повторяющиеся ошибки. Речь идёт в первую очередь о тех компаниях, которые ещё вчера не относились к it-индустрии, а сегодня им необходимо перестраивать свой бизнес и нанимать большую команду разработчиков.…»

🔎Когда я провожу аудит employer brand и devrel, то часто вижу повторяющиеся ошибки.
Речь идёт в первую очередь о тех компаниях, которые ещё вчера не относились к it-индустрии, а сегодня им необходимо перестраивать свой бизнес и нанимать большую команду разработчиков.
⚒Имея порой сильнейший штат маркетологов и рекрутеров, выстроенные hr-процессы и эффективный внутренний employer бренд, такие компании вдруг сталкиваются со сложностью привлечения it-специалистов.
Так, например, менеджменту бывает сложно принять культуру it-people, а точнее такие её ценности как:
- свобода
- потребность влиять на бизнес
- комфорт

Cвобода предполагает необходимость не быть привязанным к рабочему месту 100% рабочего времени или иногда работать из дома (может быть условия карантина расширят понимание менеджментом, что это вполне выполнимо).
Это также относится и к желанию решать более сложные и творческие задачи, совместно и открыто с командой, выбирать решения, а не фиксить баги или тупо выполнять то, что прилетает в тикеты. Практически невозможным иногда оказывается внушить не техническому руководству, что C++ разработчику может понадобиться три дня мыслительного процесса, чтобы написать три строчки кода. То есть, разработчику необходима свобода для творчества, чтобы найти наилучшее креативное инженерное решение.
И я уже не говорю о том, как важно поощрять и поддерживать разработчиков в их желании делиться удачными решениями в формате open-source.
Продолжение следует…

❓Напоминаю, что вопросы можно задавать в связанном чате https://t.me/MyDevRelChat или в личку.