Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки

Как давать субъективный фидбэк Давать объективный фидбэк, довольно просто – напоминаешь ожидания, описываешь реальность, подкрепляя конкретными фактами, подсвечиваешь дельту между ними, готово. С субъективным фидбэком обычно все сложнее, потому что подкрепить его неопровержимыми фактами уже не получается. И мне, и многим другим тимлидам давать такую обратную связь намного сложнее, поэтому часто она откладывается куда-то в сторону, забывается и не доносится до сотрудников. Несколько правил, которые вам помогут: 👉Вообще забудьте о том, что фидбэк обязан быть объективным, это не так. Любая обратная связь от другого человека так или иначе субъективна. Главное, чтобы она была направлена на пользу общему делу. 👉Как обычно, по максимуму фокусируйте обратную связь на работе, а не на личности. Это касается как обсуждения нежелательного поведения, так и результатов – вам не надо просить человека меняться, вам надо объяснять ему, как его работа влияет на общий результат. 👉Чтобы дополнительно показать, что вы пришли поддержать, а не обвинять, подсветите роль окружения и внешних факторов в нежелательном поведении. 👉Расскажите, какой вы бы видели работу человека в идеальном мире, фокусируясь на конкретных изменениях.

Про зомби-процессы Зомби-процесс – это какая-то практика, которая продолжает использоваться в компании только потому, что так принято, а не потому, что она продолжает приносить ту пользу, которая предполагалась изначально. Стандартный пример – OKR. Такой дрифт происходит постепенно: 👉Потихоньку растет разрыв между реальным миром и тем, как процесс выглядит на бумаге. 👉Практика перестает помогать командам, находящимся на передовой. 👉Падает уверенность в том, что другие участники процесса будут следовать ему честно. 👉Команды адаптируются к изменившемуся процессу, чтобы продолжать делать то, что считают нужным, оставаясь в безопасности, формально следуя ему. 👉Весь процесс смещается в сторону пустых формальностей. 👉Включается в силу sunk costs fallacy, поэтому от процесса жалко отказываться. 👉Все меньше возможностей почелленджить смысл практики. 👉Посколько все на самом деле уже понимают, что работают с зомби-процессом, даже топ-менеджеры, которые его изначально и внедряли, начинают искать другие способы обеспечить желаемый эффект, и работать сбоку этого процесса. Единственный способ бороться с зомбификацией – бороться с самим дрифтом. Ответственные за процесс должны регулярно сверяться с реальностью и проверять, продолжает ли процесс приносить ту пользу, которая от него ожидалась, или нет. Чтобы это работало, нужно давать пользователям процесса побольше возможностей почелленджить его и поделиться фидбэком.

Как Leetcode влияет на прохождение интервью Ребята, которые делают сервис мок-интервью, продолжают делиться интересными данными. В этот раз они проанализировали корреляции между тем, насколько много задач и какого уровня прорешал кандидат с тем, какой перфоманс он показывал на собеседованиях. 👉В целом корреляция между решением задач на Leetcode и успешным прохождением интервью довольно сильная. 👉На силу корреляции влияет количество решенных задач и их сложность. При этом количество влияет только до определенного порога, после 500 задач эффект перестает расти так сильно. 👉Рейтинг на Leetcode не коррелирует с успешностью интервью. 👉Прорешивание сложных задач в два раза эффективнее, чем задач средней сложности. Каждые 50 сложных задач ведут к повышению успешности прохождения интервью на 7%.

Как группа становится командой Отличная статья от Дмитрия Болдырева, разбирающая каждый из этапов формирования команды – forming, storming, norming, performing, на примере монтажной бригады, прокладывающей ЛЭП где-то в тайге. Всю статью пересказывать не буду, поделюсь лишь одной частью – список вопросов, на который у группы должны быть ответы, чтобы она могла функционировать как нормальная команда: 👉Предмет деятельности (чем мы будем заниматься?) 👉Цели (зачем мы всё это делаем и каких именно результатов планируем достичь?) 👉Стратегия (каким образом, за счёт чего мы добьёмся поставленных целей?) 👉План (что, когда, в какой последовательности будем делать?) 👉Рабочие процессы (как что должно происходить?) 👉Роли (кто за что будет отвечать, кто конкретно, что именно будет делать?) 👉Регламенты взаимодействий (кто, что, кому передаёт, когда, в каком виде и т.д.?) 👉Стандарты качества (какое выполнение работы будет считаться хорошим, а какое плохим?) 👉Способы контроля качества (как мы будем проверять и оценивать выполненную работу?) 👉Система ответственности и вознаграждений (что получат участники, если добьются или не добьются ожидаемых результатов; как индивидуальных, так и групповых?) 👉Правила принятия решений (какие решения могут приниматься индивидуально, какие только группой и, если группой, то по какому принципу – единогласно, большинством или каким-то иным способом?) 👉Нормы поведения (какое поведение приветствуется, а какое нет?) 👉Система статусов, она же внутренняя иерархия (кто какой имеет вес и влияние?) 👉Лидерство (кто будет всем управлять, кого мы будем слушаться?) Если предпочитаете смотреть, а не читать, вот тот же материал в видеоформате.

Как продавать свою работу Хотели бы научиться правильно доносить до руководства и команды ценность вашего вклада в общее дело? Как «продавать» свой труд без лишней скромности, но и без «перебора», расскажут на открытом эфире от Школы менеджмента «Стратоплан». Основной результат, который вы получите – научитесь честно и без пафоса заявлять о ценности своей работы и значимости своей роли в процессах компании и достижении общего результата. 📆Дата: 18 сентября, среда, 13:00 (GMT+3) 🔗Регистрация

