Хинт для написания статьей

Статья – не самый скоростной формат деврел-артефакта. В отличие от какого-нибудь выступления с докладом, для статьи обычно нет дедлайна; внешние обстоятельства не подталкивают ускориться и успеть к фиксированной дате.

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

Но формат-то стоящий! Статьи умеют собирать хороший трафик в длинном хвосте; могут быть прилично discoverable ещё долго после публикации, несколько лет. Часть людей из сообщества предпочитает читать статьи сильно больше, чем смотреть доклады; если не писать – уменьшаются шансы пообщаться с ними, дотянуться своим контентом.

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

Поэтому установка: не хотим отказываться от статей в пользу разговорных форматов, хотим иметь под рукой хинты для упрощения работы над текстами.

Один из таких хинтов – статья через разговор.

Приём работает так:
- автор ввязывается в разговор по теме с другим человеком, разговор записывается;
- запись разговора расшифровывается, получается черновик;
- в черновике наводится красота (своими руками или с помощью специально обученных людей).

Опциональный шаг: причёсанный черновик прогоняется через комментарии от "фокус-группы"; делаются правки по мотивам первой обратной связи. Остаётся сверстать, опубликовать; запустить фичеринг "смотрите, у меня тут статья".

===

Тут сразу несколько плюсов:

+Быстрый старт
У разговора с другим человеком есть понятная дата и время, длительность. Часто это быстрее, чем несколько раз открывать пустой документ, смотреть на безжалостно мигающий курсор и в очередной раз откладывать начало работы над статьей.

+Быстрый прогресс
У каждого своя скорость, но в среднем по больнице наговорить условную тысячу слов – быстрее и проще, чем напечатать с нуля ту же самую тысячу.

+Взгляд со стороны
Когда самостоятельно думаешь над идеей для статьи, бывает тяжело. С чего начать? О чём стоит рассказать? На чём сделать акцент?

Когда обсуждаешь, получаешь возможность посмотреть на свой опыт со стороны. Объяснение для собеседника – это сколько-нибудь систематизированная информация (нужно, чтобы сформулировать вслух).

===

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

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

А ещё такой формат – дело вкуса. Некоторым людям комфортнее формулировать свои мысли письменно, а не устно.

===

Несмотря на все эти ограничения, создание статьи через разговор – отличный способ, чтобы начать практиковать деврел или сдвинуться с мёртвой точки. Быстрее результат, быстрее обратная связь. Отличный вариант в случае дефицита времени у автора.

Пробовали так писать статьи? Расскажите о своём опыте!

Новый выпуск "Инженер заходит в бар": инженеры vs синдром самозванца

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

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

Пообщаемся с ребятами из Miro, ВКонтакте и Beeline Казахстан.

Встречаемся 24 ноября, 15:00 МСК.

Присоединяйтесь: https://miro-event.timepad.ru/event/1478817/

Сегодня в 15:00 МСК запускаем новый выпуск "Инженер заходит в бар" – про синдром самозванца в ИТ: https://youtu.be/UkUZrmjHjlE

Приносите ваши вопросы в чат: https://news.1rj.ru/str/joinchat/DDWhOE9s2lDrqu9pVMldkQ

Как внедрять ценностное предложение работодателя внутри компании

Захотеть у себя в компании Employee Value Proposition – дело нехитрое.

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

Сделать EVP – уже хитрее. Не всегда понятно, каким должен получиться результат; где подсмотреть примеры-референсы; сколько времени и денег нужно вложить. И что конкретно делать-то, какими должен быть процесс создания.

Но ок, допустим, какое-то EVP мы сделали. Как превратить EVP из красивых слайдов в рабочий инструмент – самый хитрый момент всей этой эпопеи, на наш вкус.

Мы все видели дурацкие плакаты с ценностями на кухне в офисе. Некоторым посчастливилось быть свидетелями ступора: вот сотрудник всё понимает, разделяет и поддерживает, а вот этот же человек не может повторить формулировки из EVP, даже своими словами. Неправильно внедрять – легко; правильно – непонятно.

"В любой непонятной ситуации кради как художник". Подсмотреть примеры внедрения EVP можно у компаний, которые практикуют. Например, у Netflix.

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

Действовали так: договорились, что менеджеры будут использовать в общении с сотрудниками кодовую фразу – "Не мог бы помочь мне понять, что привело тебя к таким выводам?". Человек начинал аргументировать, и становилось видно, где опирался на факты, данные, а где додумывал. А менеджеры – не бросались ругать или хвалить идею прямо с порога, а сначала собирали фактуру.

