У меня тут интересный кейс про развитие EdTech в России. В сентябре 2022 года ребята из iSpring открывают полноценный институт в Йошкар-Оле. Первый бакалавриат запускается по 4 специальностям: программирование, продакт-менеджмент, маркетинг и дизайн продукта. Почему это крутая новость – институт работает в тесной связке с различными IT компаниями, и стажировки студентов на реальных проектах начинаются фактически с первого дня, а со второго курса каждый уже работает парт-тайм. Я очень верю в то, что тесная связь между образовательными учреждениями и бизнесом дает более прикладные знания и позволяет студентам уже в процессе обучения прицельно выстраивать свою карьеру. Разрывается порочный круг джунов, которые получают отказы на собеседованиях, потому что на момент поиска работы у них нет опыта.

Из интересных фактов:
📌Результаты ЕГЭ не главное, в институте iSpring разработали собственную систему набора с фокусом на мотивацию, внимание и когнитивные способности
📌В преподаватели набирают только практиков
📌В первом наборе – всего 120 мест, на 82 из которых предусмотрены гранты
📌Новый кампус института больше похож на офис IT-компании, чем на учебные аудитории

В общем, отличный шанс залететь в IT и уже на 1 курсе стать участником большого продакшн проекта! Все подробности – на сайте института iSpring.

За последние годы во все большем количестве компаний появляются расширенные инженерные карьерные пути. Часто их обозначают как Staff+. Но одним только введением новых карьерных уровней не обойтись. Staff+ роли требуют соответствующего уровня задач, инженерной и менеджерской культуры. Автор статьи проинтервьюировал кучу staff+ разработчиков из больших и маленьких компаний и сделал подборку самых частовстречающихся дисфункций. Вот некоторые из них:
📌Под красивыми лозунгами про автономность в выборе целей и соедств их достижения staff+ инженеров на самом деле скрывается отсутствие поддержки от менеджеров и понимания с их стороны того, что нужно делать
📌Staff+ инженерам предлагается управлять другими за счет авторитета, в то время как вся корпоративная культура ориентирована на управление за счет административных полномочий
📌Менеджмент требует тратить на написание кода все время, не учитывая другие активности
📌Staff+ инженерам ставятся большие амбициозные цели, но менеджмент не пытается помочь в их достижении за счет работы со стратегией и оргструктурой, в результате ничего не получается

#люди #найм #управление_компанией

Несколько важных законов, понимание которых сильно облегчает работу тимлида:
1️⃣Закон тривиальности Паркинсона: «Люди в обсуждениях уделяют гораздо больше времени банальным или косметическим вопросам, нежели серьезным и существенным»
2️⃣Закон Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»
3️⃣Закон Иглсона: «Любой ваш код, который вы не видели шесть или более месяцев, выглядит так, будто написал его кто-то другой»
4️⃣Закон кибернетической энтомологии: «Всегда есть еще один баг»

#инструменты #развитие_себя

Еще один подход к описанию всех функций, из которых состоит роль менеджера.

Если вы задумываетесь о поиске работы тимлидом в Европе, обязательно посмотрите серию видео с недавней конференции Team DrivenCon:
📝Публичное собеседование с интервьером из Meta
📝Публичное собеседование с интервьюером из LinkedIn
👨‍👩‍👧‍👦Групповое ревью резюме инжиниринг менеджеров и советы по их улучшению
💰Обзор зарплат тимлидов и механизмов компенсации в разных странах Европы

Как в Flo переработали процесс найма

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

В итоге, основные изменения, которые внедрила команда, получились такими:
📝Использовать единый пайплайн для схожих позиций
📝За каждый пайплайн отвечает группа менеджеров
📝Этапы пайплайна визуализируются
📝Слоты на интервью бронируются в календарях заранее и не меняются
📝Все интервью ведутся в парах
📝Составляется список людей, отвечающих за bar rising, и они включаются в процесс

Все изменения команда завернула в эксперимент, который в результате привел к уменьшению среднему времени закрытия вакансий с 70 до 30 дней.

Я рекомендую статью для всех, кто недоволен своим процессом найма, как пример системного подхода к изменениям.

#найм

Разгружаем команду разработки от любых внешних коммуникаций с помощью дежурных

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

В результате такого подхода команды получили:
- Крутое обучение новичков
- Шаринг знаний внутри команды
- Повышение эффективности работы всей команды, несмотря на потерю одного человека
- Появилось чувство коллективного владения кодом

