На HighLoad++ 2017 было много интересных докладов, посвященных практически всем аспектам пути тимлида — от поиска того самого человека среди обычных разработчиков и до деталей работы и последующего движения к руководителю более высокого уровня вплоть до CTO.
Для этого обзора мы выбрали восемь наиболее популярных выступлений.
Выбранные выступления объединяет то, что участники изложили общие мысли о проблемах руководства технологическими командами через призму личного опыта, который, что важно, у каждого был свой. И поскольку докладчики работают в разных компаниях и над разными задачами, представленная подборка позволяет взглянуть на проблему с самых разных точек зрения.
Наши спикеры сходятся лишь в одном: технологическими командами должны руководить те, кто понимает, как это все работает, поэтому проще вырастить тимлида и руководителя более высокого уровня внутри команды, нежели нанимать администратора и обучать его технологиям.
Очень много было сказано о том, кто такой тимлид, каковы его основные обязанности и как ему решать те или иные административные задачи. В данном случае мы не претендуем на полноту изложения картины, а хотим порекомендовать видеозаписи лучших наших докладов для просмотра.
Обзор мы разбили на две части. В первой остановимся на докладах, посвященных переходу из инженера (разработчика) в тимлиды, а также на некоторых советах, касающихся ежедневной рутины. Во второй части пойдем дальше и обсудим развитие тимлида в руководителя более высокого уровня, а также посмотрим на команды разработчиков и их типичные проблемы под другим углом — через призму психологии.
Тезисы доклада
В первом докладе из нашего дайджеста Андрей Рыжкин (компания AGIMA) описывает собственноручно формализованную процедуру выращивания тимлидов внутри команды, попутно предостерегая разработчиков о том, что же изменится в их жизни, если они перейдут на «темную сторону», т.е. в руководители.
Как отмечают в своих докладах многие участники конференции, новоиспеченному тимлиду придется привыкнуть к тому, что времени на разработку и интересные задачи, связанные с какими-то исследованиями, у него уже не останется. Кроме того, придется выйти из комфортного потокового режима работы — как-то уживаться в мире с параллельными задачами, прилетающими одновременно по нескольким каналам, а также с большим количеством коммуникаций и планированием. В своем докладе Андрей Рыжкин дает некоторые советы, как справиться с непривычной ситуацией и не перегореть под давлением ответственности, а может и оставить себе задел на дальнейшее развитие (хотя по его данным 90% тимлидов так и останавливаются на этом уровне).
Доклад будет интересен не только сегодняшним разработчикам, метящим в тимлиды, но и руководителям, которые пытаются вырастить в коллективе себе замену. Им Андрей поможет ответить на вопросы: кого стоит взять в тимлиды? На какие качества надо обратить внимание? Стоит ли возлагать эти обязанности на самого лучшего разработчика в команде?
По опыту докладчика, чтобы прогнозировать вероятный успех персонажа в роли тимлида, ему достаточно обладать всего тремя качествами: эмпатией к команде, решительностью и технической компетенцией. Но все не так просто: на старте тимлиду нужна помощь, которую иногда можно обеспечить через правильные привычки внутри коллектива. Один из обсуждаемых примеров — так называемый «санитарный день» (а на самом деле — санитарные часы) — время, выделенное для написания отчетов и планирования. Практики, принятые в AGIMA и подробно описанные в докладе, подсказывают, с какой стороны вообще можно подступиться к решению проблем тимлида.
Естественно, рассмотрена и другая сторона вопроса — «косяки» неопытного тимлида, с которыми можно и нужно бороться (как один из примеров — любовь к закапыванию в длинных задачах). В ходе вопросов после доклада обсудили и процесс обучения остальной части команды, как правильно взаимодействовать с тимлидом.
В дополнение Андрей Рыжкин предложил список литературы, которая будет полезна будущему тимлиду. Эту ссылку вы еще встретите в презентации спикера, но мы решили вынести ее в наш анонс.
Тезисы доклада
Следующий доклад — для состоявшихся тимлидов. Потенциального адепта «темной стороны» уже выявили в коллективе и бросили грудью на амбразуру (то есть формально или неформально поставили тимлидом). Но говорить о том, что он справился с ситуацией еще рано. И на этом этапе потребуется не только помощь коллектива и корпоративных привычек, описанных выше, но и саморазвитие специалиста. Об этом и рассказывает Артем Каличкин (ГК ЦФТ), опираясь на свой 11-летний опыт работы.
В форме тезисов Артем рассказывает, как «не потонуть» на новой должности: на какие стороны собственной личности стоит обратить внимание, что развивать, а от чего, наоборот, отказаться.
В докладе разобраны самые яркие «тараканы» начинающих тимлидов: выгораживание подчиненных от любых нападок извне команды — «материнский инстинкт», страдания при адаптации мозга инженера к административной работе, стремление принять лучшее решение из возможных — «синдром отличника», попытки делать всю работу подразделения самостоятельно. На каждом из перечисленных паттернов поведения докладчик подробно останавливается, описывая его сразу с нескольких сторон (почему это плохо для команды, компании и почему это плохо для самого тимлида) — чувствуется опыт на разных уровнях руководства.
Кстати, Артем считает, что практически сразу с момента перехода на должность тимлида специалист должен начинать растить себе заместителя. В помощь этому процессу он рассматривает три из выделенных им пяти этапов выращивания будущего руководителя: выявление, тестирование и начало пути. По сути это несколько иной взгляд на те же проблемы, что описаны в первом докладе нашего дайджеста. Для каждого из этапов предлагаются антипаттерны поведения и способы с ними справиться.
Тезисы доклада
Следующий доклад переводит нас к теме ежедневных обязанностей тимлида. Несмотря на то, что кадрами в компаниях как бы занимается HR отдел, будущий непосредственный руководитель нового сотрудника должен участвовать в найме — в конце концов, ему потом руководить этим человеком. Степан Овчинников (компания Интерволга) дает выжимку полезной информации о том, куда смотреть и за что хвататься тимлиду, который включился в процесс сбора команды.
Представленный опыт был получен в компании с 60 сотрудниками (32 из которых — программисты), реализующей заказные проекты на Bitrix, что как бы ограничивает его применимость. Однако с определенными оговорками приведенные рекомендации можно использовать в самых разных ситуациях.
Докладчик прошелся по всем основным моментам работы с персоналом со стороны тимлида: найме, мотивации и даже увольнении (хоть это и считается в современном мире кощунством). Высказал рекомендации, что спрашивать на собеседовании, чтобы вскрыть мотивацию и выявить неадекват, предложил пути для поддержания уже нанятых сотрудников в состоянии повышенной мотивации, подсказал, как лучше уволить человека, чтобы не взбудоражить остальную команду.
Ценность доклада в том, что в нем даны вполне конкретные советы — что делать, чтобы собрать команду и не растерять ее. К примеру, Степан рекомендует периодически вести неформальные разговоры с коллегами, чтобы следить за их настроением и вовремя заметить назревающие проблемы. Еще одна полезная рекомендация — постоянно повышать сложность задач, чтобы избавить разработчиков от скуки. А если это по каким-то причинам невозможно (поменять технологии в большинстве компаний не так просто), сотруднику можно выделить время на профессиональный рост.
За остальными идеями советуем обратиться к докладу. Там все рекомендации дополнены весьма красочными примерами из жизни.
Кстати, и тут не обошлось без обсуждения типичных проблем начинающего тимлида, например, любви к глубокому погружению в любой вопрос или боязни увольнений своих подчиненных. Так что с точки зрения формирования образа тимлида доклад дополняет два предыдущих.
Тезисы доклада
В своем докладе Антон Потапов (компания Ingram Micro) проводит аналогию между командой разработчиков и проблемным высоконагруженным приложением, чтобы разъяснить тимичным интровертам, как разобраться во взаимодействии людей. Специалист считает, что по аналогии с тем, как решаются проблемы в программном продукте, можно справиться с командными сложностями. И приведенные в докладе примеры — его личный опыт по решению вполне конкретных проблем.
В докладе разобран, например, такой типичный паттерн как перегруженный тимлид, который занимается мелкой текучкой и накапливает «технический долг» перед решаемой задачей. Для устранения этой проблемы по аналогии с балансировкой нагрузки в команде был выделен так называемый Exception man, задача которого — обслуживать все входящие обращения, защищая команду от внешних раздражителей. А чтобы расшарить в команде экспертизу, статус Exception man стал «переходящим» (каждый «дежурит» по неделе). Это принесло свои плоды и, кстати, вызвало немалый интерес аудитории, присутствовавшей на докладе.
Аналогичным образом Антон разобрал и другие типичные ситуации — перегрузку команды, которая срывает сроки, опять же, накапливает технический долг, предлагая вместо нормальных решений костыли; наличие людей с уникальными навыками, что ставит под угрозу решение задачи при больничных, отпусках и увольнениях; непрозрачные статусы разработки и т.п. По каждой ситуации предлагается аналогия из мира разработки и ее интерпретация в терминах команды. Также даются довольно очевидные, но не всегда применяемые советы, например, использование единого списка улучшений.
Дайджест очередной порции докладов будет готов у нас через пару дней. А пока хотим напомнить, что очередной этап обмена опытом по тимлидерству и руководству пройдет уже в начале февраля в рамках конференции TeamLeadConf 2018. Там будет порядка 40 докладов.
Кстати, на сайте конференции мы выложили видеозаписи десяти наиболее интересных прошлогодних выступлений.
Для этого обзора мы выбрали восемь наиболее популярных выступлений.
Выбранные выступления объединяет то, что участники изложили общие мысли о проблемах руководства технологическими командами через призму личного опыта, который, что важно, у каждого был свой. И поскольку докладчики работают в разных компаниях и над разными задачами, представленная подборка позволяет взглянуть на проблему с самых разных точек зрения.
Наши спикеры сходятся лишь в одном: технологическими командами должны руководить те, кто понимает, как это все работает, поэтому проще вырастить тимлида и руководителя более высокого уровня внутри команды, нежели нанимать администратора и обучать его технологиям.
Очень много было сказано о том, кто такой тимлид, каковы его основные обязанности и как ему решать те или иные административные задачи. В данном случае мы не претендуем на полноту изложения картины, а хотим порекомендовать видеозаписи лучших наших докладов для просмотра.
Обзор мы разбили на две части. В первой остановимся на докладах, посвященных переходу из инженера (разработчика) в тимлиды, а также на некоторых советах, касающихся ежедневной рутины. Во второй части пойдем дальше и обсудим развитие тимлида в руководителя более высокого уровня, а также посмотрим на команды разработчиков и их типичные проблемы под другим углом — через призму психологии.
Как стать тимлидом
Тезисы доклада
В первом докладе из нашего дайджеста Андрей Рыжкин (компания AGIMA) описывает собственноручно формализованную процедуру выращивания тимлидов внутри команды, попутно предостерегая разработчиков о том, что же изменится в их жизни, если они перейдут на «темную сторону», т.е. в руководители.
Как отмечают в своих докладах многие участники конференции, новоиспеченному тимлиду придется привыкнуть к тому, что времени на разработку и интересные задачи, связанные с какими-то исследованиями, у него уже не останется. Кроме того, придется выйти из комфортного потокового режима работы — как-то уживаться в мире с параллельными задачами, прилетающими одновременно по нескольким каналам, а также с большим количеством коммуникаций и планированием. В своем докладе Андрей Рыжкин дает некоторые советы, как справиться с непривычной ситуацией и не перегореть под давлением ответственности, а может и оставить себе задел на дальнейшее развитие (хотя по его данным 90% тимлидов так и останавливаются на этом уровне).
Доклад будет интересен не только сегодняшним разработчикам, метящим в тимлиды, но и руководителям, которые пытаются вырастить в коллективе себе замену. Им Андрей поможет ответить на вопросы: кого стоит взять в тимлиды? На какие качества надо обратить внимание? Стоит ли возлагать эти обязанности на самого лучшего разработчика в команде?
По опыту докладчика, чтобы прогнозировать вероятный успех персонажа в роли тимлида, ему достаточно обладать всего тремя качествами: эмпатией к команде, решительностью и технической компетенцией. Но все не так просто: на старте тимлиду нужна помощь, которую иногда можно обеспечить через правильные привычки внутри коллектива. Один из обсуждаемых примеров — так называемый «санитарный день» (а на самом деле — санитарные часы) — время, выделенное для написания отчетов и планирования. Практики, принятые в AGIMA и подробно описанные в докладе, подсказывают, с какой стороны вообще можно подступиться к решению проблем тимлида.
Естественно, рассмотрена и другая сторона вопроса — «косяки» неопытного тимлида, с которыми можно и нужно бороться (как один из примеров — любовь к закапыванию в длинных задачах). В ходе вопросов после доклада обсудили и процесс обучения остальной части команды, как правильно взаимодействовать с тимлидом.
В дополнение Андрей Рыжкин предложил список литературы, которая будет полезна будущему тимлиду. Эту ссылку вы еще встретите в презентации спикера, но мы решили вынести ее в наш анонс.
Goth2Boss: ломка и отходняки при переходе из инженера в тимлиды
Тезисы доклада
Следующий доклад — для состоявшихся тимлидов. Потенциального адепта «темной стороны» уже выявили в коллективе и бросили грудью на амбразуру (то есть формально или неформально поставили тимлидом). Но говорить о том, что он справился с ситуацией еще рано. И на этом этапе потребуется не только помощь коллектива и корпоративных привычек, описанных выше, но и саморазвитие специалиста. Об этом и рассказывает Артем Каличкин (ГК ЦФТ), опираясь на свой 11-летний опыт работы.
В форме тезисов Артем рассказывает, как «не потонуть» на новой должности: на какие стороны собственной личности стоит обратить внимание, что развивать, а от чего, наоборот, отказаться.
В докладе разобраны самые яркие «тараканы» начинающих тимлидов: выгораживание подчиненных от любых нападок извне команды — «материнский инстинкт», страдания при адаптации мозга инженера к административной работе, стремление принять лучшее решение из возможных — «синдром отличника», попытки делать всю работу подразделения самостоятельно. На каждом из перечисленных паттернов поведения докладчик подробно останавливается, описывая его сразу с нескольких сторон (почему это плохо для команды, компании и почему это плохо для самого тимлида) — чувствуется опыт на разных уровнях руководства.
Кстати, Артем считает, что практически сразу с момента перехода на должность тимлида специалист должен начинать растить себе заместителя. В помощь этому процессу он рассматривает три из выделенных им пяти этапов выращивания будущего руководителя: выявление, тестирование и начало пути. По сути это несколько иной взгляд на те же проблемы, что описаны в первом докладе нашего дайджеста. Для каждого из этапов предлагаются антипаттерны поведения и способы с ними справиться.
Все, что тимлид должен знать о найме и увольнении
Тезисы доклада
Следующий доклад переводит нас к теме ежедневных обязанностей тимлида. Несмотря на то, что кадрами в компаниях как бы занимается HR отдел, будущий непосредственный руководитель нового сотрудника должен участвовать в найме — в конце концов, ему потом руководить этим человеком. Степан Овчинников (компания Интерволга) дает выжимку полезной информации о том, куда смотреть и за что хвататься тимлиду, который включился в процесс сбора команды.
Представленный опыт был получен в компании с 60 сотрудниками (32 из которых — программисты), реализующей заказные проекты на Bitrix, что как бы ограничивает его применимость. Однако с определенными оговорками приведенные рекомендации можно использовать в самых разных ситуациях.
Докладчик прошелся по всем основным моментам работы с персоналом со стороны тимлида: найме, мотивации и даже увольнении (хоть это и считается в современном мире кощунством). Высказал рекомендации, что спрашивать на собеседовании, чтобы вскрыть мотивацию и выявить неадекват, предложил пути для поддержания уже нанятых сотрудников в состоянии повышенной мотивации, подсказал, как лучше уволить человека, чтобы не взбудоражить остальную команду.
Ценность доклада в том, что в нем даны вполне конкретные советы — что делать, чтобы собрать команду и не растерять ее. К примеру, Степан рекомендует периодически вести неформальные разговоры с коллегами, чтобы следить за их настроением и вовремя заметить назревающие проблемы. Еще одна полезная рекомендация — постоянно повышать сложность задач, чтобы избавить разработчиков от скуки. А если это по каким-то причинам невозможно (поменять технологии в большинстве компаний не так просто), сотруднику можно выделить время на профессиональный рост.
За остальными идеями советуем обратиться к докладу. Там все рекомендации дополнены весьма красочными примерами из жизни.
Кстати, и тут не обошлось без обсуждения типичных проблем начинающего тимлида, например, любви к глубокому погружению в любой вопрос или боязни увольнений своих подчиненных. Так что с точки зрения формирования образа тимлида доклад дополняет два предыдущих.
Команда как высоконагруженная система
Тезисы доклада
В своем докладе Антон Потапов (компания Ingram Micro) проводит аналогию между командой разработчиков и проблемным высоконагруженным приложением, чтобы разъяснить тимичным интровертам, как разобраться во взаимодействии людей. Специалист считает, что по аналогии с тем, как решаются проблемы в программном продукте, можно справиться с командными сложностями. И приведенные в докладе примеры — его личный опыт по решению вполне конкретных проблем.
В докладе разобран, например, такой типичный паттерн как перегруженный тимлид, который занимается мелкой текучкой и накапливает «технический долг» перед решаемой задачей. Для устранения этой проблемы по аналогии с балансировкой нагрузки в команде был выделен так называемый Exception man, задача которого — обслуживать все входящие обращения, защищая команду от внешних раздражителей. А чтобы расшарить в команде экспертизу, статус Exception man стал «переходящим» (каждый «дежурит» по неделе). Это принесло свои плоды и, кстати, вызвало немалый интерес аудитории, присутствовавшей на докладе.
Аналогичным образом Антон разобрал и другие типичные ситуации — перегрузку команды, которая срывает сроки, опять же, накапливает технический долг, предлагая вместо нормальных решений костыли; наличие людей с уникальными навыками, что ставит под угрозу решение задачи при больничных, отпусках и увольнениях; непрозрачные статусы разработки и т.п. По каждой ситуации предлагается аналогия из мира разработки и ее интерпретация в терминах команды. Также даются довольно очевидные, но не всегда применяемые советы, например, использование единого списка улучшений.
Дайджест очередной порции докладов будет готов у нас через пару дней. А пока хотим напомнить, что очередной этап обмена опытом по тимлидерству и руководству пройдет уже в начале февраля в рамках конференции TeamLeadConf 2018. Там будет порядка 40 докладов.
Кстати, на сайте конференции мы выложили видеозаписи десяти наиболее интересных прошлогодних выступлений.