Если обобщить: компания вовлекла руководителей в регулярную трансляцию нужного посыла внутри компании, в рабочем контексте. Руководителей, потому что они – сколько-то ролевая модель для остальных. При прочих равных, сотрудники сколько-нибудь берут с них пример.

В модели внедрения культурных изменений по Кену Уилберу, это область "личное – внешнее". Ещё есть "коллективное – внешнее" (процессы) и "личное – внутреннее" (мониторинг настроений). Но об этом в другой раз.

Главная мысль поста: если вдруг ещё не читали отличную книгу бывшего HR-директора Netflix Пати МакКорд "Сильнейшие. Бизнес по правилам Netflix" – обязательно обратите внимание. Там полно занятных идей не только для HR-директоров других стартапов из Кремниевой долины, но и вообще руководителей, неравнодушных инженеров, деврелов. Отдельно хорошо описано, как внедряли EVP.

Рекомендуем!

https://eksmo.ru/book/menedzhment-po-netflix-kultura-svobody-i-otvetstvennosti-samoy-dorogoy-kompanii-v-mire-ITD912688/

Готовим традиционный ежегодный дайджест полезных материалов по деврелу – чтобы было что почитать, посмотреть и послушать на новогодних выходных.

Докидывайте ваши находки к нам в дайджест? Что вам попадалось интересного полезного про деврел, за последнее время или в целом в 2020? Статьи, доклады, телеграм-каналы, книги, что угодно.

Можно присылать артефакты, которые вы сами создали.

С вас наводки, с нас – именные благодарности в дайджесте.

Расскажите в комментах или засылайте в личку?

Если что, прошлые дайджесты тут:
https://devrel-digest.medium.com/что-посмотреть-о-devrel-hr-маркетинге-и-их-друзьях-часть-2-81ba23b9bc69
https://devrel-digest.medium.com/что-посмотреть-про-hr-маркетинг-368d748420c5

Фреймворк для формулирования метрик деврела

"Хотим стать более заметными для инженерного сообщества" – не так уж сложно представить себе компанию, которая подумает такую мысль (мы проверяли).

В целом ок, достойное стремление. Но самое интересное впереди.

"А как мы поймём, что становимся более заметными?" – тепло; "Какие у нас будут деврел-метрики?" – горячо.

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

===

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

Ок, давайте наймём толкового эйчара. Локальная метрика: число и релевантность откликов на нашу вакансию эйчара. Знают ли соискатели о компании нужное, долетает ли до них то важное, которое мы транслируем во внешний мир.

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

Ок, давайте раскачаем внутренние активности по обмену опытом между сотрудниками – внутренние митапы, блог, каналы с тематическими новостями, фичеринг коллег, кто сделал что-то интересное-полезное. Локальная метрика: воронка участия в канале – сколько людей наблюдают в режиме read-only, сколько участвуют в обсуждении, сколько готовы вписаться в качестве автора, сколько в работе, сколько помогает с организацией.

===

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

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

Вот и получается, что в качестве фреймворка для формулирования ваших собственных деврел-метрик можно использовать старый добрый Root-Cause анализ. Выписываем проблему; рисуем стрелки вверх – к последствиям; рисуем стрелки вниз – к причинам; добавляем-соединяем; ищем, какие утверждения аффектят своими стрелками больше всего других проблем в дереве. Зачисляем этих "чемпионов" в корневые проблемы, обрушиваем на них праведный гнев.

===

Почитайте брошюру Хенрика Книберга о Root-Cause анализе. Вы скорее всего знаете мистера Книберга как эксперта в аджайле, смотрели его видео про инженерную культуру Spotify. Но в Root-Cause штуке он не менее крут, ей-богу.

Эти 18 страниц – для нас были полезнее, чем некоторые книги по отдельности, а то и вместе взятые.

===

Если попробуете Root-Cause для формулирования своих деврел-метрик – напишите потом, поделитесь впечатлениями?

https://blog.crisp.se/wp-content/uploads/2009/09/cause-effect-diagrams.pdf

Дайджест полезных материалов о девреле, выпуск-2020

Видео, подкасты, телеграм-каналы, гуглодоки, инструменты нетворкинга для онлайн-мероприятий и в этот раз даже деврелометр.

Enjoy!

