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

Исследование DevRel-специалистов 2026

Женя Голева и DevCrowd запустили уже четвёртое исследование русскоязычного DevRel.
Буду ждать результатов, что изменилось в профессии.

🔸Чем стали заниматься DevRel-команды — где заканчивается DevRel и начинаются Tech PR, employer brand, community или developer marketing?
🔸Какие метрики действительно работают?
🔸Что происходит с ролями и зарплатами?

🔸 И, конечно, что AI уже потихоньку забирает себе из нашей работы :)

В исследовании на это есть отдельные блоки.
Если вы строите отношения компании с разработчиками — даже если в вашей должности вообще нет слова DevRel, — заполните.

Чем больше будет не только «классических» деврелов, но и людей, которые делают эту работу внутри других функций, тем интереснее получится картина профессии.

А, как мы знаем с вами, цифры очень убедительны, особенно для топов. В моей работе с C-level над DevRel и технологическим брендом это очень полезный материал, чтобы разговаривать не только с позиции опыта и наблюдений, но и с "цифровой" картинкой того, куда вообще движется профессия и чего от неё сегодня ждать.

👉 Пройти исследование DevRel 2026

Вышел новый обзор 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 готова, а нормально его поддерживать, развивать и продвигать нет. Или инди-раработчик на энтузиазме сначала тащит, а ресурсов вдолгую не хватает. Вот и сиди-гадай, что будет со всеми этими инициативами ))

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: У нас, получается, ещё даже фундамента нет.
Я: У вас есть инженеры, которые молчат не потому что нечего сказать, а потому что непонятно, можно ли. Это уже отправная точка. Дальше вопрос, кто первый скажет "можно" — и покажет это не словами, а собственным примером.

Насколько заранее вы начинаете готовиться к участию во внешних конференциях, а ваши спикеры — подавать заявки на доклады?

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

Верю, что вы стараетесь всё делать как можно раньше, но на деле разработчики часто тянут до последнего. Причин много: занят, времени до дедлайна CFP ещё полно, мы ещё не выкатили фичу, о которой хотим рассказать, и так далее. А когда спикер вдруг созрел, слотов в программе не остаётся даже для классной темы. Вас ставят в резерв, который в итоге не срабатывает.

Уверена, если вы опытный деврел, то вы:

- Держите руку на пульсе и настраиваете разработчиков на конференции за 7-10 месяцев.

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

- Знаете, кто из ПК ответственен за нужные вам стримы. Заранее ищете возможность познакомиться и посоветоваться: как лучше «упаковать» вашу экспертизу и повернуть тему, чтобы она зашла и организаторам, и участникам.

- Выстроили процесс внутри компании и «продали» разработчикам идею, почему им (и бизнесу) важно участвовать в конференциях.

- Заранее знаете о сильных технических и продуктовых релизах (закладываете их в свой план) и чётко понимаете, с какой темой на какую конференцию идти.

Есть и другие лайфхаки, но эти считаю базой. Поделитесь своими в комментариях, если открыли для себя что-то новое!

А вот что касается партнёрства и спонсорства — здесь шевелиться надо ещё раньше. Но об этом поговорим в следующий раз, если вам интересно.

В продолжение предыдущего поста...
Инфографика для тех, кому покороче...

Итак, не отлавливаем низкочастотные ответы, а планируем пользу заранее и после проверяем результат
У разработчика появляется понятная цель. У нас — понимание, какой результат мы вообще считаем успешным и как можно на него повлиять.
И наряду с цифрами на нашей стороне и смыслы и польза для разработчиков и производства.
И, если честно, именно такие истории спустя время я вспоминаю чаще всего. Вот, собственно поэтому про это и пишу)) 😊