Начнем рассказ о тимлидах и для тимлидов с проблем, болей, вопросов, которые могут возникнуть в больших и небольших ИТ-компаниях. Ведь, если мы не можем сформулировать задачи, то как же мы станем их решать.
- Нужен ли вообще тимлид?
- Что есть тимлид, какие у него задачи?
- Что сначала: команда или тимлид?
- Необходимы ли тимлиду технический навыки?
- Вырастить или нанять?
- Как понять, можно ли и нужно ли выращивать из инженера тимлида?
- Сколько времени нужно, чтобы вырастить тимлида?
- Менеджерские роли тимлида, какая роль предпочтительней?
- Насколько важны эмоциональный интеллект и социальные навыки?
- Что делать если руководитель сам является техническим специалистом и падок на микроменеджмент?
- Тимлид ушел на неопределенное время (отпуск, больничный, форс-мажор), что делать?
- Что делать, если тимлид уходит насовсем?
- Какое должно быть соотношение менеджмента и разработки в работе тимлида?
- Есть ли путь назад (и вперед)?
- Какие перспективы карьеры тимлида?
- Что может помешать стать тимлидом?
- В чем разница между тимлидом и техлидом?
- Как выявить неэффективного тимлида на ранней стадии?
- Как начинающему тимлиду справиться с потоком информации?
- Нужен формальный или неформальный лидер?
- Junior и Senior тимлид, в чем различия и как держать их в одной команде?
Такой поток запросов выдали участники TeamLead Conf на круглый стол. Если вы уже сталкивались с какими-то из них, то, вероятно, и остальные могут вас настигнуть, есть, о чем подумать.
Под катом — обзор лучших докладов TeamLead Conf с видеозаписями и презентациями.
Анатолий Стояновский (PricewaterhouseCoopers), Георгий Могелашвили (Booking.com) и Роман Павлушко (Avito) с помощью Александра Зиза попытались за час найти столько ответов, сколько успели.
Круглый стол на то и круглый стол, что это своего рода импровизация и четкой структуры у него нет. Но мы все же постараемся выделить из этого обсуждения самые важные мыcли.
Естественно, само понятие тимлида в разных компаниях как правило разное. Первым делом нужно определить, какие именно у него цели в вашем случае. Роман назвал два самых распространенных типа: про компетенцию или про процесс разработки в целом.
Тимлид первого типа в случае религиозной войны о выборе новой технологии, имея максимальную компетенцию, имеет возможность вставить свое веское слово и направить всю команду. Во втором случае целью является time-to-market, то есть полная организация процесса, чтобы максимально быстро, качественно, прозрачно решение задачи дошло до пользователя.
Серьезно обсудили вопрос необходимости технического бэкграунда для тимлида. Георгий рассказал, что в booking.com это не обязательно — тимлидом может стать дизайнер, копирайтер, QA и пока это работает хорошо. Какое-то время такой тимлид будет посвящать управленческим задачам, а какое-то своей изначальной работе. Анатолий возразил, что инженеры смогут манипулировать не специалистом в их предметной области, хотя в целом, в зависимости от конкретного производственного процесса, если такой человек способен осуществлять «подстрочный перевод» и отвечать за качество выполняемой работы всей команды, то это возможно.
Результаты работы круглого стола широко обсуждались в нашем telegram-чатике под названием «Боль тимлида», сейчас чат работает как экспертное сообщество тимлидов. Подключайтесь!
Роман же заметил, что может быть это возможно в очень зрелых командах, и что он еще ни разу не видел тимлида без сильного понимания хотя бы одной из областей разработки, который не мог бы в голове разложить весь процесс, включая архитектуру, сроки, качество и пр.
Какие нужны soft skills и как их развивать обсудим более детально дальше, но, если коротко, то они очень важны.
С другой стороны, по мнению Анатолия, и остальные с ним согласились, тимлид должен по крайней мере в долгосрочном режиме поддерживать знание своей предметной области. Это может быть кодинг, какие-то собственные проекты, смены роли время от времени и так далее, но это очень важно. Мы живем в индустрии, где за пару лет ничего неделания, можно превратиться из специалиста, а пустое место, а кодить — это относительно простой способ все-таки сохранять свою компетенцию.
Но! Цель у руководителя должна быть — не кодить, он должен стараться все делать чужими руками. Даже прозвучал такой сильный тезис:
Делегируй или умри.
Вопрос, что делать если вышестоящий руководитель сам такой сильный технический специалист, хочет навязывать своё мнение и падок на микроменеджмент, в целом привел к такому неожиданному изречению Романа:
Мироменджмент — это плохо, микросервисы — это хорошо.
Конкретных механизмов выявления тимлида наши эксперты не дали. В основном приходится надеяться, что найдется человек, который будет активнее других вовлекаться в процесс и активнее других давать фидбэк, и возможно возьмет на себя некую дополнительную ответственность. В booking.com для таких работников предусмотрен испытательный срок для проверки способностей и желания.
В Avito была практика «тимлид в кредит» для наиболее компетентных специалистов, которые могли бы обучать команду и за которыми тянулись как за техническими лидерами. Но, к сожалению, было несколько случаев очень быстрого выгорания и от этого отказались.
Из этого можно сделать вывод для тех, кто хотел бы вырасти в тимлида — сначала делай, потом тебя увидят. То есть, не надо ждать пока тебе четко сформулируют и попросят решить проблему, начни сам их замечать.
В итоге, став тимлидом, нужно добиться того, чтобы команда работала и без вас условно месяц. Если могут больше, то тимлид уже не нужен, меньше — организация еще не идеальная. Традиционный совет думать о том, кто будет вашим приемником, желательно сразу в двух вариантах, тоже прозвучал.
А дальше несколько докладов, с видео, но и с аннотацией, чтобы вам быстро сориентироваться и посмотреть наиболее для вас актуальные.
Как строить свой профессиональный путь
Максим Цепков представил целых два доклада. Сейчас рассмотрим схемы самоопределения, необходимые для того, чтобы успешно строить свой профессиональный путь, а презентацию второго можно найти на сайте самого автора. Чтобы не углубляться в философствования, все рассуждения пойдут в метафоре человека, который плывет в потоке жизни и в процессе подгребает, чтобы попасть, куда надо. Причем, не самоопределяться, а спокойно плыть по потоку в такой трактовке — это тоже самоопределение.
Живя в эпоху перемен задача самоопределения возникает достаточно часто, в общем и целом, с каждым новым проектом. А когда что-то надо делать регулярно мы, понятно дело, стремимся автоматизировать процесс и сделать его технологичным. Собственно про схемы, которые можно для этого использовать и был доклад. Речь пойдет, конечно, о профессиональной составляющей и самоопределении в компании, которое на разном уровне понимается по-разному: от освоиться и разобраться в новом незнакомом месте до осознать общие ценности и вместе начать делать общие дела и так далее.
Первым делом нужно нарисовать образ будущего, но обязательно в этом самом прекрасном будущем представить самого себя что-то делающего и действующего, иначе это чье-то чужое будущее. Это не просто, но участникам конференции предлагалось за 90 секунд хотя бы попробовать — попробуйте и вы. Есть куча книг о том, что с этим образом потом делать, и Максим предлагает свое видение: как бы подвешивать свои созданные образы и следить, а когда мире открываются возможности туда сделать шаг, а они обычно, что интересно, открываются, тогда и идти. Такой подход сродни предпринимательской бдительности, которая в ключе самоопределения используется редко.
А дальше следует гораздо более трудный шаг по представлению себя в кооперации с тем, что будет вас окружать, и поиск ответов на вопросы: что надо делать, что делаете вы, что отдадите другим, что от вас требуется. Схема из презентации, возможно, поможет вам осознать свое развитие, потому что совершенно наверняка ваш профиль не будет полностью совпадать с тем, что требуется.
Кстати, Максим великолепно протоколировал всю конференцию в facebook и сделал выжимку на своем сайте. Мы ему очень за это благодарны и хотим процитировать хотя бы начало:
Два дня, 08-09.02.2018 был на новой конференции Олега Бунина для тимлидов TeamLead Conf. 474 участника, и два трека очень хороших докладов. Очень высокий уровень по содержанию, по подготовке докладов, по компоновке программы. Я был на многих конференциях, достаточно много знаю в IT, так что ситуация, когда доклады в каждом слоте несут ценную для меня информацию, вызывают размышления — редкость. Тут было именно так. И, надеюсь, дальше будет не хуже. Потому что путь от разработчика к тимлиду — это актуальная тема. Я, кстати, специально не пишу «руководитель команды», потому что современный тимлид — он не классический руководитель. И вообще тимлиды — они очень разные, прежде всего потому, что компании — разные, у них очень разное распределение ответственности и обязанностей между сотрудниками, и, как следствие, очень разные тимлиды. И это разнообразие было в полной мере представлено на конференции.
Улучшая performance review
Нельзя обойти стороной доклад Егора Толстого о том, как в Avito устроен performance review, какие конкретные практики используются, каковы результаты анализа многих тысяч полученных оценок, но не только. Конечно, в нем не будет универсального фреймворка, который подойдет любой компании с любой структурой и задачами.
Основная ценность рассказа в том, как постепенно, небольшими шагами, основываясь на собранных данных и обратной связи улучшался процесс performance review. Ведь практика continuous improvement может быть применена не только к людям, не только к технологиям, а к любому процессу и это очень важно.
Нет оснований, чтоб не поверить Егору, что инструмент измерения продуктивности сотрудника правильно называть именно performance review, и что в его применении заинтересованы сразу три стороны: сотрудник, менеджер и вся компания. На этом прекратим пересказ и дадим вам посмотреть выступление.
Кстати, Егор ведет telegram-канал (https://t.me/leadgr), в котором приводит самые интересные статьи, видео и новости, связанные с техническим менеджментом (обещает не больше трёх материалов в день).
Управление большой распределенной командой
В своем докладе Алексей Катаев из Skyeng в первую очередь говорит об особенностях, связанных с тем, что сотрудники не просто редко ходят в офис, или сидят в зданиях через дорогу, но и живут в разных городах. Несмотря на то, что в выступлении присутствовал некийевангелизм удаленной работы, большинство приемов вполне универсальны и также эффективны при работе в едином офисе.
По мнению Алексея, основные преимущества организации удаленной команды в эффективности коммуникаций (а они часто занимают больше времени, чем непосредственно написание кода), доступ к большому пулу высококвалифицированных разработчиков, и хорошая возможность их удержать, поскольку предложений удаленной работы не так много. Надо заметить, что раз 87% сотрудников Skyeng в восторге от такого формата, то и для разработчиков есть немалые преимущества.
Остановимся на некоторых пунктах поподробнее. Сотрудничество как правило начинается с собеседования и несмотря на то, что проводя видео-собеседование вы не можете пожать человеку руку, вы можете посмотреть на него, причем в комфортной для него обстановке. А сохранившаяся запись позволит вам: при необходимостипосоветоваться с коллегами, не проводить повторного собеседования при найме в другую команду, проанализировать собеседование в случае увольнения сотрудника, и выявить ошибки, которые нужно в дальнейшем избежать, провести обзор 360 собеседующих, что тоже может оказаться очень полезным.
Наверное, вопрос номер один к организаторам распределенных команд это, как контролировать сотрудников, ведь они у себя дома будут смотреть ютубчик и никто кодить не будет. Хм, как будто в офисах поголовно закрыт доступ к котикам. Что ж, ответ Алексея — никак. В Skyeng стараются обеспечить прозрачность работы сотрудников, и пришли к тому, что нужно вести ежедневный worklog. Актуальные статусы, remaining estimates и бэклог тоже направлены на это и не являются чем-то важным исключительно в удаленном формате.
Второй часто встречающийся тезис: специалисты на удаленке сидят каждый у себя дома и просто делают задания в Jira и у них нет никакой общности, а вот в офисе — непременно команда. Алексей возражает, и нельзя с ним не согласится, что в первую очередь вовлеченность обеспечивает общение. Поэтому общения у них много и в различных форматах. Используя Hangouts (обязательно с камерой — никаких говорящих смайликов) проводят: ежедневные встречи, планирование и ретроспективы, вимбоксинги и квартальные презентации. А недавняя практика еще и чемпионат по СS — отлично развивает командный дух вне зависимости от типа компании.
Все виды общения вместе с тем, что каждый ticket формулируется, начиная с проблемы, которую он решает, чтобы разработчик сразу понимал, для чего он это делает и какую именно пользовательскую проблему он решает (тоже вполне себе общеприменимая scrum-практика), позволяет всем быть примерно в курсе всего, что нужно.
И когда в воздухе уже повис вопрос, когда вы там вообще работаете, вы похоже только и делаете, что разговариваете, Алексей, во-первых, привел наглядный пример собственного распределения времени, в котором общение в среднем занимает чуть более часа в день, зато это точно выделенное время, к которому не добавляются бесконечные уточнения соседа по столу и разговоры на кухне.
Во-вторых, заметил, что общение в слаке — это дешево, а живое общение — дорого. Конечно, онлайн сам по себе не гарантирует, что ваше общение станет эффективным, но свод правил, включая четкая структуру каналов по принципу «любое ваше сообщение должны прочитать только те люди, которым оно важно» и другие пункты конвенции сделают его таковым.
Ниже слайд с рекомендациями — эти инструменты могут пригодиться и вам.
Делегаты от команды Plesk, которые аж вчетвером приехали на конференцию, в своем обзоре охарактеризовали доклад Алексея, как потрясающий по концентрации информации. А вот, что они написали про конференцию в целом:
В начале февраля в Москве прошла конференция Teamlead Conf 2018. Событие, можно сказать, знаковое — произошло осознание того, что проблемы твоей должности вполне достойны не только локальных митапов или треков, но и самостоятельной большой конференции.
Конференция получилась интересной, в первую очередь, благодаря отличному контенту. Надо отдать должное организаторам: собрать нужную аудиторию и нужных докладчиков у них явно получилось.
Данную конференцию однозначно хочется отнести к категории, когда возвращаешься на работу и разбираешь по кирпичикам, переосмысливаешь услышанные доклады, готов пробовать новые идеи, экспериментировать и улучшать процессы разработки. Цель «получить опыт и вдохновение» достигнута на 100%.
Развиваемся по-имперски
Матрица компетентности, конечно, может восприниматься сотрудниками как критический инструмент для подавления, один из многих документов, который надо поскорее и как попало заполнить и забыть. В Лазада хотели же использовать его так, чтобы ни у кого не было ощущения, что это инструмент для подавления, а чтобы просто помочь хорошим людям саморазвиваться.
Техно-хаб в Москве появился два с половиной года назад и очень быстро стал расти, приходило много новых людей, которым нужно было сплотиться и стать единым коллективом — использование матрицы компетентности отчасти было направлено и на решение этой задачи.
Нина Щеглова в своем докладе рассказала, какие именно навыки были включены в матрицу для тимлида, почему там только soft skills, и каковы правила игры. Чтобы было понятнее, рассмотрим пример: гибкое входит в категорию «Анализ и принятия решений».
Первый уровень владения характеризуется тем, что человек просто способен посмотреть на проблему с другой стороны, когда вы еще только junior тимлид для вас это большой шаг. Находясь на втором уровне развития, он способен изменить собственную точку зрения при наличии аргументов и он очень любопытный. Тимлид с третьим, высшим, уровнем гибкого невероятно любопытен, очень легко жонглирует идеями, комбинирует их, меняет точки зрения и так далее.
Полученная матрица служит для того, чтобы наметить план развития выбрав области в которых было бы интересно и полезно развиваться дальше. Чтобы был фокус и действительно развитие Нина рекомендует выбирать только три области на несколько месяцев. С одно стороны, не возбраняется, через какое-то время поменять вектор развития, с другой — помогает обосновать проведение кое-какого корпоративного обучения. Так, например, из чрезвычайно стильных слайдов Нины нетрудно догадаться, что джедайские техники в Лазада уже освоили.
Конечно, никто не отрицает субъективности данного инструмента, но в конкретном примере он показал себя хорошо и справился со своими задачами. Вы можете попробовать использовать его в своей работе, дополнив и кастомизировав под себя и свои задачи:
В комментариях к посту Максима Цепкова об этом докладе возникла некоторая полемика вокруг содержания матрицы, а еще — обсуждение разницы soft skill и hard skill менеджера, которое нам кажется уместным привести.
Ekaterina Semenova: Hard skills менеджера мы целенаправленно не расписывали — они очень отличаются даже в рамках одной компании. Где-то много-много специфичных инструментов, а где-то — макросы и программирование в Экселе.
Максим Цепков: Екатерина, мне кажется, Вы hard skill менеджера понимаете в IT-смысле — как владение определенными IT-инструментами. А я их понимаю по-другому, а именно, как профессиональные скилы менеджера. Они ведь есть. То есть деление на soft skill и hard skill не по тому, используются ли какие-то технические средства, а потому, что hard skill связаны с профессией (дисциплиной), а soft skill — от нее не зависят. Менеджер — это профессия, а менеджмент дисциплина и у нее есть свой набор hard skill, которым учат, обучая менеджменту.
Ekaterina Semenova: Теперь я поняла о чем Вы. С такой трактовкой понятий получается довольно интересно. С одной стороны, у тимлида должны быть hard skills команды (программирование/ тестирование). И возможно Вы правы, когда разработчик переходит в тимлиды — его скилл, например, коммуникации становится hard skill’ом.
Максим Цепков: Там тонко. Возьмем аналитика. У него есть soft skill коммуникации и умение писать тексты, и есть hard skill проведения интервью (с фиксацией результата), в котором коммуникация и написание текстов — важная составная часть. Наверное, что-то аналогичное и здесь.
Ekaterina Semenova: Ага. И прокачать можно видимо оба скилла.
1000 и 1 фидбэк
Рассказ Евгении Голевой из Lamoda был адресован в особенности тем, кто собирается учить тимлидов навыку фидбэка, но, на самом деле, был полезен всем. Даже те, кто уверенно поднял руку в ответ на вопрос о том, кто сам дает фидбэк, наверняка нашли для себя полезные советы.
Сам факт того, что обратная связь нужна и важна не обсуждался — не случайные же люди собрались, все всё сами понимают. Как и то, что среднестатистический инженер часто критикует, редко хвалит и судит не разобравшись. А это не совсем то, чего нам бы хотелось, потому что не очень-то этот фидбэк мотивирует людей, а наоборот способствует возникновению конфликтов.
Отсутствие позитивных отзывов трактуется как будто человека не ценят, и он норовит покинуть компанию.
Самый очевидный способ решения, который приходит на ум, это тренинги. Такие тренинги есть, в Lamoda их много перепробовали и даже изобрели свою модель обратной связи, которую назвали SAME (Situation, Action, Message, Expectation).
Но Евгения придумала завернуть эту задачу в проект клуба, который, в отличие от тренинга, был бы по желанию, а не в качестве обязаловки. Во-вторых, клуб — это мероприятие, на которое люди ходят регулярно и длительно, то есть можно прокачивать разные навыки постепенно. Таким проектом стал клуб спикеров, организованный с подачи сотрудников компании, которые сами захотели научиться публично выступать. А внутри этого клуба спикеров была часть про то, как давать друг другу фидбэк таким образом, чтобы это было полезно.
С самого начала участники на своем примере осознали, что, когда ты готовился к выступлению, а в итоге нет ни вопросов, ни комментариев, ни возражений — это плохо, это неприятно.
Тем не менее, некоторые сопротивлялись, сама мысль, что фидбэком не бьют, что он необходим для развития, в нашей культуре не очень привычна. И нужно время, чтобы привыкнуть к тому что фидбэк может быть полезным и с ним можно взаимодействовать и вообще-то, когда тебе дают фидбэк правильно — это очень приятно и здорово.
По ходу дела сформировалось несколько правил, которые можно взять на вооружение. Одно из них велит всегда находить три плюса, но не для того, чтоб подсластить горькую пилюлю. Самое главное для чего нужен позитивный фидбэк, как ни странно, для собственного развития, потому что, чтобы учиться у других, надо уметь смотреть на работу коллег и замечать какие-то вещи, которые тебе самому не приходили в голову, запоминать, а потом использовать.
С другой стороны, получая обратную связь, все мы зачастую пропускаем мимо ушей плюсы, но, как только нам указали на какой-то недостаток, мы берем огромную лупу и внимательно его разглядываем. Поэтому умение правильно принимать отзывы и не реагировать каждый раз, как на истину в последней инстанции, тоже нужно тренировать.
А правило трех тарелочек, по сути, то же, что и в плане развития по матрице компетентности — не надо пытаться сразу исправить все, что только можно, для начала, выбери три зоны для развития
Одним словом, клуб получился эффективнее тренингов, его участники не только научились давать и принимать обратную связь, но и своим примером постепенно заряжают коллег вокруг.
А в качестве небольшого отступления, расскажем, что Евгения в Lamoda служит devrel’ом и является очень активной участницей нашей новой серии мероприятий DevRel Conf. Обсуждаем, кто это вообще такие, какие у них задачи, как их решать и многое другое. Уже провели три встречи, видео с которых есть на сайте, и не собираемся останавливаться.
Завершая этот разноплановый обзор, во-первых, хотим упомянуть Management Channel, плейлисты Aletheia Business (конференция по применению психологии в управлении и бизнесе) и Whale Rider (конференция по управлению и предпринимательству), в которых видео более ранних управленческих докладов, которые тоже могу отказаться полезными, и обратить внимание, что презентации всех докладов прошедшей TeamLead Conf, в отличие от самих выступлений, доступны всем желающим.
А во-вторых, напомнить, что конференции — это совсем не только доклады. Это живое общение, возможность: спросить, уточнить, познакомится, поделиться, найти соратников и многое другое. Тем более в такой тонкой теме, по которой гуглить не перегуглить, а решается все равно все методом проб и ошибок. В доказательство того, что мероприятие наше получилось в этом смысле очень успешным, под спойлером кое-какие фотографии.
Несмотря на все усилия докладчиков, не похоже, чтоб тема себя исчерпала. Доклады про команды и управление будут и на ближайшем РИТ++ и, вероятно, на сибирском Highload++.
Например, в списке заявок на Whale Rider есть:Никита Быков из Kodix Automotive с докладом «Тимлиды: бойцы или командиры?» и
Владимир Толоконников (SkyDNS / SafeDNS) с докладом «Нам нужен проджект! или Как жить, если ты теперь ПМ?».
На Aletheia Business темы поближе к психологии в управлении, например, среди заявок:
Георгий Могелашвили с темой «Game of Roles: как мы играючи решили проблему роста сотрудников в Booking.com» и
Вячеслав Злобин обещает рассказать, как обучать «лиц, принимающих решения».
Формулируйте собственные задачи, смотрите заявки и приходите участвовать. Причем, рекомендуем не откладывать решение на последний момент и ознакомиться с билетным предложением, потому что рост цен уже запущен.
Автор: e_finkel