https://devrel-digest.medium.com/%D1%87%D1%82%D0%BE-%D0%BF%D0%BE%D1%87%D0%B8%D1%82%D0%B0%D1%82%D1%8C-%D0%BF%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80%D0%B5%D1%82%D1%8C-%D0%B8-%D0%BF%D0%BE%D1%81%D0%BB%D1%83%D1%88%D0%B0%D1%82%D1%8C-%D0%BE-%D0%B4%D0%B5%D0%B2%D1%80%D0%B5%D0%BB%D0%B5-%D0%B2%D1%8B%D0%BF%D1%83%D1%81%D0%BA-3-c50680669c31

Что послушать про деврел

Забегали в юбилейный 127-ой выпуск подкаста Make Sense – поговорить про деврел. Как будто бы под ракурсом продуктового менеджмента, но надеемся, что получилось интересно для людей с разными ролями в команде.

Для разных менеджеров, лидов и сочувствующих.

https://sense23.com/podcast/make-sense-127-o-devrel-podhode-kompaniya-kak-produkt-motivatsii-i-vovlechenii-komandy-s-alekseem-dolgushevym

Ловушка: точные слова для самоидентификации компании

За три года в бюро мы видели появление полутора десятков Employee Value Proposition – ядра формулировок для коммуникаций с инженерами. Со всей ответственностью и статистикой хотим вас предупредить: остерегайтесь желания "ещё немного покрутить формулировки".

==УЗКОЕ МЕСТО В СОЗДАНИИ EVP==

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

На каком этапе больше всего проблем, как думаете? Для нас в своё время это было неожиданностью: самое мучительное – зарелизить EVP.

Казалось бы, уже всё есть! Понятно, о чём рассказывать в историях о компании. Понятно, как это делать, какие есть форматы коммуникаций и точки контакта. Но не тут-то было: червячок сомнений нашёптывает, что нужно "ещё немного покрутить формулировки".

"Мы тут написали, что "reimagine" нашу предметную область. Но ведь точнее будет сказать "reinvent". Ну не "reinvent", а как-то так".

В особо запущенных случаях обмусоливание формулировок происходило дольше, чем все остальные этапы работы над EVP вместе взятые! Безумное количество человекочасов на то, чтобы покатать синонимы по нёбу.

==ПРОБЛЕМА: ПОГОНЯ ЗА ОЩУЩЕНИЕМ==

Чаще всего причина очень человеческая: хочется wow-эффекта. Чтобы выбранные слова о компании били прямо в сердце.

Проблема в том, что если стейкхолдеров хотя бы двое, то тут все шансы не договориться никогда. Пробовали когда-нибудь поделиться песней, которая тронула вас до глубины души и которую вы послушали на репите зиллиард раз в течение дня – видели недоумение на лицах знакомых, "эм, ну ок песня, да"? Тут похожая штука.

Ощущения от формулировок – супер-субъективные. Один чувствует одно, другой другое. И даже интереснее: один и тот же человек может испытывать разные ощущения от одних и тех же формулировок в разное время и в разных контекстах. Встал не с той ноги – формулировки перестали "играть"; выпил кофе – вроде наладилось; проголодался – всё снова плохо.

Погоня за ощущением от EVP – по-человечески понятный, но контр-продуктивный путь.

==МЕТОД: ВМЕСТО ОЩУЩЕНИЙ==

Вместо попыток найти идеальные слова, мы стараемся практиковать диаду "иллюстрации для всего" + "непрерывная обратная связь".

Вот мы говорим, что придерживаемся принципа "fail fast" в разработке – что это значит на практике? Какие есть примеры? А антипримеры? В каких конкретно ситуациях из нашего опыта можем увидеть этот принцип в деле, для каких инженерных решений?

Вот говорим, что вся наша компания ради того, чтобы что-то там "reinvent" – что это значит? Какие критерии у "reinvent", где мы находимся относительно этих критериев, куда хотим попасть?

Уметь объяснить, что именно значат формулировки из EVP – сильно важнее, чем филигранные формулировки в рифму в пределах 280 символов.

Объяснили – теперь собираем обратную связь. Понятно, о чём речь? Отзывается? Собрали обратную связь – тюним, в первую очередь иллюстрации для пояснений.

Любая лаконичная формулировка – абстракция. Будь так же прекрасна на слух, как любимая песня, не будет работать без конкретики.

==В КОПИЛКУ РЕФЕРЕНСОВ==

Пойдёте делать своё EVP, посмотрите, как оно вот у этих ребят, например: https://tettra.com/article/company-culture-deck/
(обратите внимание, сколько будет случаев ну-таких-себе формулировок и при этом компания у вас на слуху, как классная)

Ищем спикеров для "Инженер заходит в бар"