#процессы

Сделать первые шаги к карьере программиста можно через Python. Это востребованный, но простой язык: код компактный и похож на английский текст. Чтобы вывести надпись «tests» на экран, можно так и написать: print(""tests""). Освоить профессию Python-разработчика можно на курсе Яндекс Практикума.

◾️ Базовая программа → 9 месяцев
— интенсивная учёба по 20 часов в неделю;
— реальные рабочие задачи с первого дня;
— 6 учебных проектов в портфолио;
— программа трудоустройства: научим составлять резюме и проходить собеседования.

◾️ Расширенная программа → 14 месяцев
— учёба в среднем темпе по 15 часов в неделю;
— фундаментальная теория и много практики;
— 12 учебных проектов и проекты от реальных заказчиков в Мастерской;
— гарантия возврата: если вы не получите предложений о работе за 6 месяцев после выпуска, мы вернём деньги за обучение.

Наша статистика показывает, что сменить профессию — реально: 78% наших выпускников находят работу в новой сфере. Попробуйте курс бесплатно →

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

Вообще, обучение тимлидов – сложная штука. Одной теорией все запросы закрыть не получится – ведь полученные знания надо как-то применять и отрабатывать. Практику наработать тоже сложно – не у всех сходу есть готовая команда и проект, на которых можно учиться. Нам со Стасом всегда очень нравился Go Practice – симулятор работы продакт-менеджеров. Симулятор удерживает крутой баланс между прикладными знаниями, авторским опытом и проверкой изученного материала на живых заданиях и кейсах. И все это доступно для прохождения в асинхронном режиме в удобном именно для тебя темпе.

Мы решили попробовать перенести эту модель на обучение тимлидов, и несколько месяцев назад начали разрабатывать Симулятор Тимлида – большой интерактивный курс, который обучает и дает попробовать на практике самые важные инструменты и практики для менеджера, управляющего командами разработки. Чтобы разработать Симулятор, нам нужно подготовить огромную гору контента – и мы понимаем, что этот проект может спокойно занять год-полтора. Ждать столько времени, чтобы получить первичную обратную связь о том, насколько сам формат обучения и контент полезны – с продуктовой точки зрения самоубийство. Поэтому мы решили начать собирать фидбэк как можно раньше, и открыть программу раннего доступа к Симулятору. Что у нас уже есть – MVP версия обучающей платформы, одна очень большая глава про управление встречами и календарем, и еще две близкие к релизу главы – одна про обучение сотрудников, другая – про подбор людей в команду.

Мы видим ранний доступ как очень маленький, не больше 20 участников, закрытый клуб из тимлидов, которые готовы активно участвовать в разработке проекта – проходить новые главы, давать много обратной связи, делиться своими рабочими кейсами и проблемами, помогать нам шлифовать все предлагаемые модели. Мы хотим собрать маленькое, но очень живое коммьюнити, которое будет прокачиваться в профессии паралелльно с тем, как мы пишем Симулятор. По опыту работы с другими сообществами я знаю, что такие закрытые тусовки работают гораздо лучше, когда за доступ в них есть небольшой донат. Пока мы не знаем, сколько будет стоить доступ к итоговому курсу – поэтому ежемесячный донат за доступ к ранней версии выбрали практически наугад, 300 рублей.

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

Мы очень верим в крутость Симулятора, и хотим собрать вокруг себя еще людей, которые смогут кайфовать в процессе его написания вместе с нами!

👉Форма регистрации

Принципы здорового алертинга и on-call процесса

Почти во всех компаниях процесс on-call дежурств – боль, страдание и частая причина увольнений. В презентации СТО Honeycomb предлагает следующие шаги по исправлению ситуации:
🌡Выключить алерты на симптомы, заменить их алертами на SLO, которые привязаны непосредственно к болям пользователей.
🤔Удалить все флакующие алерты, потому что моральное состояние людей важнее.
🚨Почти все алерты должны падать во второстепенную очередь, на которую не требуется мгновенная реакция дежурного. Вместо этого, очередь можно разбирать с началом рабочего дня.
📝Каждый алерт должен идти со ссылкой на подробную документацию о том, что его может вызвать.
👀Инвестируйте в observability своего кода и сервисов, профилируйте максимально часто и ловите баги до того, как они отстрелят у пользователей
📈Используйте SLO для того, чтобы приоритизировать работы по техническим улучшениям

