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

👉 Ключевое здесь то, что Telegram с самого старта сделал ставку на разработчиков, даже если формальной DevRel-стратегии у них и не было. Но когда продукт создают инженеры, часто решения получаются нативными для инженеров сами собой.

❓Почему именно разработчики и IT специалисты стали первыми ранними последователям?

👉 Репутация создателей

Если безусловным лидером Телеграм является Павел Дуров, то его брат Николай не менее известен и уважаем именно в техническом сообществе. Именно его имя и репутация в области разработки сразу стали основой для доверия и интересу к продукту.

👉 Уникальная технология

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


👉 Акцент на безопасности и в нужный момент

Продукт вышел на рубеже 2013-2014 гг., когда вопрос информационной безопасности и конфиденциальности переписки хайповал. Телеграм попал в волну. Пока остальные думали, зачем нам еще один мессенджер, есть же Skype, Slack, FB мессенджер, Gitter и пр., разработчики побежали тестировать именно Телеграм -- там и остались. Почему? Потому что: это не просто “мы про безопасность”, а безопасность как инженерная задача и философия команды. И это очень резонирует с духом технической аудитории.

Безусловно, все это подогревалось деталями ухода Павла Дурова из ВКонтакте, но это детали скорее истории про TechPR, а не DevRel.

👉 Специальные проекты и конкурсы с большим призовым фондом

Отдельно хочется уделить внимание теме конкурсов, грантов, открытым задачам от Telegram, адресованным разработчикам и дизайнерам.

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

Существуют отдельные каналы https://news.1rj.ru/str/contest_ru и https://news.1rj.ru/str/contest, где несколько раз в год публикуются челенджи, задачи и конкурсы для разработчиков на создание, разработку чего-либо. Например, серьезных ML-задач, продуктовых фич, визуализации графиков, анимирования аватаров и пр.
Ну и это еще и шанс попасть в команду Телеграм.


👉 TechPR и имидж Павла

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

Но мы здесь про DevRel. И Telegram никогда не пытался быть “милым” или “корпоративным”. Он честно инженерный, немножко бунтарский и с чёткой философией продукта.

Если первые пункты-принципы опытные DevRel-специалисты вполне понимают и используют, то вот потенциал программ для разработчиков в России используется очень редко. Бигтех проводит олимпиады для молодых специалистов, чтобы присмотреть и "прикормить" самых талантливых в надежде потом нанять. А вот искать идеи "на стороне" или платить за прототипы пока мало кто готов. Это и правда риск, но вот кому-то удается )


🧑‍💻 Добавляйте, если знаете еще секреты или инсайды )

Если хотите разбор DevRel-успеха какой-то компании (может быть даже вашей в порядке аудита, пишите в комментарии или в личку).

👍🔥❤️

Привет!
Начинаю год с объявления, что переименовываю свой канал и теперь он очевидно авторский. То есть он всегда был таким, но теперь становится именным, как того диктует тренд )
«Наталия Макарова про технобренд и DevRel».

Чтобы было ещё интереснее, задавайте вопросы. Они — навигация, которая помогает мне лучше понимать ваши потребности, что наиболее полезно и актуально именно вам. 💎

Спасибо, что остаётесь со мной!
😍

Как обещала, немного о стратегии KodaCode. Много не могу, все-таки NDA )

🔤🔤🔤🔤🔤🔤🔤 DevRel — это не только сцена, митапы и CFP.

И здесь очень важно понимать, что это стартап с определенными условиями и ограничениями.

* стартапу важно не распыляться
* бюджет минимален
* команде некогда готовить доклады «на сезон».

➡️ DevRel-стратегия — Bottom-up.
Как было выше сказано, бизнес-модель — B2B и B2D2B, это значит, что нам важно заручиться признанием основных пользователей — разработчиков, кто будет хотеть инструмент в работе, будет его рекомендовать работодателям и заказчикам.

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

📣 Каналы и ресурсы

🔸 Хабр — must have. Для стартапов без монетизации аккаунт бесплатный.
Бюджет: 0 ₽
🔸 YouTube (видео, рилсы, How to, гайды и пр.): собственные каналы и техноблогеры — своими силами, С техноблогеми дружим, захватываем идеей и/или договариваемся с микроблогерами с самыми недорогими, но реальными (теми, кто взаправду про технологии, а не канал ради рекламных заказов). VK, RuTube - чисто ради интереса и эксперимента, но ожидаемо, что там ЦА почти нет.
🔸 Telegram канал и чат — апдейты, запуски, мысли про индустрию? общение участников и поддержка
🔸 Щупаем другие медиа для разработчиков, а также СМИ для официальных анонсов.
🔸 К FAQ и документации пристальное внимание

Лояльные пользователи из сообщества — ценный актив