Мы тут планируем следующий сезон митап-сериала "Инженер заходит в бар". Есть задумка – поговорить о путях развития для IT-инженеров. Помимо прочего, хотим позвать ребят, кто был разработчиком, а потом стал ещё кем-то – поговорить об их опыте, как оно так вышло.

Посоветуйте людей?

===

Ищем вот таких ребят:

- технический трек
- "вечный" синьор, сознательно не становится лидом или архитектором
- архитектор
- сменить стек, предметную область – и перестать быть синьором

- менеджерский трек – был разработчик, а стал:
- лид
- ПМ
- продакт
- босс

- шифт в сторону – был разработчиком, а стал QA, аналитиком, дата сайентистом, консультантом, etc. – остался в IT

- выйти из айти – стал предпринимателем в офлайне, видеоблогером, etc.

===

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

Стартовать сезон планируем в феврале.

===

Прошлый сезон можно посмотреть тут: https://www.youtube.com/channel/UC6lFK2V49KhPOv_oikiZ5Sw/featured

#вакансии

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

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

Посмотрите эти вакансии. Покажите знакомым. Даже если ни вы, ни знакомые не собираетесь работать по этому профилю – вакансии помогут лучше представлять, чем занимаются люди в девреле и около него. Будет больше референсов, чтобы поддержать разговор.

======

И на всякий случай пара слов от нас о компаниях с этими вакансиями.

https://www.facebook.com/photo?fbid=3743632999062200&set=a.377881515637382

Те самые ребята, с которыми мы делаем "Инженер заходит в бар" (@serega_shabalin, привет). Помимо прочего, считаем Miro компанией с крутой продуктовой культурой, одной из топовых в этом плане среди знакомых нам.

***

https://hh.ru/vacancy/41850540

Благодаря Deutsche Bank мы в своё время окончательно убедились, что в Новосибирске можно и нужно делать большие Java-мероприятия на целый день или больше (сейчас мы считаем, что такие мероприятия можно и нужно делать не только в, но и из Новосибирска; но это отдельная история про SnowOne, в другой раз).

Из субъективного: все инженеры Технологического Центра Deutsche Bank, с которыми мы знакомы – искреннее любят свою работу, прямо вот заметно невооружённым взглядом. Как компания это делает – нам не до конца ясно, честно говоря; но вовлечённость завидная, бодрит.

***

https://hh.ru/vacancy/41798732

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

======

Готовимся и мы внести свой вклад в метрику про деврельские вакансии – в ближайшие время напишем, какие люди нужны к нам в бюро.

А пока что – увидите ещё деврельские вакансии, рассказывайте нам? Посчитаем.

"Инженер заходит в бар и встречает там консультанта..."

Новый сезон нашего онлайн-митапа – о траекториях профессионального развития разработчиков. Первый выпуск сезона – о ребятах, кто из разработчиков стали консультантами.

Что их подтолкнуло? С какими сложностями столкнулись, как преодолевали? Скучают ли по написанию кода? Куда планируют развиваться дальше?

Своим опытом поделятся:
— Асхат Уразбаев, управляющий партнёр в ScrumTrek
— Максим Дорофеев, прокрастинатолог в mnogosdelal.ru
— Георгий Могелашвили, Mentor/Coach, Lead Developer в Booking.com

Встречаемся в онлайне 2 марта, 15:00 МСК.

Подключайтесь и зовите знакомых: https://miro-event.timepad.ru/event/1551602/

#мероприятия

Деврел-марафон: месяц докладов

Главный инструмент деврела – поддержка.

Без поддержки инженеру кажется, что "у нас всё обычное", "сначала нужно сделать что-то крутое, вот тогда можно будет рассказывать", "мне не о чем рассказать".

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

Без поддержки рисует слайды "как в институте", а после доклада не пользуется обратной связью.

А с поддержкой – получается нормальный доклад.

===

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

Вокруг полно инженеров, кто мог бы делать полезные и интересные доклады, но людям не всегда хватает поддержки. Мы хотим это изменить.

Готовим деврел-марафон: будем вместе готовить доклады.

Для кого: инженеры любых направлений (разработка в любом стеке, тестирование, аналитика, etc.); проджектам, продактам, лидам и другим руководителям – тоже можно, но при условии, что тема доклада будет техническая.

Когда: 16 марта – 16 апреля.

Условия участия: бесплатно; по заявке; в процессе – чтобы оставаться в марафоне, нужно достигать недельных майлстоунов (несложных).

