Руководители команд, 26 июля в 18:30 встречаемся в московском офисе Авито на первом TeamLead meetup!

Спикеры и темы 🔥

👉🏻 Чего ждут коллеги разных уровней от тимлида?
Работа тимлида не ограничивается собственной командой. Надо контактировать с другими командами, начальством, продактом, и у каждого есть свои ожидания. Евгений Рейх, руководитель кластера Goods Classified, подробно разберёт их.

👉🏻 Как осознать себя в роли руководителя тимлидов?
Если вы хорошо научились управлять разработчиками, это ещё не значит, что будет просто координировать тимлидов. Сергей Баранов, который недавно возглавил юнит Тарифы и не понаслышке знает об этом, поделится своим опытом смены образа мышления, ошибками и источниками силы.

А ещё после каждого выступления ребята проведут открытые дискуссии с коллегами из СберЗдоровья, Тинькофф, Skyeng и Ozon.
Регистрируйтесь: clc.to/Te3ETg.

Кстати, если вы не в Москве или не сможете прийти на встречу, то присоединяйтесь к прямой трансляции митапа на ютуб-канале AvitoTech.

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

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

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

#люди #процессы

У меня тут интересный кейс про развитие 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