Рассмотрим задачу. Дано: технический специалист на позиции синьора с широким набором технических навыков. Напишите функцию, на вход которой подается разработчик, а на выходе получается тимлид. Дополнительные условия задачи: тимлид должен быть лидером, независимо от того экстраверт он или интроверт; соответствовать трем критериям хорошего управленца; отличаться от технаря, как минимум, по четырем параметрам; не должен совершать распространенных ошибок руководителя.
«Что за странная задача, какая функция? Просто берем синьора, назначаем тимлидом и готово!» Но мы знаем, что когда хорошего технического специалиста пытаются перевести в касту менеджеров, чаще теряют хорошего технаря и приобретают плохого менеджера. Все потому, что тимлид это именно менеджер: ему нужно управлять людьми, организовывать командную работу и решать самые разные проблемы. Здесь нужен набор навыков руководителя и новые шаблоны поведения, а технические скилы часто мешают.
Чтобы разобраться в задаче трансформации технического специалиста в руководителя, нам нужен человек, который знает о тимлидах практически все — это Дмитрий Смирягин. Дмитрий 20 лет в разработке ПО, из них 15 лет руководил группами архитектуры, разработки и внедрения продуктовых решений для 20th Century Fox, Wells Fargo Bank, Zurich Insurance, BoA и подразделениями производства ПО полного цикла, от аналитики до поддержки решений. Работал разработчиком, тимлидом и руководителем тимлидов, а сейчас обучает последние две группы и консультирует по вопросам IT-управления. Это идеальный опыт, чтобы решить нашу задачу — приступим.
Как переходят в тимлиды
Обычно в компаниях есть некоторая карьерная лестница. Сотрудник начинает с джуниора, переходит в мидлы, профессиональные скилы растут, и он становится синьором. Возникает вопрос «Куда дальше расти?» Частый ответ на него — стать тимлидом. Причем обычно на вопрос отвечают не сами сотрудники, а руководство выше.
Дорасти до тимлида — это стандартный карьерный путь.
Вроде бы это очередной шаг по карьерной лестнице, но разница между разработчиком-синьором и тимлидом принципиальна. Раньше сотрудник был техническим специалистом и решал технические вопросы, используя свои компетенции. Тимлиду требуются совершенно другие способности. Фактически, разработчик не поднимается на следующую ступень, а переходит на другую лестницу.
Цель работы тимлида
Вы стали руководителем, теперь у вас новые задачи и цели. Что изменилось? Когда вы были техническим специалистом, ваша основная цель была получать какой-то результат: код, документы, тесты. Когда вы перешли в тимлиды, изменился только один параметр — как достигается результат.
Цель руководителя такая же, как и у исполнителя — добиваться результата, но чужими руками.
Тимлид, который поднялся с технического уровня, может использовать свои технические компетенции, как один из ресурсов. Но это не единственный ресурс, а лишь один из множества.
В одной из команд, которой я руководил, работал тимлид. Как технический специалист он был на голову выше всей команды. Но мне пришлось его заменить на человека, у которого меньше технических скилов, но больше управленческих. Потому что мне нужна предсказуемость результатов, когда команда загружена, хорошо организована и выдает результат.
Типы лидерства
Как мы представляем лидера? Вот он идет впереди: харизматичный и вдохновляющий он знает цель и ведет за собой. Это яркий человек, который горит и умеет зарядить свою команду идеями, а команда их воспринимает. Лидер питается энергетикой от команды, а команда получает энергию от такого лидера.
Харизматичный лидер.
Во многих учебниках по лидерству описывается именно такой тип харизматичного лидера — это человек, который идет впереди и ведет за собой. Но, что случится, если сзади подкрадется волк и кого-то укусит? Увидит ли такой лидер, что произошло? Если он идет впереди, то нет.
Бывает и другой тип лидера, который находится позади команды. Он не такой яркий и впечатляющий, но зато он на коне, поэтому хорошо контролирует то, что происходит и быстро реагирует на любую ситуацию. Любому руководителю дают коня, как дополнительный инструмент, чтобы решать проблемы. В этом типе лидерства человек видит всё — никакой волк не сможет подкрасться сзади и утащить кого-нибудь.
Лидер-пастух.
На вопрос, какой из типов лидерства лучше, ответа нет. У каждого типа свои плюсы и минусы. Если руководитель обладает такой харизмой, которая вдохновляет и ведет за собой воодушевленную команду, он может позволить обращать чуть меньше внимания на то, что происходит внутри. Лидер ведет за собой, и команда следует за магнитизмом его личности. Здесь подойдет тип харизматичного лидерства. Такие люди чаще всего экстраверты.
Второй тип подходит интровертам. Это не менее, а иногда и более эффективное управление с позиции чуть сзади или сбоку.
Каждый руководитель выбирает тип управления сам, исходя из своего опыта и предрасположенности.
Критерии хорошего тимлида
Результат. Это первое, что ожидается от руководителя. Очевидно, что если нет результата, нет смысла в лидере. Результат — это получение кода в заданные сроки, в выделенный бюджет и предсказуемо. Поэтому сюда же относится предсказуемость результата и бюджет.
Стабильная команда. Именно команда создает результат. Но она не только инструмент для получения результата. Команда самоценна для организации, как «автономная боевая единица». Стабильная качественная команда не менее важна, чем результат деятельности.
Свободное время. Об этом часто забывают. Иногда тимлид как-то получает результат и формирует относительно хорошую команду, но при этом работает сутками. Это плохо, потому что от работы нужно получать еще и удовольствие и оставлять свободное время для саморазвития. Время на изучение чего-то нового важно, чтобы не потеряться в новых технологиях и вовремя отвечать на совершенно непредсказуемые вызовы.
Свободное время спасает от эмоционального и профессионального выгорания. Обеспечивая себе ресурс в виде свободного времени, тимлид сможет долго бежать в этом марафоне. Иначе выдохнется, и сразу же упадет эффективность команды, а результаты ухудшатся.
В равностороннем треугольнике критериев хорошего тимлида нет ничего самого главного, все три угла одинаково важны.
Все ошибки сделаны до нас
Рассмотрим основные типовые ошибки, которые совершают все руководители и не только тимлиды. Эти ошибки совершаю и я, в том числе. Важно их понимать и осознавать причины, которых мы тоже коснемся.
Суперменность или «Сделаю сам»
Представьте, что возникла небольшая задача. Вы решаете поручить ее сотруднику и думаете: «Сейчас же надо объяснить, потом как-то проверить, а он еще не поймет. Все равно все придется переделывать самому… Да ну, лучше сам сделаю!»
Я приду и решу любую проблему, потому что я супермен!
Запомните это ощущение. Когда оно возникает, нужно себя перебороть и все-таки перепоручить задачу, потому что это ощущение эмоциональное, а не рациональное. Под эмоциональное нежелание столкнуться со сложностями подводится «рациональное» объяснение. Но любое решение нужно принимать головой, а не эмоциями.
Когда тимлид решает задачу самостоятельно, он не выполняет функцию формирования команды: нет наставничества, команда не растет, и теряется свободное время.
Это не значит, что надо переводить вообще все задачи на своих сотрудников. Нет, чтобы быть в курсе технологий, не отставать от развития своей команды, иногда требуется осознанно самому браться за какие-то задачи. Ключевое слово — «осознанно».
Были ситуации, когда я понимал, что мне необходимо разобраться с какой-то технологией, и брал задачу на себя. Я делал это сознательно и предупреждал, что отхожу от выполнения функций тимлида на неделю и занимаюсь только технологической работой.
«Бутылочное горлышко»
Вторая ошибка похожа на первую. В первом случае мы говорили о случайных, мелких и спонтанных ситуациях. При синдроме «бутылочного горлышка» тимлид навешивает на себя задачи, которые можно поручить команде, систематически.
Систематические работы, которые выполняет тимлид, приводят к эффекту бутылочного горлышка.
Типичные ситуации.
- Релиз-менеджмент. Все написали код, а затем тимлид из последних сил пытается выполнить необходимые процедуры в срок.
- Код-ревью. Иногда тимлиды замыкают код-ревью на себя, вместо того, чтобы дать возможность провести его всей команде. Тимлид смотрит все сам, и становится «бутылочным горлышком».
- Баги. Часто тимлид замыкает на себя разбирательство с багами и ответы на вопросы смежных подразделений.
Все это ошибки. Не делайте так.
Откуда возникают ошибки
Источник ошибок «Сделаю сам» и «Бутылочное горлышко» это страх, причем трех видов.
Страх ответственности. Тимлид думает:«Кто-то сделает хуже, чем я, а мне отвечать. Нет, лучше сам». Это возможно, но зачем лечить следствие? Лечите причину — учите сотрудников выполнять свои задачи лучше и совершать меньше ошибок.
Страх потерять свою экспертность и значимость. «В чем моя ценность, если я поручил все сотрудникам? Они все выполнят, а где я — супергерой, который один может выполнить сложную задачу?»
Страх коммуникаций. Это страх взаимодействия с людьми и того, что вас поймут неправильно.
«Я сказал, меня поняли»
Представьте кружку. Кто-то представит пивную, кто-то — маленькую кофейную чашечку, а кто-то стандартную цилиндрическую кружку для чая и кофе. На простое понятие «кружка» у каждого свой образ.
В нашей индустрии мы говорим, например, «Микросервисы», и каждый понимает что-то свое. Для одного «Микросервис» это действительно микросервис, а для другого некий функциональный сервис. Под «Отчетом» один понимает PDF-файл, другой документ в Excel, а для третьего это динамические веб-формы, в которых можно сразу менять параметры.
Вы дали задание сотруднику и сказали сделать к пятнице. С утра в пятницу вы ждете отчет, но:
— Я не сделал.
— Почему?
— Ты же сказал в пятницу, еще целый день.
В конце рабочего дня вы снова спрашиваете, выполнена ли задача:
— Нет, не сделана.
— Почему?
— Еще же пятница не закончилась! Я сегодня буду до 12 сидеть и сделаю эту задачу.
Но вам-то надо в 7 часов передать эту задачу на установку!
Здесь неважно, что вы совершенно правильно сформулировали «Сделай до пятницы», и что «до» означает в четверг вечером. Важно то, как вас понял сотрудник и что у него сформировалось в голове, а не ваша стройная логика.
Важен результат, а не то, что вы сказали все правильно.
Есть несколько способов решить проблему с пониманием. Часто рекомендуют после того, как вы что-то объяснили, попросить сотрудника рассказать вам, что от него требуется. Способ работает, он ломовой. Если вы будете применять его постоянно, то сотрудники взвоют. Они решат, что вы сами ничего не понимаете, взбунтуются и не будут нормально работать.
Больше того, даже в этом случае не факт, что сотрудник правильно вас поймет. Если вы сказали «кружка», а сотрудник вернул «кружка», то все равно каждый из вас остался при своем понимании.
Единственный действенный способ решить проблему с пониманием — это контроль.
Нет контроля
Почему-то часто тимлиды считают, что раз они дали задание, то можно пустить выполнение на самотек и не контролировать. Это похоже на то, как если бы вы сели в автомобиль, увидели направление, закрыли глаза и уши и поехали. Хорошо будет? Наверное, не очень.
Не так давно я столкнулся с простой технической ситуацией — сконвертировать офисный документ в PDF. Дал задачу разработчику, он ее выполняет: тестирует в несколько итераций, потому что конвертация офисных документов в PDF всегда сопряжена с некоторыми проблемами.
До сдачи релиза один день, и, наконец, тестирование завершено, все хорошо. Разработчик говорит: «Я использовал платную библиотеку, а у меня демо-версия. Поэтому нужно купить лицензию». Но лицензию так быстро не купишь, а через день нужно отчитываться перед заказчиком.
На следующий день разработчик приходит и говорит: «Да ладно, не парьтесь! Я хакнул эту библиотеку, лицензия не нужна». Но мы не можем поставить взломанную библиотеку серьезному заказчику. Да, мы ее потом заменили и скорректировали ситуацию, но вся команда осталась без премии из-за того, что тимлид вовремя не проконтролировал технический аспект реализации задачи.
К разработчику в этой ситуации нет никаких претензий. Он не виноват, потому что раньше работал в другой компании, где не было проблем с быстрой закупкой лицензий. В рамках своих компетенций он все сделал правильно. Даже больше, когда возникла проблема, он ее еще и решил как умел. Разработчик молодец, тимлид не проконтролировал.
Отсутствие контроля — это ошибка, которая возникает из-за иррационального страха.
Иногда люди боятся обидеть кого-то: лишний раз спросить, проконтролировать, вдруг кто-то обидится, это же будет конфликт.
В одной из компаний, где я работал, была система опросов всех сотрудников. Мы опрашивали 360 человек об их отношении к работе, коллегам и руководителям. В компании работал один замечательный тимлид. Он обладал отличными техническими и софт-скилами, у него была отличная команда. Но я был удивлен, когда некоторые сотрудники команды выразили замечание, что тимлид их мало контролирует: не хватает внимания, работа как будто не имеет значения. Но тимлид их контролировал, просто они об этом не знали.
Сотрудники, скорее всего, были джунами. Они понимали, что им не хватает внимания, потому что контроль — это не только способ получения результата. Это и обратная связь, и коммуникация, и мотивация людей. Да, обратная связь может иметь форму провокации или микроконфликта.
Потеря лидерства
Хотели бы вы, чтобы у вас в команде работал такой сотрудник?
Я бы нет, и вот почему. Если вы помните фильм, героиня Шэрон Стоун вела себя провокационно. На просьбу соблюдать элементарные правила и не курить, ответила: «Вы на меня в суд подадите, если я закурю?» Подобный сотрудник в команде, на ваш запрос соблюдать простые правила, может спросить: «Иначе ты меня уволишь?» Если это произошло — вы потеряли лидерство.
Потеря лидерства в команде и нарушение формата коммуникаций — самая серьезная ошибка.
В любых взаимоотношениях люди всегда пытаются расширить зону собственного влияния. Дети постоянно проверяют родителей, насколько они готовы прогибаться под детские «хотелки». Сотрудники действуют также — всегда проверяют, насколько руководитель готов выдерживать формат коммуникаций, который ему необходим.
В этом случае мелочей не бывает. Когда формат коммуникаций потерян, и восстановить его сложно, когда сотрудник уже готов сказать: «Не буду делать, ты же меня не уволишь!», это запущенная ситуация. Ее гораздо легче предотвратить, обращая внимание на мелочи.
Например, вы пригласили сотрудника в кабинет:
— Присаживайся!
— Да ладно, я постою.
Человек не хочет выполнять даже микрораспоряжения. В этой ситуации у каждого тимлида есть выбор: закрыть глаза и говорить с человеком, когда он пребывает в своих мыслях, или настоять на том, чтобы он взял стул и сел. Необязательно для этого принуждать и давить — проявите гибкость: «Слушай, у нас долгий разговор, нужно смотреть на экран, тебе будет удобнее, если присядешь». Так в этом микропоединке вы окажетесь победителем. Это восстанавливает формат коммуникации, не давая ему дойти до неприемлемого состояния.
Но не всегда подобные сотрудники в команде это плохо. Чаще всего они самостоятельны, профессиональны и прекрасно знают себе цену. Здесь проблема не в качествах сотрудника, а руководителя: насколько конкретный руководитель готов работать с таким сложным и самоуверенным человеком.
Что должен делать хороший тимлид
Мы прошлись по основным ошибкам руководителей. Теперь поговорим о том, чем отличаются хорошие тимлиды от технических специалистов.
В любой ситуации тимлид берет ответственность на себя и принимает решения.
Представьте: Советский Союз, лунная программа. В НИИ, который разрабатывает луноход, работают две группы. Первая предлагает луноход на гусеницах, вторая — на железных колесах. Группа, которая предлагает гусеницы, утверждает, что железные колеса на Луне не сработают, потому что там двухметровый слой пыли. На Луне слабая гравитация, пыль не слеживается, её много, и луноход просто провалится в эту пыль.
Но на Луне никто не был, и не знает, есть ли там пыль. В этот момент генеральный конструктор Сергей Павлович Королев выпускает распоряжение по институту: «Считать поверхность Луны твердой». Проблема решена, он взял на себя ответственность и принял решение, хотя мог в этой ситуации совершить ошибку, потому что никто не знает, какая поверхность у Луны.
Хорошие тимлиды делегируют.
Работа — это обезьянка, которая сидит либо на ваших плечах, либо на плечах сотрудника. Каждый раз вы должны решать, на кого посадить обезьянку. Оставить ее на себе неудобно и тяжело, лучше пересадить на сотрудника. В этом суть и смысл делегирования.
Правила делегирования.
- Ставить задачу и четко формулировать.
- Обозначать критерии выполнения. Что вы будете считать хорошим результатом?
- Определять ресурсы на выполнение задачи. Это прежде всего время. Если дать указание сотруднику, у которого есть другая работа, он его не воспримет. Дайте ему ресурс: укажите, сколько времени он может потратить, определите дедлайн. Теперь сотрудник заинтересован в задаче, знает, что ему не придется сидеть сверхурочно, и вероятность выполнения работы выше.
- Обучать. Это важно при делегировании. Вы уверены, что сотрудник знает, как выполнить работу? Если не знает, вас ждут велосипеды, которые могут совершенно не походить на тот результат, что вы себе представляли.
- Контролировать. Вариантов контроля множество. Но важны не варианты, а цель контроля — получить предсказуемый результат. Но есть еще дополнительные цели: обратная связь (даже негативная), потому что контролируя, вы вступаете в коммуникацию; и мотивация сотрудника. Например, посетители фитнес-клуба часто платят деньги тренеру за то, чтобы он контролировал выполнение упражнения и попинывал. Это и есть мотивация через контроль.
- Утверждение своего лидерства.
Тимлиды устанавливают правила.
Приведу простую метафору с оживленным перекрестком. Есть два варианта регулирования движения. В первом варианте на перекрестке стоит регулировщик и управляет движением. Ему не очень здорово: шум, вонь, снег, дождь. Во втором варианте устанавливаются понятные формализованные правила проезда перекрестка, ставятся светофор и знаки.
Когда есть правила, можно понять, как контролировать. Если есть это понимание, значит можно передать функцию контроля другому человеку — делегировать контроль. Если правил нет, это сделать невозможно.
Например, в офисе всегда кто-то мерзнет, а кому-то жарко. Определите правила проветривания помещения и вам не придется каждый раз долго обсуждать, открывать сейчас окно или нет. Вы определяете, что в 11, 13 и 17 часов помещение проветривается, и это делает конкретный сотрудник. Все, кому холодно, в это время на 15 минут выходят. Простое правило, но освобождает время и команду от кучи ненужных дискуссий.
Правила позволяют избежать ошибок. Они самодостаточны: определяют, что нужно делать, ограничивают рамки ответственности.
Тимлиды работают с людьми.
Тема работы с людьми — огромная, коснусь её кратко. Первый тезис: люди никогда не будут работать так, как хочется вам. Они не обязательно будут выполнять задачи правильно так, как вы понимаете это «правильно».
Второй тезис: люди в большинстве своем иррациональны. Большинство якобы рациональных решений имеют эмоциональную природу.
Правила трансформации
Подведем итоги по превращению технического специалиста в тимлида, который умеет управлять.
- Тимлид это руководитель, а не только технический специалист.
- Управление это умение достигать результата чужими руками.
- Навыку управления можно научиться.
Чтобы научиться управлению, придерживайтесь нескольких простых правил.
Изменения требуют действий. Действуйте каждый день в мелочах. Хотите выполнить задачу самостоятельно? Поручите работу сотруднику. Понемногу вы измените свои шаблоны поведения.
Навык через повторение. Сначала вам придется прилагать усилия, чтобы делегировать работу другим. Но через некоторое время появится навык: вам станет комфортно, делегирование будет естественным.
Право на ошибку. Чтобы свободно действовать в новом для себя русле, дайте себе право ошибиться. Когда вы начнете действовать по новому у вас обязательно будут ошибки, но ошибаются все — это нормально. Радуйтесь этой возможности научиться чему-то новому. Если ошибок нет, учиться не на чем.
Обратная связь. Получайте обратную связь от команды и давайте свою.
Хотите прокачать навык управления, получать удовольствие от работы и быть настоящими лидерами своих команд — присоединяйтесь к сообществу тимлидов на TeamLead Conf в феврале 2020 года. И сегодня идеальный день, чтобы забронировать билет, потому что завтра повышение цены.
На сайте конференции мы постепенно отмечаем принятые доклады, а в рассылке группируем их в небольшие дайджесты. Скоро расскажем о новинках грядущей конференции, а пока можно изучить наполовину готовую программу докладов и написать, что в неё нужно добавить, в комментариях.
Автор: Роман Ивлиев