Запугивающие вопросы Еще будучи джунами во время своих первых code review многие из нас прочувствовали на себе, что один и тот же вопрос можно задать кучей разных способов. И если на некоторые вам хочется отвечать, то некоторые быстро пробуждают все самое худшее – неуверенность в себе, синдром самозванца, чувство некомпетентности. Менеджерам особенно важно уметь чувствовать эту грань. Некоторые вопросы могут довольно сильно подорвать моральный дух ваших сотрудников. Вот несколько таких примеров: ❌Я просил тебя это делать? ❌Кто дал тебе право принимать решение? ❌С чего ты взял, что это будет работать? Вот более корректные варианты формулировок: ✅Из каких вариантов решения и как ты выбирал? ✅Какие факторы повлияли на то, как ты принимал решение?

Новый выпуск Sravni Podcast — о том, как управлять процессами в мобильной (и не только) разработке. Денис Сизый, тимлид Сравни, рассказал о тонкостях перехода из разработки в менеджмент, взаимосвязи продуктов и технологий, развитии скиллов и собственном пути в ИТ — от написания первого калькулятора на Pascal до управления командой. Среди вопросов, которые обсудили с гостем: как и для чего сеньор становится тимлидом? В чем польза архитектурного мышления? Нормально ли, если разработчик в команде не хочет развиваться? Бывают ли в идеальном мире дейлики? ✅Смотреть выпуск на YouTube ✅Смотреть на RUTUBE ✅Смотреть в VK ✅Слушать на Яндекс Музыке Реклама. ООО "Сравни.ру", ИНН 7710718303, erid:2SDnjd1Srti

Менеджеры-антипаттерны Отличная подборка детально разобранных примеров поведения, которое вы могли встречать как у других менеджеров, так и у себя. Вот некоторые из них: 👉Бомба. Менеджерам с хорошим послужным списком работы в крутых командах часто поручают исправить команду-лоуперформер. Заряженный энергией менеджер прибегает в такую команду, начинает искать проблемы, конечно же их находит, и полностью перестраивает все, чем команда занимается, и как она работает. Проблема в том, что часто с водой выплескивается и ребенок – без нормального контекста сложно определить руткозы проблем конкретной команды, и перестройка случайных вещей скорее вредит, чем помогает. 👉Сфинкс. Вместо того, чтобы открыто сообщать команде плохие новости, он предпочитает молчать до последнего. Как результат – происходят непредсказуемые реструктуризации, приоритеты меняются внезапно, и команда не знает, чего ожидать. Такой менеджер может даже верить, что таким образом защищает команду от "булшита сверху". Проблемы очевидны – пропадает доверие менеджеру, а качество проекта из-за частых изменений страдает. 👉Менеджер с молотком. Молотком может быть что угодно – конкретная технология, стиль менеджмента, организационный фреймворк. Суть в том, что менеджер, пару раз добившийся успеха с использованием конкретного инструмента, будет пытаться и дальше слепо везде его применять, даже если контекст изменился. В статье еще больше антипаттернов, и для каждого из них детально разобраны последствия и способы митигации.

Как стать тимлидом, кого из коллег повышать и что делать с синдромом самозванца Делимся материалами с Yet Another Level — серии митапов про жизнь и развитие в IT-компаниях от Яндекса. На них эксперты обсуждают прокачку софт-скилов, карьеру, менеджмент, нетворкинг и многое другое. Yet Another level делится на два направления: ❇️ Evolution — как разработчику выполнять все обязанности и оставаться счастливым ❇️ Team Lead — что нужно знать начинающему тимлиду и куда расти опытному Собрали экспертов из разных областей, чтобы обсудить все больные и насущные вопросы. Ловите доклады из подборки: 🔴 Анастасия Абрашитова, руководитель отдела DevTools, Яндекс. Рассказала, как повышать разработчиков до тимлидов, чтобы это не превратилось в лотерею 🔴 Евгений Идзиковский, IT-психолог частной практики. Показал, откуда берётся синдром самозванца и культ достигаторства и как с ними жить 🔴 Александр Афенов, Technical Cluster Lead в Авито Доставке. Рассказал о двух вариантах судьбы тимлида и частых ошибках при первых шагах на новом месте ➡️ Все 14 выступлений собрали в один плейлист. Посмотреть его можно: 🅰️ на ютуб-канале 🅰️ или в VK Видео Смотрите, оставляйте отзывы и советуйте друзьям!

Как работать с зависимостями между командами Любая зависимость между командами порождает риски, так как может негативно повлиять на время и качество разработки, перфоманс и мотивацию команды. Как и с любым другим риском, можно предпринимать следующие действия: 👉Избавиться от риска, минимизировав количество зависимостей. В целом, зависимости могут создаваться на трех уровнях: бизнес-требования, инженерный процесс и компоненты системы. Чтобы понять, что делать, вам надо определить, с каким из этих уровней вы столкнулись, и нужным образом пересобрать команду или границы ее области ответственности. 👉Митигировать риск, уменьшив негативные последствия, вызываемые зависимостями. В основном все крутится вокруг того, что команды, зависимые друг от друга, должны работать максимально тесно, с малым количеством переключений контекста и отвлечениями на другую работу. Помочь с этим могут практики вроде общих стандартов разработки, единого бэклога на все команды, организационные паттерны вроде платформенных команд, да и в целом распространение знаний. 👉Управлять риском, организовав координацию между такими командами. Тут помогает грамотный процесс планирования, в рамках которого зависимые команды могут работать как последовательно, так и параллельно.