Продолжаем обзор самых популярных докладов HighLoad++ 2017 по тематике тимлидерства. В этой части мы расскажем о выступлениях для уже состоявшихся руководителей — в первую очередь о движении из тимлида на более высокие посты. Ну и немного поговорим о психологии.
Докладчики в предыдущей части уже предупреждали будущих тимлидов о том, что подъем по административной лестнице снижает долю «технической» и «творческой» составляющих в работе в пользу мелких задач по управлению. Однако спикеры из второй части нашего обзора утверждают, что дальше будет только хуже. Больше административных задач и ответственности, меньше времени на непосредственную работу. Но если душа к этому лежит, не стоит упускать свой шанс.
Тезисы доклада
Найти себе заместителя — первостепенная задача каждого руководителя. В своем докладе Виталий Шароватов (компания Badoo) говорит о выращивании тимлида, но не с точки зрения самого «испытуемого», а с позиции недавно назначенного руководителя, которому срочно надо искать в коллективе потенциальную замену.
Почему в коллективе? Потому что спикер, как и его коллеги из первой части нашего обзора, считает, что инженерами лучше руководит инженер. Однако на эту позицию может подойти не любой технарь, поскольку для успешного лидерства нужно «отращивать» административные навыки. Путь по карьерной лестнице в сторону управленца представляет собой лишь один из возможных вариантов развития специалиста, и он нужен не каждому.
Виталий представил интуитивно выработанный, но хорошо формализованный подход к выбору, назначению и последующему сопровождению тимлида в команде, который поэтапно отсеивает неподходящих кандидатов. Вчерашним разработчикам такой взгляд понравится. С другой стороны, его подход показался нам очень «человечным» — на каждом шаге присутствуют разъяснения, как все это сделать комфортно для окружающих людей. К примеру, рассматривается процесс назначения нового руководителя с точки зрения ожиданий вверенной ему команды, а также последующее введение специалиста в курс дела.
Подход, предложенный спикером, требует от руководителя довольно много времени на начальном этапе. Виталий считает, что начинающего тимлида стоит в буквальном смысле вести за руку, выстраивая вместе с ним процессы и разбирая возникающие сложности. Однако эти затраты прикрывают риски — чинить «сломанную» кривым руководством команду потом будет гораздо дороже.
Беседа наполнена практическими советами по всем аспектам пути новоиспеченного тимлида. Но, в отличие от докладов первой части, советы предназначены не для самого тимлида, а для его руководителя.
Одна из основных идей, которой спикер уделяет много внимания, создание подобия советской картотеки с регулярно обновляемой информацией о сотрудниках и даже внутренним скорингом. Попутно Виталий разобрал важные для тимлида человеческие качества, снабдив все это простыми жизненными примерами.
Все подробности в видеозаписи.
Тезисы доклада
Хотя инженерный бекграунд важен для руководителя разработчиков, в некоторых ситуациях он будет мешать эффективному управлению. В своем докладе Александр Трофимов и Дмитрий Мачехин (Лаборатория Касперского) рассказывают о том, какие «технарские» привычки будут мешать разработчику, только начинающему свой путь по административной лестнице.
Для наглядной иллюстрации навыков, необходимых для руководителя, Александр предложил присутствующим нарисовать картинку по его устному ТЗ. При просмотре доклада рекомендуем не пропускать эту часть, а попробовать поучаствовать. После того, как в презентации появится изображение того, чего же на самом деле хотел заказчик, ряд аспектов работы руководителя удастся в буквальном смысле прочувствовать на собственной шкуре.
Основная мысль доклада заключается в том, что став руководителем, специалист перестает отвечать напрямую за систему — он отвечает за людей, создающих ее. И в непривычной ситуации он может попасть в одну из нескольких стандартных «засад». В докладе речь пойдет о двух из них — тех, в которые попал спикер: о попытках делать работу за криворуких (по мнению новоиспеченного руководителя) подчиненных и о злоупотреблениях полномочиями, то есть стремлении переделать весь «монастырь» под свой «устав».
Главный посыл доклада заключается в том, что надо быть умеренным в своем желании все сделать по-своему как с точки зрения технологий, так и с других позиций (графика работы, детализации менеджмента). Людям надо доверять, учиться делегировать, а свои силы направить на более высокоуровневые задачи.
Несмотря на этот спойлер, рекомендуем все же посмотреть видео, так как абстрактный совет «не мелочиться» запоминается гораздо хуже, нежели цепочка ярких личных примеров с разбором результатов, полученных на реальной команде.
Кроме видео, мы также сделали полную расшифровку этого доклада.
Тезисы доклада
Доклад Романа Ивлиева (ivliev.info) — о том, как на самом деле выглядит работа технического директора (CTO) глазами человека, прошедшего все административные уровни, начиная от обычного технаря.
С нижних уровней карьерной лестницы иногда кажется, что CTO занимается непонятно чем, а ведь у него в руках столько хорошего: целая технологическая команда, которая может решать сложнейшие задачи и готова пойти за него и в огонь, «и в воду, и в воскресенье на работу» (по выражению самого спикера). Однако, как рассказывает Роман, к команде, возможности принимать свои решения и нести за них ответственность, «бонусом» идут множество сопутствующих дел — кадры, бюджет, бесконечные совещания с руководителями других подразделений, вопросы ЖКХ (куда и как посадить нового сотрудника) и самая страшная аббревиатура — ФОТ. Техническому директору приходится учиться объективно оценивать людей, следить за рынком, искать способы удержать хороших специалистов и решать кучу других вопросов.
Начав с такой «бочки дегтя», спикер рассказал про типичные «болезни» инженера на месте CTO. О том, какие качества лучше оставить в прошлом, а какие навыки, наоборот, подтянуть. О том, насколько тяжело бывает продвинуть техническую идею в компании через разговоры о сроках, рисках и бюджетах. И о том, что результатов работы CTO не видно, даже по сравнению с тимлидами (в докладах первой части обзора был разговор о том, что в отличие от рядового разработчика, тимлид не имеет возможности быстро оценить результат своих действий; и чем выше уровень — тем это ярче выражено). Зато ошибки технического директора видны почти сразу.
Весь рассказ наполнен очень жизненными примерами из собственной практики Романа.
В целом доклад лишний раз показывает, что с верхушки административной лестницы взгляд на технические проблемы совсем иной. Но так как это не руководство всей компанией, несмотря на то, что CTO видит множество факторов, он не всегда может оценить их влияние на ситуацию в целом.
Доклад будет полезен тем, кто движется вверх по административной ветви развития. Как отметил Роман, если руководитель хочет вернуться в программирование, делать это надо как можно быстрее, поскольку технологический стек меняется с невообразимой скоростью. И этот «взгляд изнутри» поможет лишний раз оценить специалистам, хотят ли они такого развития.
Тезисы доклада
Вместо заключения — небольшое погружение в психологию командной работы. Несмотря на хитрые методики кадрового отдела по оценкам психологической совместимости, тимбилдинг и прочие моменты, всегда есть что-то, что мешает команде развиваться. Доклад Александра Зиза (Алетейя Бизнес) повествует о том, какие типовые проблемы встречаются в 100% команд разработчиков (и не только).
Доклад Александра ценен тем, что несмотря на огромное количество теории по вопросам командного взаимодействия — корневые причины перечисленных проблем давно известны — фундаментально они не решены. Чтобы разобраться в этом бардаке, нужны практика и опыт. А заодно понимание, что именно активнее всего проявляется в ИТ.
Интересно, что российская прописка компании также добавляет своей специфики.
Однако не будем заниматься пересказом — за подробностями рекомендуем обратиться к видеозаписи доклада.
По ходу беседы специалист рекомендует литературу, ссылается на исследователей — в целом будет, что почитать. Например, «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте» (Эдвард Йордон) — про системный уровень работы с командой, хотя и эта книга многое оставляет за кадром.
Однако спикер предостерегает от самостоятельных действий. Для сохранения комфортной атмосферы работы все психологические беседы с сотрудниками он рекомендует вести со стороны — с помощью приглашенных консультантов. А что касается информации из доклада и литературы — они для целей саморефлексии.
Для тех, кто хочет не размышлять, а действовать, Александр предлагает пошаговую стратегию развития из пяти пунктов (в правой нижней части слайда):
Дублируем ссылку на опросник. Но прежде чем бросаться его распечатывать, посмотрите сам доклад.
Друзья, хотим напомнить, что очередной этап обмена опытом по тимлидерству и управлению пройдет уже в начале февраля в рамках конференции TeamLeadConf 2018. А на сайте конференции вы сможете найти видеозаписи десяти наиболее интересных прошлогодних выступлений.
Кстати, ещё можно впрыгнуть в уходящий поезд и подать доклад. Что сказать? У нас есть результаты мозгового штурма на эту тему.
Докладчики в предыдущей части уже предупреждали будущих тимлидов о том, что подъем по административной лестнице снижает долю «технической» и «творческой» составляющих в работе в пользу мелких задач по управлению. Однако спикеры из второй части нашего обзора утверждают, что дальше будет только хуже. Больше административных задач и ответственности, меньше времени на непосредственную работу. Но если душа к этому лежит, не стоит упускать свой шанс.
Как я был тимлидом, а теперь — руководитель направления
Тезисы доклада
Найти себе заместителя — первостепенная задача каждого руководителя. В своем докладе Виталий Шароватов (компания Badoo) говорит о выращивании тимлида, но не с точки зрения самого «испытуемого», а с позиции недавно назначенного руководителя, которому срочно надо искать в коллективе потенциальную замену.
Почему в коллективе? Потому что спикер, как и его коллеги из первой части нашего обзора, считает, что инженерами лучше руководит инженер. Однако на эту позицию может подойти не любой технарь, поскольку для успешного лидерства нужно «отращивать» административные навыки. Путь по карьерной лестнице в сторону управленца представляет собой лишь один из возможных вариантов развития специалиста, и он нужен не каждому.
Виталий представил интуитивно выработанный, но хорошо формализованный подход к выбору, назначению и последующему сопровождению тимлида в команде, который поэтапно отсеивает неподходящих кандидатов. Вчерашним разработчикам такой взгляд понравится. С другой стороны, его подход показался нам очень «человечным» — на каждом шаге присутствуют разъяснения, как все это сделать комфортно для окружающих людей. К примеру, рассматривается процесс назначения нового руководителя с точки зрения ожиданий вверенной ему команды, а также последующее введение специалиста в курс дела.
Подход, предложенный спикером, требует от руководителя довольно много времени на начальном этапе. Виталий считает, что начинающего тимлида стоит в буквальном смысле вести за руку, выстраивая вместе с ним процессы и разбирая возникающие сложности. Однако эти затраты прикрывают риски — чинить «сломанную» кривым руководством команду потом будет гораздо дороже.
Беседа наполнена практическими советами по всем аспектам пути новоиспеченного тимлида. Но, в отличие от докладов первой части, советы предназначены не для самого тимлида, а для его руководителя.
Одна из основных идей, которой спикер уделяет много внимания, создание подобия советской картотеки с регулярно обновляемой информацией о сотрудниках и даже внутренним скорингом. Попутно Виталий разобрал важные для тимлида человеческие качества, снабдив все это простыми жизненными примерами.
Все подробности в видеозаписи.
Как убить технаря в руководителе
Тезисы доклада
Хотя инженерный бекграунд важен для руководителя разработчиков, в некоторых ситуациях он будет мешать эффективному управлению. В своем докладе Александр Трофимов и Дмитрий Мачехин (Лаборатория Касперского) рассказывают о том, какие «технарские» привычки будут мешать разработчику, только начинающему свой путь по административной лестнице.
Для наглядной иллюстрации навыков, необходимых для руководителя, Александр предложил присутствующим нарисовать картинку по его устному ТЗ. При просмотре доклада рекомендуем не пропускать эту часть, а попробовать поучаствовать. После того, как в презентации появится изображение того, чего же на самом деле хотел заказчик, ряд аспектов работы руководителя удастся в буквальном смысле прочувствовать на собственной шкуре.
Основная мысль доклада заключается в том, что став руководителем, специалист перестает отвечать напрямую за систему — он отвечает за людей, создающих ее. И в непривычной ситуации он может попасть в одну из нескольких стандартных «засад». В докладе речь пойдет о двух из них — тех, в которые попал спикер: о попытках делать работу за криворуких (по мнению новоиспеченного руководителя) подчиненных и о злоупотреблениях полномочиями, то есть стремлении переделать весь «монастырь» под свой «устав».
Главный посыл доклада заключается в том, что надо быть умеренным в своем желании все сделать по-своему как с точки зрения технологий, так и с других позиций (графика работы, детализации менеджмента). Людям надо доверять, учиться делегировать, а свои силы направить на более высокоуровневые задачи.
Несмотря на этот спойлер, рекомендуем все же посмотреть видео, так как абстрактный совет «не мелочиться» запоминается гораздо хуже, нежели цепочка ярких личных примеров с разбором результатов, полученных на реальной команде.
Кроме видео, мы также сделали полную расшифровку этого доклада.
СТО: мечты сбываются?
Тезисы доклада
Доклад Романа Ивлиева (ivliev.info) — о том, как на самом деле выглядит работа технического директора (CTO) глазами человека, прошедшего все административные уровни, начиная от обычного технаря.
С нижних уровней карьерной лестницы иногда кажется, что CTO занимается непонятно чем, а ведь у него в руках столько хорошего: целая технологическая команда, которая может решать сложнейшие задачи и готова пойти за него и в огонь, «и в воду, и в воскресенье на работу» (по выражению самого спикера). Однако, как рассказывает Роман, к команде, возможности принимать свои решения и нести за них ответственность, «бонусом» идут множество сопутствующих дел — кадры, бюджет, бесконечные совещания с руководителями других подразделений, вопросы ЖКХ (куда и как посадить нового сотрудника) и самая страшная аббревиатура — ФОТ. Техническому директору приходится учиться объективно оценивать людей, следить за рынком, искать способы удержать хороших специалистов и решать кучу других вопросов.
Начав с такой «бочки дегтя», спикер рассказал про типичные «болезни» инженера на месте CTO. О том, какие качества лучше оставить в прошлом, а какие навыки, наоборот, подтянуть. О том, насколько тяжело бывает продвинуть техническую идею в компании через разговоры о сроках, рисках и бюджетах. И о том, что результатов работы CTO не видно, даже по сравнению с тимлидами (в докладах первой части обзора был разговор о том, что в отличие от рядового разработчика, тимлид не имеет возможности быстро оценить результат своих действий; и чем выше уровень — тем это ярче выражено). Зато ошибки технического директора видны почти сразу.
Весь рассказ наполнен очень жизненными примерами из собственной практики Романа.
В целом доклад лишний раз показывает, что с верхушки административной лестницы взгляд на технические проблемы совсем иной. Но так как это не руководство всей компанией, несмотря на то, что CTO видит множество факторов, он не всегда может оценить их влияние на ситуацию в целом.
Доклад будет полезен тем, кто движется вверх по административной ветви развития. Как отметил Роман, если руководитель хочет вернуться в программирование, делать это надо как можно быстрее, поскольку технологический стек меняется с невообразимой скоростью. И этот «взгляд изнутри» поможет лишний раз оценить специалистам, хотят ли они такого развития.
Сопротивление в работе команды и его «симпатичные» сценарии, приводящие развитие команды в тупик
Тезисы доклада
Вместо заключения — небольшое погружение в психологию командной работы. Несмотря на хитрые методики кадрового отдела по оценкам психологической совместимости, тимбилдинг и прочие моменты, всегда есть что-то, что мешает команде развиваться. Доклад Александра Зиза (Алетейя Бизнес) повествует о том, какие типовые проблемы встречаются в 100% команд разработчиков (и не только).
Доклад Александра ценен тем, что несмотря на огромное количество теории по вопросам командного взаимодействия — корневые причины перечисленных проблем давно известны — фундаментально они не решены. Чтобы разобраться в этом бардаке, нужны практика и опыт. А заодно понимание, что именно активнее всего проявляется в ИТ.
Интересно, что российская прописка компании также добавляет своей специфики.
Однако не будем заниматься пересказом — за подробностями рекомендуем обратиться к видеозаписи доклада.
По ходу беседы специалист рекомендует литературу, ссылается на исследователей — в целом будет, что почитать. Например, «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте» (Эдвард Йордон) — про системный уровень работы с командой, хотя и эта книга многое оставляет за кадром.
Однако спикер предостерегает от самостоятельных действий. Для сохранения комфортной атмосферы работы все психологические беседы с сотрудниками он рекомендует вести со стороны — с помощью приглашенных консультантов. А что касается информации из доклада и литературы — они для целей саморефлексии.
Для тех, кто хочет не размышлять, а действовать, Александр предлагает пошаговую стратегию развития из пяти пунктов (в правой нижней части слайда):
Дублируем ссылку на опросник. Но прежде чем бросаться его распечатывать, посмотрите сам доклад.
Друзья, хотим напомнить, что очередной этап обмена опытом по тимлидерству и управлению пройдет уже в начале февраля в рамках конференции TeamLeadConf 2018. А на сайте конференции вы сможете найти видеозаписи десяти наиболее интересных прошлогодних выступлений.
Кстати, ещё можно впрыгнуть в уходящий поезд и подать доклад. Что сказать? У нас есть результаты мозгового штурма на эту тему.
samizdam
Спасибо за подборку, но хотелось бы больше текстовых расшифровок докладов.
А то видео-ассорти какое-то получается вместо публикации.
Ну и по одной из ссылок из статьи такой вот "огонь":