#техлидство

Подборка инструментов, помогающих думать

Сайт с каталогом инструментов и фреймворков, которые помогают улучшить коммуникацию, прокачать системное мышление и принятие решений. Среди них – Пирамида Минто, Six Thinking Hats, Decision Matrix.

📆Каждую неделю я стараюсь публиковать несколько классных и полезных материалов про тимлидство. За месяц их набегает несколько десятков, и ориентироваться в них не всегда легко. Чтобы облегчить вам задачу, раз в месяц я публикую дайджест самых популярных постов, разбитых на категории.

✍️Менеджерские практики
Большой гайд по менеджменту remote команды
Надо ли включать камеры на созвонах
Выпуск Подлодки про то, что оценки не нужны
Подборка шаблонов RFC и PRD

👀Поиск работы тимлидом
Коллекция видео Team DrivenCon про поиск работы тимлидом в Европе
Как подготовиться к собеседованию на Engineering Director
Публичное собеседование тимлида

💬Коммуникации
Как научить не бояться просить о помощи
Рассказываем о своем опыте, используя метод STAR
Системный разбор рабочих конфликтов
Как связаны выгорание и рабочие конфликты

👨‍👨‍👦‍👦Найм и рост
Почему карьерная линейка Staff инженеров часто не работает

🐣Подписывайтесь на мой Твиттер – там я пишу немного смешные шутки про айти, полезные тимлидские треды и рассказы про то, как мы деляем язык программирования.

Если дайджест вам понравился – ставьте ❤️, 👍 и 🔥. Благодаря этому я пойму, что собирал его не зря! А если у вас будут конкретные предложения по его улучшению – смело пишите в комментарии!

#digest

Как общаться с топ-менеджерами

- Лучший способ подготовиться – изложить свои мысли в документе, это само по себе заставляет подходить к проблеме структурно.
- Попробуйте фреймворк SCQA: Situation – Complication – Question – Answer.
- Поговорите с теми, кто уже показывал что-то этому топ-менеджеру. Это поможет узнать дополнительные советы, которые помогут правильно подойти к разговору.
- Не стоит спорить с обратной связью. Лучше сделать это позже.
- Не избегайте ответственности и проговаривания проблем.
- Не приходите без готового ответа.

Путь из СТО в инженеры

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

- Готовьтесь к тому, что технические скиллы вы потеряли – они забываются гораздо быстрее, чем менеджерские.
- Проблема не столько в потерянном умении писать код, сколько в том, что вы разучились фокусироваться на одной задаче, и привыкли работать с постоянной сменой контекста.
- Лучше всего начать с нового технического стека, а не с того, экспертиза в котором у вас была раньше.
- Желательно найти проект, в котором ваш код действительно влияет на пользователей, так будет проще вспомнить забытое удовольствие.
- Избегайте вакансий архитекторов, иначе рискуете быть все так же далеко от кода.

Должен ли менеджер быть щитом от дерьма для команды

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

Как давать полезный фидбэк

- Используйте принципы radical candor: проявляйте явную заботу о том, кому вы даете фидбэк, но в то же время будьте максимально прямым и откровенным.
- Не пытайтесь защитить людей от неприятного фидбэка, это им не поможет. В то же время, не стоит и вываливать негативную обратную связь, не проявляя участия и заботы.
- Попробуйте следующий процесс: получить согласие на фидбэк > расскажите факты > объясните, как конкретно эти факты повлияли на результат > завершите вопросом про то, как человек сам видит всю ситуацию.
- Постарайтесь давать обратную связь как можно чаще, это помогает оттачивать навык.

Как сделать так, чтобы сотрудники приходили к тебе с решениями, а не проблемами?

