MyDevRelChat

Насколько заранее вы начинаете готовиться к участию во внешних конференциях, а ваши спикеры — подавать заявки на доклады? Например, сейчас июль, а CFP на осенние конференции JUG Ru Group, а также других популярных у разработчиков технологических конференций, уже закрыт. Но эта тема актуальна всегда: уже сейчас пора начинать готовиться к весеннему сезону. Верю, что вы стараетесь всё делать как можно раньше, но на деле разработчики часто тянут до последнего. Причин много: занят, времени до дедлайна CFP ещё полно, мы ещё не выкатили фичу, о которой хотим рассказать, и так далее. А когда спикер вдруг созрел, слотов в программе не остаётся даже для классной темы. Вас ставят в резерв, который в итоге не срабатывает. Уверена, если вы опытный деврел, то вы: - Держите руку на пульсе и настраиваете разработчиков на конференции за 7-10 месяцев. - Помните: чем раньше подан доклад, тем больше шансов попасть в программу, потому что организаторы сами заинтересованы поскорее наполнить сетку интересными темами и начать промо. - Знаете, кто из ПК ответственен за нужные вам стримы. Заранее ищете возможность познакомиться и посоветоваться: как лучше «упаковать» вашу экспертизу и повернуть тему, чтобы она зашла и организаторам, и участникам. - Выстроили процесс внутри компании и «продали» разработчикам идею, почему им (и бизнесу) важно участвовать в конференциях. - Заранее знаете о сильных технических и продуктовых релизах (закладываете их в свой план) и чётко понимаете, с какой темой на какую конференцию идти. Есть и другие лайфхаки, но эти считаю базой. Поделитесь своими в комментариях, если открыли для себя что-то новое! А вот что касается партнёрства и спонсорства — здесь шевелиться надо ещё раньше. Но об этом поговорим в следующий раз, если вам интересно.

🔔4 DevRel- лайфхака, как выжать максимум из IT-конференций В одном из недавних постов я рассказала, о чем спросить разработчиков перед поездкой на конференцию. А сегодня давайте на примере грядущей конфы SmartData от JUG.Ru Group разберем, как CTO, тимлидам и DevRel-ам «дожать» реальную пользу из участия команды. Лайфхак 1. Точечный опрос до оплаты билетов Скиньте программу активным инженерам (ML, Data, Highload) и спросите: - Что из этого бьется с нашими текущими задачами? - На какие доклады больше всего хочешь сходить? - Расскажешь о том, что узнал, команде после возвращения? Лайфхак 2. Запрашивайте у участников максимально подробный фидбек после конфы Фидбек в стиле «было круто» мы принимаем, но не останавливаемся и копаем глубже. Что именно участник привез с конфы? Возможно, это будет хардовая конкретика: «понял, как ускорить запросы в ClickHouse» или «узнал, как перейти от sensors к Datasets в Airflow»». А возможно, инженер по итогу конфы по-настоящему задался важным вопросом «Где и как я могу стать лучше?» , а после общения с коллегами у него появилось много новых идей и заряд мотивации для этого. Главное — узнать, что значимого человек унес для себя и чем он потом будет готов поделиться с командой. Это может быть даже инсайт, что у вас похожую задачу получилось решить лучше, что тоже здорово порадует и замотивирует коллег. Лайфхак 3. Отправляйте несколько человек от команды Сетка докладов профильных ивентов всегда плотная. Одновременно в расписании может стоять несколько полезных докладов. В результате один человек просто физически не сможет прослушать всё интересное. Конечно, на той же Smardata и других IT-конференциях предусмотрена возможность посмотреть доклады в записи, но при личном присутствии у человека еще и получается задать уточняющие вопросы спикеру. Поэтому лучше отправляйте минимум двоих-троих сотрудников: они разделятся по хардовым трекам, соберут кратно больше решений, да и корпоративный мерч выгуливать веселее. Лайфхак 4. Настройте

