Наталия Макарова про технобренд и DevRel
الذهاب إلى القناة على Telegram
Канал про опыт в DevRel/Tech Marketing и Employer Brand for Tech Talents. В сфере DevRel с 2013 года. Ex Head of Devrel в SberDevices, DevRel-партнер GigaChat. ExYa. Пишу про свой опыт, сохраняю полезные ссылки, делюсь практиками. Слежу за трендами.
إظهار المزيد812
المشتركون
-124 ساعات
-17 أيام
-530 أيام
جارٍ تحميل البيانات
القنوات المماثلة
سحابة العلامات
لا توجد بيانات
هل تواجه مشاكل؟ يرجى تحديث الصفحة أو الاتصال بمدير الدعم الخاص بنا.
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
أكتوبر '26أكتوبر '26
أكتوبر '26
+13
في 0 قنوات
سبتمبر '260
في 0 قنوات
Get PRO
أغسطس '260
في 0 قنوات
Get PRO
يوليو '260
في 1 قنوات
Get PRO
يونيو '260
في 2 قنوات
Get PRO
مايو '260
في 0 قنوات
Get PRO
أبريل '260
في 0 قنوات
Get PRO
مارس '260
في 0 قنوات
Get PRO
فبراير '260
في 1 قنوات
Get PRO
يناير '260
في 2 قنوات
Get PRO
ديسمبر '250
في 2 قنوات
Get PRO
نوفمبر '250
في 1 قنوات
Get PRO
أكتوبر '250
في 1 قنوات
Get PRO
سبتمبر '250
في 2 قنوات
Get PRO
أغسطس '250
في 1 قنوات
Get PRO
يوليو '250
في 2 قنوات
Get PRO
يونيو '250
في 2 قنوات
Get PRO
مايو '250
في 0 قنوات
Get PRO
أبريل '250
في 0 قنوات
Get PRO
مارس '250
في 0 قنوات
Get PRO
فبراير '250
في 0 قنوات
Get PRO
يناير '250
في 0 قنوات
Get PRO
ديسمبر '24
+36
في 0 قنوات
Get PRO
نوفمبر '24
+20
في 0 قنوات
Get PRO
أكتوبر '24
+57
في 2 قنوات
Get PRO
سبتمبر '24
+32
في 0 قنوات
Get PRO
أغسطس '24
+97
في 0 قنوات
Get PRO
يوليو '240
في 0 قنوات
Get PRO
يونيو '240
في 1 قنوات
Get PRO
مايو '240
في 3 قنوات
Get PRO
أبريل '240
في 0 قنوات
Get PRO
مارس '240
في 0 قنوات
Get PRO
فبراير '240
في 0 قنوات
Get PRO
يناير '240
في 0 قنوات
Get PRO
ديسمبر '230
في 0 قنوات
Get PRO
نوفمبر '230
في 0 قنوات
Get PRO
أكتوبر '230
في 1 قنوات
Get PRO
سبتمبر '23
+4
في 0 قنوات
Get PRO
أغسطس '23
+27
في 0 قنوات
Get PRO
يوليو '23
+33
في 0 قنوات
Get PRO
يونيو '23
+11
في 0 قنوات
Get PRO
مايو '23
+23
في 0 قنوات
Get PRO
أبريل '23
+34
في 0 قنوات
Get PRO
مارس '23
+16
في 0 قنوات
Get PRO
فبراير '23
+12
في 0 قنوات
Get PRO
يناير '23
+6
في 0 قنوات
Get PRO
ديسمبر '22
+7
في 0 قنوات
Get PRO
نوفمبر '22
+10
في 0 قنوات
Get PRO
أكتوبر '22
+10
في 0 قنوات
Get PRO
سبتمبر '22
+21
في 0 قنوات
Get PRO
أغسطس '22
+2
في 0 قنوات
Get PRO
يوليو '22
+31
في 0 قنوات
Get PRO
يونيو '220
في 0 قنوات
Get PRO
مايو '220
في 0 قنوات
Get PRO
أبريل '22
+110
في 0 قنوات
Get PRO
مارس '220
في 0 قنوات
Get PRO
فبراير '220
في 0 قنوات
Get PRO
يناير '220
في 0 قنوات
Get PRO
ديسمبر '210
في 0 قنوات
Get PRO
نوفمبر '210
في 0 قنوات
Get PRO
أكتوبر '210
في 0 قنوات
Get PRO
سبتمبر '210
في 0 قنوات
Get PRO
أغسطس '210
في 0 قنوات
Get PRO
يوليو '210
في 0 قنوات
Get PRO
يونيو '21
+7
في 0 قنوات
Get PRO
مايو '21
+11
في 0 قنوات
Get PRO
أبريل '21
+9
في 0 قنوات
Get PRO
مارس '21
+311
في 0 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 28 أكتوبر | +1 | |||
| 27 أكتوبر | 0 | |||
| 26 أكتوبر | 0 | |||
| 25 أكتوبر | 0 | |||
| 24 أكتوبر | 0 | |||
| 23 أكتوبر | 0 | |||
| 22 أكتوبر | 0 | |||
| 21 أكتوبر | 0 | |||
| 20 أكتوبر | 0 | |||
| 19 أكتوبر | 0 | |||
| 18 أكتوبر | 0 | |||
| 17 أكتوبر | +1 | |||
| 16 أكتوبر | 0 | |||
| 15 أكتوبر | 0 | |||
| 14 أكتوبر | 0 | |||
| 13 أكتوبر | 0 | |||
| 12 أكتوبر | 0 | |||
| 11 أكتوبر | 0 | |||
| 10 أكتوبر | +2 | |||
| 09 أكتوبر | +1 |
منشورات القناة
Помню это всеобщее волнение, когда что-то происходило и какая-нибудь новость сотрясала наш Яндекс. С одной стороны, активность и работа будто замирали, а с другой — у всех словно включался особый режим: надо что-то делать, перестраивать процессы и проекты, чтобы помочь компании успешнее действовать в новых условиях. Мы все будто становились ещё сплочённее, вдруг начинали знакомиться с теми, с кем раньше не было точек пересечения, что словно обновляло картину мира.
У всех обострялось чувство причастности к чему-то грандиозному и важному.
И сейчас, в свете этих событий, у меня так же замирает сердце. Я желаю, чтобы эта великая компания ответила на вызов, преодолела и эти трудности и вышла из них ещё сильнее. И мы — вместе с ней.
| 2 |  Исследование DevRel-специалистов 2026
Женя Голева и DevCrowd запустили уже четвёртое исследование русскоязычного DevRel.
Буду ждать результатов, что изменилось в профессии.
🔸Чем стали заниматься DevRel-команды — где заканчивается DevRel и начинаются Tech PR, employer brand, community или developer marketing?
🔸Какие метрики действительно работают?
🔸Что происходит с ролями и зарплатами?
🔸 И, конечно, что AI уже потихоньку забирает себе из нашей работы :)
В исследовании на это есть отдельные блоки.
Если вы строите отношения компании с разработчиками — даже если в вашей должности вообще нет слова DevRel, — заполните.
Чем больше будет не только «классических» деврелов, но и людей, которые делают эту работу внутри других функций, тем интереснее получится картина профессии.
А, как мы знаем с вами, цифры очень убедительны, особенно для топов. В моей работе с C-level над DevRel и технологическим брендом это очень полезный материал, чтобы разговаривать не только с позиции опыта и наблюдений, но и с "цифровой" картинкой того, куда вообще движется профессия и чего от неё сегодня ждать.
👉 Пройти исследование DevRel 2026 | 282 |
| 3 |  Вышел новый обзор Open Source в России от ICT.Moscow.
Российские репозитории развиваются, Open Source используют всё больше, а 46% участников исследования считают, что главным драйвером роста открытых проектов станет ИИ.
Цифры там довольно оптимистичные. Верить хочется, но есть у меня и сомнения.
Казалось бы, почему бы российскому Open Source не вырасти в большую экосистему?
У Китая получилось. Причём не только создать собственные репозитории, но и вырастить вокруг них сообщества, проекты и международно заметные истории.
И... и как раз давайте про это и поговорим.
Пока у российского Open Source есть несколько системных проблем: разрозненные сообщества, недостаток сильных историй успеха, слабая культура совместной разработки и не очень понятная система притяжения контрибьюторов.
В исследовании это тоже видно.
Например, центров экспертизы на стыке индустрии, науки и Open Source ждут 35% участников.
А вот объединения разработчиков и контрибьюторов вокруг наиболее успешных проектов — только 10%.
Получается любопытный разрыв: инфраструктуру мы готовы развивать охотнее, чем сообщества вокруг неё.
А ведь именно сообщество превращает открытый код в экосистему.
Второе, что сейчас актуально — это вторжение ИИ.
С одной стороны, он может сильно снизить порог входа: помочь разобраться в чужом коде, подготовить документацию, найти баг, объяснить архитектуру, подготовить материалы для продвижения. То есть делает бот большую часть DevRel -работы
Но есть и обратная сторона.
Если ИИ резко увеличит количество автоматически сгенерированного кода, maintainer'ы получат не только больше контрибьюторов, но и больше работы по проверке всего этого потока. На Западе уже обсуждают проблему так называемого AI slop в Open Source.
И получается парадокс:
ИИ может сделать технический вход в Open Source проще, но не создаст культуру сотрудничества автоматически.
Человеческое «я пришёл в чужой проект, разобрался, поговорил с автором, предложил изменение, получил обратную связь и стал частью сообщества» никуда не исчезает.
И в этом исследовании не идёт речь ещё об одной частой проблеме, когда компания для пиара опубликовать проект в open source готова, а нормально его поддерживать, развивать и продвигать нет. Или инди-раработчик на энтузиазме сначала тащит, а ресурсов вдолгую не хватает. Вот и сиди-гадай, что будет со всеми этими инициативами )) | 222 |
| 4 | Почему тебе надо в техпиар, а не в DevRel...
На днях увидела вакансию VK: компания ищет старшего специалиста в службу техпиара.
И здесь как раз хорошо видна разница между стартапом, небольшой компанией и большой технологической корпорацией.
В предыдущем посте я писала, что в небольшой компании техбренд должен в идеале начинаться "с головы" и быть основой культуры, исходя от CTO, разработчиков, публичных технических экспертов, продукта и того, как компания вообще разговаривает с рынком.
Но чем крупнее компания — тем сложнее эта конструкция.
Особенно если компания изначально технологическая или активно держит путь на трансформацию.
Нужно показать очень широкой аудитории:
🔸 какие технологии ваша компания создаёт;
🔸 что в них действительно нового, в чем прорыв;
🔸 почему вашим решениям можно доверять;
🔸 что умеют ваши рпзработчики!
🔸и главное — почему всё это должно быть интересно человеку, который вообще не разбирается в технологиях?
И эта вакансия очень хорошо демонстрирует этот фокус.
Потому что там нужен именно пиарщик, которому интересно не просто рассказывать о технологиях, а делать так, чтобы технологии трогали сердца и завоёвывали лояльность обычного пользователя.
При этом, конечно, нужно быть очень близко к разработчикам, техлидам, CTO — доставать из них технологическую суть продукта, понимать, что в ней действительно важно, а потом переводить это на язык разных аудиторий.
Но это всё-таки не DevRel.
И, кстати, ко мне довольно часто приходили пиарщики и спрашивали:
— А может, мне пойти в DevRel? Кажется, DevRel сейчас востребованнее обычного PR.
А я обычно отвечала:
— Нет. Тебе не надо в DevRel.
Тебе надо в техпиар.
Потому что ты привык возводить сложную сущность в категории, понятные всем и каждому, работать с репутацией, искать сильную историю, находить правильный язык для разных аудиторий, делать сложное интересным и выстраивать доверие к бренду. И тебе может быть неуютно в достаточно специфичном профессиональном техническом сленге. То есть я не хочу сказать, что DevRel это только узкие профессиональные темы, там тоже иногда нужны красивые вдохновляющие истории, но все же уклон в первое больше.
Т.о. CTO и разработчики дают технологическую экспертизу.
DevRel выстраивает отношения с профессиональным сообществом.
А техпиарщик помогает сделать так, чтобы технологическая сила компании стала понятной, заметной и эмоционально значимой для гораздо более широкой аудитории. | 268 |
| 5 |  DevRel и два CTO: разговор, который начался с одного простого вопроса 💬
Не так давно делала презентацию про DevRel — для CEO и CTO нескольких стартапов. Стояла и ловила себя на мысли, что объясняю, что вода мокрая. 💧 А потом вспомнила этот разговор и поняла — да, мокрая, но напоминать полезно. Записала почти дословно.
CTO №1: У нас честно — никто ничего не постит. Не потому что запрещено, просто у людей нет времени, а у меня тем более.
Я: А если бы время появилось — кто-то стал бы?
CTO №1: Не уверен. Скорее всего испугались бы. У нас команда не публичная вообще, все привыкли молчать и кодить.
CTO №2: У нас похожая история. Я вот думал нанять DevRel-человека, чтобы он это разрулил. Пусть выступает, пишет, представляет нас.
Я: А что бы он рассказывал?
CTO №2: Ну... про продукт. Про стек. Что мы вообще есть.
Я: А он у вас в коде разбирается, в архитектурных решениях?
CTO №2: Нет, это же не его работа.
Я: Вот тут обычно и начинается проблема. Если нанять человека со стороны, который не варился в вашей инженерной кухне — он максимум сделает красивую упаковку. А разработчики на рынке такое считывают моментально. Это не DevRel, это пиар с техническими словами.
CTO №1: Так а что тогда, мне самому этим заниматься? У меня продакшн, найм, роадмап — это уже перебор. 😵💫
Я: Не заниматься одному. Но без тебя — никак не начнётся. Культура идёт сверху. Если ты сам ни разу не рассказал, как вы решали какую-то задачу, не показал, что это нормально — команда тем более не начнёт, а уж тем более не начнёт наёмный человек со стороны, которому вы поручили "быть голосом компании". 🗣️
CTO №2: Но я правда не умею и не люблю писать посты. Это не моё.
Я: Речь не про то, чтобы ты вёл блог. Речь про то, чтобы твоя инженерная экспертиза и твоя позиция были видны — хотя бы иногда. Пост, комментарий на конфе, тред в чате с командой, где ты объясняешь, почему приняли то или иное решение. Люди в команде это видят и считывают: ага, оказывается, можно.
CTO №1: А если я скажу что-то не так и это выйдет боком?
Я: Вот это и есть настоящий вопрос, а не "нужен ли нам DevRel". Страх обычно живёт именно здесь — не в отсутствии времени, а в том, что непонятно, где граница и что будет, если ошибёшься.
CTO №1: Честно — да. Проще молчать, чем потом разгребать.
Я: И это нормальная реакция, если никто в компании явно не сказал: вот что можно говорить, вот где граница, и если ошибся — это не катастрофа. Без этого разговора команда будет молчать сколько угодно, наймите вы хоть трёх DevRel-менеджеров.
CTO №2: Хорошо, а сам DevRel-человек тогда вообще зачем, если начинать надо не с него?
Я: Затем что построить всё в одиночку, без выделенного человека, тоже почти невозможно — у тебя нет на это времени, у команды нет привычки, и это должно быть чьей-то явной задачей: организовать, подготовить, довести до системы. Просто этот человек должен опираться на то, что уже задаёте вы — идеологию, позицию, готовность делиться. А не придумывать её за вас с нуля.
CTO №1: То есть сначала мы, потом он.
Я: Или вместе, но точно не вместо. Если нанять человека и полностью отойти в сторону — считай, вы наняли пресс-службу. А если начать хотя бы с малого — сам рассказал, сам поддержал того, кто рискнул выступить, — DevRel-человек потом это масштабирует. Но фундамент — КУЛЬТУРА — это всегда изнутри и сверху, не снаружи.
CTO №2: У нас, получается, ещё даже фундамента нет.
Я: У вас есть инженеры, которые молчат не потому что нечего сказать, а потому что непонятно, можно ли. Это уже отправная точка. Дальше вопрос, кто первый скажет "можно" — и покажет это не словами, а собственным примером. | 294 |
| 6 |  Насколько заранее вы начинаете готовиться к участию во внешних конференциях, а ваши спикеры — подавать заявки на доклады?
Например, сейчас июль, а CFP на осенние конференции JUG Ru Group, а также других популярных у разработчиков технологических конференций, уже закрыт. Но эта тема актуальна всегда: уже сейчас пора начинать готовиться к весеннему сезону.
Верю, что вы стараетесь всё делать как можно раньше, но на деле разработчики часто тянут до последнего. Причин много: занят, времени до дедлайна CFP ещё полно, мы ещё не выкатили фичу, о которой хотим рассказать, и так далее. А когда спикер вдруг созрел, слотов в программе не остаётся даже для классной темы. Вас ставят в резерв, который в итоге не срабатывает.
Уверена, если вы опытный деврел, то вы:
- Держите руку на пульсе и настраиваете разработчиков на конференции за 7-10 месяцев.
- Помните: чем раньше подан доклад, тем больше шансов попасть в программу, потому что организаторы сами заинтересованы поскорее наполнить сетку интересными темами и начать промо.
- Знаете, кто из ПК ответственен за нужные вам стримы. Заранее ищете возможность познакомиться и посоветоваться: как лучше «упаковать» вашу экспертизу и повернуть тему, чтобы она зашла и организаторам, и участникам.
- Выстроили процесс внутри компании и «продали» разработчикам идею, почему им (и бизнесу) важно участвовать в конференциях.
- Заранее знаете о сильных технических и продуктовых релизах (закладываете их в свой план) и чётко понимаете, с какой темой на какую конференцию идти.
Есть и другие лайфхаки, но эти считаю базой. Поделитесь своими в комментариях, если открыли для себя что-то новое!
А вот что касается партнёрства и спонсорства — здесь шевелиться надо ещё раньше. Но об этом поговорим в следующий раз, если вам интересно. | 368 |
| 7 | И, кстати, кто не знаком с замечательной Аней Крюковой и хочет ещё поспрашивать про мероприятия в Европе, добавляйтесь к ней в линкедин, Аня разрешила 😘
Аня живёт сейчас в Барселоне и поднимала DevRel и Employer Brand с нуля в Manychat.
https://www.linkedin.com/in/meowsphere | 300 |
| 8 |  +1Как одеть стендистов, чтобы их везде было видно)) | 288 |
| 9 |  +5لا يوجد نص... | 268 |
| 10 |  +9لا يوجد نص... | 261 |
| 11 |  لا يوجد نص... | 231 |
| 12 |  لا يوجد نص... | 223 |
| 13 |  لا يوجد نص... | 229 |
| 14 | В закрытом чате коллега прислала отзыв о том, как побывала на WeAreDevelopers World Congress -- крупнейшей конференции в Европе.
Не могу этим не поделиться с вами (с разрешения, Анны, конечно!) | 229 |
| 15 |  В продолжение предыдущего поста...
Инфографика для тех, кому покороче...
Итак, не отлавливаем низкочастотные ответы, а планируем пользу заранее и после проверяем результат
У разработчика появляется понятная цель. У нас — понимание, какой результат мы вообще считаем успешным и как можно на него повлиять.
И наряду с цифрами на нашей стороне и смыслы и польза для разработчиков и производства.
И, если честно, именно такие истории спустя время я вспоминаю чаще всего. Вот, собственно поэтому про это и пишу)) 😊 | 375 |
| 16 | «На конференции я нашел решение проблемы, над которой наша команда билась несколько недель»
Считаю, что одна из самых недооцененных метрик в DevRel — это реальная польза конференции для конкретного разработчика.
Когда после мероприятия деврелы от компаний или организаторы конференций собирают с участников обратную связь, то это или CSI, или NPS, где большинство ответов обычно достаточно стандартные: насколько понравилась организация, были ли интересные доклады, хороша ли площадка и пр.
Когда мы обсуждаем участие в конференциях, разговор как правило сводится к тому, сколько людей увидели бренд, сколько человек подошли к стенду, сколько упоминаний получили в соцсетях или какой охват собрали.
Все это важно. Но иногда за этими цифрами теряется главный вопрос: а что получил сам разработчик?
Ведь конференция — это и знания из докладов, и место, где люди находят ответы на задачи, с которыми не могли разобраться месяцами. Где получают совет от эксперта, который уже проходил через похожие проблемы. Где через случайный разговор в кулуарах или обсуждение после доклада находят решение, которое потом экономит недели работы команды.
Такие истории происходят не каждую минуту. Они редко становятся красивой статистикой в итоговом отчете. Но именно они зачастую создают наибольшую ценность.
И вот, иногда встречается ответ вроде: «На конференции я нашел решение проблемы, над которой наша команда билась несколько недель».
И, если честно, для меня такой отзыв может весить больше десятков других.
Потому что один разработчик, который решил действительно важную рабочую задачу благодаря участию в конференции, — это уже очень серьезный результат. В некоторых случаях ценность такого кейса вполне может соперничать с существенной частью инвестиций компании в мероприятие.
Поэтому мне кажется, что DevRel стоит чаще смотреть на конференции глазами участников, а не только глазами бренда.
Узнаваемость важна. Охваты важны. Но если благодаря мероприятию разработчики становятся эффективнее,
быстрее решают свои задачи и получают доступ к опыту, который сложно получить где-либо еще, — это одна из самых сильных ценностей, которую мы можем создавать. | 367 |
| 17 | То, о чем и правда стоит задуматься про IT-конференции в России 17 минут.
К некоторым деталям и мнению у меня есть вопросы, но по сути видео очень стоит того, чтобы посмотреть.
И над озвученными проблемами очень полезно поразмыслить:
— качество
— польза для разработчиков
— стоимость и кто за что платит
— как будем жить дальше?)).
В целом на междусобойчиках деврелы и так это обсуждают, а вот вам кто-то взял и схайпил.
Готовы об этом поговорить? | 904 |
| 18 |  💪 Разработчики, подвиньтесь!
Крупнейшие технологические компании нанимают людей, которые пишут тексты, и платят им как опытным айтишникам. Пересказываем материал Business Insider про новый HR-тренд.
В 2026-м одни из самых востребованных позиций в бигтехе связаны не технологиями, а с творческими задачами. Компании ищут опытных авторов, редакторов и коммуникационных стратегов, способных мыслить творчески. Например, Anthropic уже увеличил численность коммуникационной команды на 200% и продолжает искать сотрудников на зарплату $200 000. А в OpenAI таким экспертам готовы платить более $400 000 — на уровне технических специалистов. То же самое происходит в Microsoft, Adobe, Netflix и других компаниях (не только технологических). За последние два года в LinkedIn в два раза увеличилось количество вакансий, требующих навыков сторителлинга.
Всё дело в том, что корпоративные каналы заполнил генеративный контент, и на этом фоне резко выросла ценность человеческой креативности. Люди могут создавать узнаваемый голос бренда, укреплять репутацию компании, выстраивать нарратив и завоевывать доверие аудитории. Другими словами, технологии, которые должны были автоматизировать создание контента, наоборот, повысили ценность человека в этой сфере.
Подписывайтесь 👉 @techno_yandex | 805 |
| 19 | Как бальзам на душу 👼 | 516 |
| 20 | Но не 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.
Общее у всех этих форматов одно: компания снижает порог входа, помогает разработчику быстрее что-то сделать своими руками, познакомится, «примерить на себя».
🔼Короче, надо делиться по-настоящему, 🔽а не делать вид 🤷♀️ | 596 |