В рамках марафона поделимся своим фреймворком подготовки доклада. Там никакого рокет-сайенса, но наш систематизированный опыт по каждому этапу: поиск темы, выгрузка материала из головы, структурирование, наведение красоты, пробный запуск, подготовка к релизу, релиз, ретроспектива. Для каждого этапа – чеклисты.

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

Марафон пройдёт в отдельном закрытом чате, куда добавим людей из заявок. Приём заявок откроем на следующей неделе.

Интересно было бы в таком поучаствовать?

"Заходят в бар Уразбаев, Могелашвили и Дорофеев..."

Первый митап нового сезона "Инженер заходит в бар" – в следующий вторник.

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

Проверяйте, что записались сами и рассказали о митапе знакомым: https://miro-event.timepad.ru/event/1551602/

2 марта, 15:00 МСК

Запись выложим через пару недель после митапа.

DevRel для HR в 2021

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

2020 внёс "корректировочки" во всё, в том числе в деврел-инструментарий для HR. Какие сложности могут возникнуть у HR с деврелом в 2021 и как c ними бороться – поговорим об этом на онлайн-митапе Иннополиса в этот четверг. Начало в 16:00.

Заглядывайте: https://oez-innopolis.timepad.ru/event/1562804/

Открываем регистрацию на деврел-марафон докладов.

Записываться тут: https://forms.gle/H6w1kDgznVPxMmCQA

Для кого: инженеры любых направлений (разработка в любом стеке, тестирование, аналитика, etc.); проджектам, продактам, лидам, другим руководителям и остальным – тоже можно, но при условии, что тема доклада будет околотехническая, полезная для инженеров.

Когда: 18 марта – 18 апреля.

Формат: онлайн, обсуждения – в закрытом чате, созвоны – в зуме.

Условия участия: бесплатно; по заявке; в процессе – чтобы остаться в марафоне, нужно достигать недельных майлстоунов (несложных).

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

Зачем нам марафон: https://news.1rj.ru/str/hrm_agency/141

Что дальше: записывайтесь сами и пересылайте знакомым инженерам, кому может быть интересно! До встречи на марафоне!

О переходе из разработки в консультанты – опубликовано.

https://youtu.be/p-wY1D_Xa_Q

В интернете пишут, что выпуск получился шикарный🤷

А мы тем временем готовим следующий эпизод о траекториях профессионального развития разработчиков. На этот раз поговорим о переходе "Dev-to-Nocode".

Зашедулили анонс на следующую неделю, stay tuned.

#мероприятия

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

===

Сегодня забежим на митап от PMClub, расскажем о PM-инсайтах из деврела – какими процессами пользуемся сами, что из деврела могло бы быть полезно PM-ам для их обычных недеврельских задач.

Подключайтесь: https://pmclub.pro/webinars/pm-v-devrel-tips-tricks

Новый эпизод "Инженер заходит в бар" – 30 марта.

Если у тебя как разработчика в карьере наступает момент, когда больше не пишешь код – чем тогда ты занимаешься?

Продолжаем исследовать траектории профессионального развития разработчиков — на этот раз поговорим о переходе Dev-to-Nocode.

Пообщаемся с ребятами, кто перестал писать код в изначальном смысле, но остался в разработке, в смежной роли. Аналитика, DevOps, маркетинг, менеджмент – обсудим разные сценарии.

Что подтолкнуло ребят перестать писать код? С какими сложностями столкнулись, как преодолевали? Скучают ли по написанию кода? Куда планируют развиваться дальше?

Эксперты (три Дмитрия!):
— Дмитрий Цыбин, Head of Engineering Productivity в Miro;
— Дмитрий Еремеев, Web-analytics в IsraelPack, Web-development в 150bar;
— Дмитрий Янтер, Аналитик в Технологическом Центре Дойче Банка.

Задать вопросы экспертам и обсудить тему можно тут в чате канала.

===

Встречаемся в онлайне во вторник, 30 марта, 15:00 МСК.

Присоединяйтесь!

Факапы в девреле

Что у вас пошло не так в девреле – наши инженеры продолжают говорить, что им нечего рассказать. Это канонический факап; топ-1, идущий с большим отрывом впереди конкурентов.

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

За 30+ наших кейсов мы видели разное. На каждую заметную удачную историю есть пара-другая не на виду – там всё делали так же, как в успешном кейсе (практически), но итог получился так себе; зафакапилось.

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

Сегодня в 12:00 МСК забежим на FailProject – расскажем, какие видели (ну ок, делали) факапы в девреле и как с подобными штуками можно бороться.

Присоединяйтесь!