🔹 Отдельный чатик по тестированию для самых лояльных, проверке гипотез — за идею, доступ к новым фичам, дополнительным бесплатным лимитам, признание, благодарность.
🔹 Не дают расслабляться: приносят баги, вопросы, просьбы новых фичей и релизов.
🔹 Рассказывают в разных форматах и делятся в других сообществах впечатлениями об использовании KodaCode


Итак, DevRel — это не только сцена, митапы и CFP.
А есть ли здесь что-то уникальное. Пожалуй, нет. Но это тот самый пример выбора стратегии и инструментов, исходя из ситуации и ресурсов.
DevRel может быть системным, экономным и очень прикладным. И даже если вы работаете с Tech HR-брендом, очень полезно понимать принципы продуктового DevRel, который максимально приближен к потребностям разработчиков.

➡️ Есть в DevRel такое понятие — Developer Success.

В широком смысле это про то, насколько комфортно, понятно разработчику работать с системой: продуктом, компанией, сообществом или технологией. Это не только про документацию, SDK или инструменты. Это про путь разработчика от первого контакта до момента, когда он может с уверенностью сказать: «я сделал это!».

В контексте построения репутации компании как классного работодателя для технарей Developer Success выходит за рамки продукта и DevRel. Разработчикам важно не только сколько им платят, но и как к ним относятся. Признаётся ли их вклад? Видят ли его влияние? Есть ли пространство для роста и публичного признания достижений?

Компании, которые умеют ценить вклад разработчиков не только через зарплату, но и через уважение, доверие и признание, формируют сильный employer brand. Что уж там, не только разработчики, большинство людей хотят быть там, где им дают почувствовать: «мой вклад здесь важен» и где можно сказать с гордостью: «я сделал это — вместе с этой командой».
➡️

😊 Для меня в DevRel ключевыми принципами являются ⚖️взаимовыгодная коммуникация с разработчиками и доверие. Это когда компания дает рынку и целевой аудитории реальную пользу в виде экспертизы, полезных материалов, обучения, а также делится с IT-сообществом своими технологиями. Самый знакомый формат — open-source. Это очень ценится, что компания, вложив много денег в какую-то разработку или технологию, условно безвозмездно отдает ее на благо развития технологий в целом. Это круто укрепляет ее репутацию и повышает лояльность разработчиков.

💬⁉️ Разработчики любят экспериментировать и учиться на практике. Чтобы сократить их путь к вам, дайте им возможность быстро и легко «пощупать» то, что есть у вас интересного. Если говорим про продуктовый деврел, то чтобы начать работу с вашим продуктом, важно предоставить им простые и понятные инструкции. Это может быть «С чего начать» или «Пошаговая инструкция», которые помогут им быстро увидеть результаты.
Если говорим про Employer Brand, то здесь мы используем непосредственное знакомство с командой, задачами, в формате челленджей или в игровом формате даем возможность примериться друг к другу. Чем быстрее они начнут, тем больше у них будет мотивации двигаться дальше: использовать ваши решения, идти к вам на работу или рекомендовать другим.

📈Быстрый первый результат рождает интерес, второй его усиливает, третий вызывает доверие, а доверие — это и есть основа сильного DevRel.

Но не open-source единым или как ещё компания может делиться технологиями и экспертизой!

Продолжая мысль предыдущего поста.
Разработчики уважают компании не только за open source. Намного шире — за готовность делиться тем, что реально имеет ценность.
Это может быть:
🔹 открытые API, SDK, CLI и инструменты с бесплатным доступом
🔸 инженерная документация, туториалы, hands-on лаборатории
🔹 бесплатный доступ к инфраструктуре и средам, где разработчик может экспериментировать без риска и затрат.
🔸 Sandbox-окружения, demo-стенды, playground’ы
🔹 Free tier на облачные сервисы или продукты
🔸 Open datasets и тестовые данные
🔹архитектурные разборы, публичные технические кейсы (как мы это сделали, что пробовали, что получилось, что нет и почему…)
🔸 внутренние библиотеки, фреймворки, шаблоны и best practices
🔹 живое общение с инженерами: AMA, office hours, сообщества
🔸 митапы, хакатоны, доклады инженеров без рекламы и продажи
🔹 участие в рабочих группах, вклад в стандарты, в свои и/или общие экосистемы (примеры: РГ 21C++, вклад в развитие сообществ в регионах, Kubernetes)
🔸 участие в программных комитетах конференций
🔹 контрибьют в чужие важные open-source проекты
🔸 менторство, открытые или персональные code review.

Общее у всех этих форматов одно: компания снижает порог входа, помогает разработчику быстрее что-то сделать своими руками, познакомится, «примерить на себя».

🔼Короче, надо делиться по-настоящему, 🔽а не делать вид 🤷‍♀️