Кажется, что так бывает только в раю, но эффективный менеджмент и честное взаимодействие с коллегами ещё и не на такое способны!
Вот несколько шагов, которые помогут взрастить уровень ответственности подчинённых.
👇🏻
Держитесь позиции взрослого
Не берёте ли вы на себя роль “родителя”, когда сотрудники обращаются к вам с позиции детей и приглашают взять на себя функции спасения? Есть вероятность, что у команды гораздо больше компетенций для решения проблем.
👇🏻
Сверяйте степень директивности
Не душите контролем тех, кто уже показывает высокий уровень ответственности. Лучше поощряйте автономность и воспроизводите постепенно эту модель с теми, кто пока нуждаются в конкретике.
👇🏻
Будьте готовы к ошибкам
Любая инициатива и изменения увеличивают шанс на ошибку, но без этого вы не получите развития коллег. Планируйте люфт и ресурсы для возможных экспериментов, внедряйте общие практики спокойного и позитивного разбора ошибок.
👇🏻
Спрашивайте, а не отвечайте
Постепенно увеличивайте количество навигирующих вопросов по задачам, чтобы побудить сотрудника к собственным предложениям. Не «Давай сделаем так», а «Как ты считаешь, что здесь можно сделать?»

👥 Этот и другие сложные управленческие кейсы разбирают на курсе «Как управлять командой и собой». Живые воркшопы от экспертов с многолетним опытом в управлении помогут решить ситуации, которые волнуют вас прямо сейчас. Вы подготовитесь к любым трудностям в команде — от кризиса до реструктуризации.

Все детали о спикерах и обучении здесь: https://clck.ru/sTiTx

Подборка статей про стратегию

Недавно наткнулся на серию заметок про разные аспекты работы над стратегией. В этих материалах не будет никаких готовых фреймворков, но меня они натолкнули на кучу полезных мыслей:

- Оценка стратегии через призму “ставок”, и баланса между risk и reward
- Про то, почему многим стратегиям не достает ясности, и почему они очень абстрактны
- Чем отличаются фокусировка и обобщение в стратегии
- Как собирать фидбэк на стратегию, и почему разные люди говорят разные вещи
- Почему у многих команд и компаний нет стратегии
- Нормально ли, если стратегия часто изменяется

Переход из тимлида в менеджеры менеджеров: вредные советы

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

🎤Автор предлагает с первого месяца в новой роли ворваться в хайринг – разобрать все открытые вакансии, выяснить как они ложатся в общую стратегию, подключиться к процессу интервью самостоятельно. Цель всего этого – получить общую картину по тому, насколько здоровый в команде процесс найма.
💬Найм – это инструмент. До того, как пытаться его чинить, надо понять, а есть ли с ним вообще проблема. Наличие проблемы не определить, пока ты не понял, а что и зачем в командах разрабатывается. Поэтому я бы построил план по-другому:
1. Разобраться с общей стратегией компании, поговорив с релевантными людьми.
2. Выяснить, в чем заключается успех работы каждой из команд.
3. Поговорить с заказчиками и сотрудниками и собрать список известных им проблем, которые мешают достижению успеха.
4. Вместе с тимлидами своих команд оценить влияние этих проблем друг на друга, выделить корневые.
5. В зависимости от того, в чьей зоне влияния находятся проблемы, делегировать их решение тимлиду или заняться этим самостоятельно.

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

🎤Автор советует организовать регулярные встречи со всеми, с кем только можно – 1/1 с заказчиками, синки с коллегами, еженедельные митинги с прямыми подчиненными.
💬Синхронное общение – отличный инструмент для тех случаев, когда требуется соединить картины мира и знания нескольких людей чтобы быстро прийти к общему решению. Это очень дорогой инструмент – он сильно вырывает людей из рабочего контекста, причем в то время, которое удобно автору встречи, а не им.

Заводить кучу встреч без явной агенды с целью «посинкаться про статус» – вредно для всех участников. Вместо этого я бы рекомендовал следующий подход:
1. Асинхронное общение по умолчанию. Если вам нужно узнать статус каких-то проектов – настройте общение в чате или в проектном трекере.
2. Если требуется регулярное общение с одними и теми же людьми в рамках решения какой-то конкретной проблемы – регулярные встречи рабочих групп с внятной повесткой – тоже нормально.

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

Как подходить к решению крупных проблем

🤔Не всегда первое приходящее на ум решение будет самым лучшим. Потратьте время на то, чтобы аргументировать его.
💬Проверьте, что проблему вообще стоит решать, поговорив с людьми с другим бэкграундом.
🤬Не поддавайтесь на критику сомневающихся, но отрабатывайте их возражения.
🤝Учитесь убеждать стейкхолдеров, находя свои аргументы для каждого из них.
👨‍👩‍👧‍👦Постройте две команды – инженерную, которая будет работать над решением каждый день, и расширенную, включающую в себя юристов, бизнес, дизайн и другие функции, которые могут пригодиться.