DevRel и два CTO: разговор, который начался с одного простого вопроса 💬 Не так давно делала презентацию про DevRel — для CEO и CTO нескольких стартапов. Стояла и ловила себя на мысли, что объясняю, что вода мокрая. 💧 А потом вспомнила этот разговор и поняла — да, мокрая, но напоминать полезно. Записала почти дословно. CTO №1: У нас честно — никто ничего не постит. Не потому что запрещено, просто у людей нет времени, а у меня тем более. Я: А если бы время появилось — кто-то стал бы? CTO №1: Не уверен. Скорее всего испугались бы. У нас команда не публичная вообще, все привыкли молчать и кодить. CTO №2: У нас похожая история. Я вот думал нанять DevRel-человека, чтобы он это разрулил. Пусть выступает, пишет, представляет нас. Я: А что бы он рассказывал? CTO №2: Ну... про продукт. Про стек. Что мы вообще есть. Я: А он у вас в коде разбирается, в архитектурных решениях? CTO №2: Нет, это же не его работа. Я: Вот тут обычно и начинается проблема. Если нанять человека со стороны, который не варился в вашей инженерной кухне — он максимум сделает красивую упаковку. А разработчики на рынке такое считывают моментально. Это не DevRel, это пиар с техническими словами. CTO №1: Так а что тогда, мне самому этим заниматься? У меня продакшн, найм, роадмап — это уже перебор. 😵‍💫 Я: Не заниматься одному. Но без тебя — никак не начнётся. Культура идёт сверху. Если ты сам ни разу не рассказал, как вы решали какую-то задачу, не показал, что это нормально — команда тем более не начнёт, а уж тем более не начнёт наёмный человек со стороны, которому вы поручили "быть голосом компании". 🗣️ CTO №2: Но я правда не умею и не люблю писать посты. Это не моё. Я: Речь не про то, чтобы ты вёл блог. Речь про то, чтобы твоя инженерная экспертиза и твоя позиция были видны — хотя бы иногда. Пост, комментарий на конфе, тред в чате с командой, где ты объясняешь, почему приняли то или иное решение. Люди в команде это видят и считывают: ага, оказывается, можно. CTO №1: А если я скажу что-т

Вышел новый обзор Open Source в России от ICT.Moscow. Российские репозитории развиваются, Open Source используют всё больше, а 46% участников исследования считают, что главным драйвером роста открытых проектов станет ИИ. Цифры там довольно оптимистичные. Верить хочется, но есть у меня и сомнения. Казалось бы, почему бы российскому Open Source не вырасти в большую экосистему? У Китая получилось. Причём не только создать собственные репозитории, но и вырастить вокруг них сообщества, проекты и международно заметные истории. И... и как раз давайте про это и поговорим. Пока у российского Open Source есть несколько системных проблем: разрозненные сообщества, недостаток сильных историй успеха, слабая культура совместной разработки и не очень понятная система притяжения контрибьюторов. В исследовании это тоже видно. Например, центров экспертизы на стыке индустрии, науки и Open Source ждут 35% участников. А вот объединения разработчиков и контрибьюторов вокруг наиболее успешных проектов — только 10%. Получается любопытный разрыв: инфраструктуру мы готовы развивать охотнее, чем сообщества вокруг неё. А ведь именно сообщество превращает открытый код в экосистему. Второе, что сейчас актуально — это вторжение ИИ. С одной стороны, он может сильно снизить порог входа: помочь разобраться в чужом коде, подготовить документацию, найти баг, объяснить архитектуру, подготовить материалы для продвижения. То есть делает бот большую часть DevRel -работы Но есть и обратная сторона. Если ИИ резко увеличит количество автоматически сгенерированного кода, maintainer'ы получат не только больше контрибьюторов, но и больше работы по проверке всего этого потока. На Западе уже обсуждают проблему так называемого AI slop в Open Source. И получается парадокс: ИИ может сделать технический вход в Open Source проще, но не создаст культуру сотрудничества автоматически. Человеческое «я пришёл в чужой проект, разобрался, поговорил с автором, предложил изменение, получил обратную связь и стал частью сооб

Исследование DevRel-специалистов 2026 Женя Голева и DevCrowd запустили уже четвёртое исследование русскоязычного DevRel. Буду ждать результатов, что изменилось в профессии. 🔸Чем стали заниматься DevRel-команды — где заканчивается DevRel и начинаются Tech PR, employer brand, community или developer marketing? 🔸Какие метрики действительно работают? 🔸Что происходит с ролями и зарплатами? 🔸 И, конечно, что AI уже потихоньку забирает себе из нашей работы :) В исследовании на это есть отдельные блоки. Если вы строите отношения компании с разработчиками — даже если в вашей должности вообще нет слова DevRel, — заполните. Чем больше будет не только «классических» деврелов, но и людей, которые делают эту работу внутри других функций, тем интереснее получится картина профессии. А, как мы знаем с вами, цифры очень убедительны, особенно для топов. В моей работе с C-level над DevRel и технологическим брендом это очень полезный материал, чтобы разговаривать не только с позиции опыта и наблюдений, но и с "цифровой" картинкой того, куда вообще движется профессия и чего от неё сегодня ждать. 👉 Пройти исследование DevRel 2026