Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки
21.9K subscribers
297 photos
2 videos
1.47K links
Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами.

Размещение рекламы: @tanyasanovna

Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Download Telegram
Начинающие тимлиды сталкиваются с разными задачами: первое совещание, распределение нагрузки, контроль за соблюдением дедлайнов. Хочется правильно выстроить процессы и сохранить доверие команды — не превратиться из руководителя-коллеги в грозного начальника.

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

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

7,5 часов вебинаров, где можно отработать навыки, и бессрочный доступ к интерактивному учебнику с теорией. Интенсив длится девять дней и стоит 15 000 ₽.
Новый поток стартует 18 августа. Записаться
Когда инженерная команда Uber выросла до 100 человек, было принято решение разбить ее на две большие части:
🪄Program – команды, которые делают продукт для конечных пользователей
🪠Platform – команды, которые разрабатывают инфраструктуру и продукты для внутренних потребителей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#инструменты #развитие_себя
Еще один подход к описанию всех функций, из которых состоит роль менеджера.
Как в 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.
- Поговорите с теми, кто уже показывал что-то этому топ-менеджеру. Это поможет узнать дополнительные советы, которые помогут правильно подойти к разговору.
- Не стоит спорить с обратной связью. Лучше сделать это позже.
- Не избегайте ответственности и проговаривания проблем.
- Не приходите без готового ответа.
Путь из СТО в инженеры

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

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