Тимлид — не повышение. Это смена профессии.
Главный подвох: навыки, которые сделали вас сильным инженером, могут помешать стать хорошим руководителем. Я работаю техническим директором и вырастил более двух десятков тимлидов. Некоторых отговорил — и горжусь этим не меньше. Перед тем как инженер уходит в менеджмент, я предлагаю ему эти семь вопросов.
За каждым вопросом — не сухая теория, а реальный опыт и истории живых людей.
Я готов перестать писать код?
Первое, что заберет у вас карьерный трек тимлида — это код.
Не сразу. У тимлида еще останется время на код: процентов 20-40, зависит от компании. Но тимлид — это только первая ступенька карьеры технического менеджера. Дальше вас ждёт unit-lead, где код писать уже просто некогда. Cluster-lead, где тратить время на код — вообще преступление. А дальше CTO или целый VP, где о коде даже мечтать будет нельзя. Исключения я видел, но крайне редко.
Если человек не готов перестать писать код совсем, его ждут последствия.
Такой тимлид начнёт решать системные проблемы с помощью кода. Например, был у меня тимлид Вася. Команда Васи была кросс-функциональной — 8 человек, занималась всем подряд. К Васе несколько раз в день приходили стейкхолдеры: бухгалеры там, юристы всякие. И постоянно накидывали ему задач. Васе было жалко команду, поэтому он разбирался с мелочевкой сам и тратил на нее больше половины дня. Каждый день.
Плохо что ли, спросите вы? Хорошо ведь: тимлид защищает своих сотрудников от влетов!
Очень плохо, отвечу я. Потому что ни у одного члена команды не было ИПРа, встречи 1-1 Вася проводил хорошо если раз в месяц, а разбирать новые задачи с командой вообще не мог. У него просто не оставалось времени на работу тимлида. Команда видела в нем еще одного разработчика, но с другой лычкой. А главное — он не пытался решить системные проблемы, которые приводили к влетам. Он продолжил решать проблемы кодом, как разработчик.
Вася не перестал быть разработчиком. Просто он стал разработчиком, у которого есть ещё и подчинённые.
Мне важно сразу видеть результат моей работы?
Когда я был разработчиком, каждая строчка кода приносила видимость прогресса. Пишу код, обновляю страницу — вижу результат. Очень нравилось. К вечеру появлялось приятное чувство усталости от выполненной работы, я пушил код в репозиторий и шёл домой.
У тимлида все будет не так.
Вот вам типичный день менеджера в ИТ: с утра разруливаем конфликт между двумя сеньорами по поводу кейса на ревью, потом согласовываем приоритеты с продактом, потом несколько встреч 1-1, потом — перерыв. В перерыве нужно ответить на 17 сообщений в слэке, потому что без вас никак. Ответили, и вот перерыв подошел к концу и пора идти на встречу по новому процессу перформанс ревью, после нее — синк по целям с вашим руководителем.
Приятное чувство усталости сменится на менее приятное чувство вымотанности.
А главное — у вас нет РЕЗУЛЬТАТА. Одну часть дня вы, как прилежный садовник, сажали семена. Они прорастут, но не завтра и даже не через неделю: например, правильность новых приоритетов. Другую часть дня вы делали так, чтобы работа просто работалась — отвечали на сообщения, решали конфликты.
Но ничего из этого в конце дня не выглядит как РЕЗУЛЬТАТ.
И если вам важно его видеть каждый день, работа тимлида вас может сжечь. Мой другой тимлид — допустим, Женя — оставался через день до ночи на работе. Он хотел сделать хоть что-то осязаемое. Написать документацию (он мог бы ее делегировать) или шёл оставлять комментарии в ревью (сеньоры в его команде и без него справлялись).
Результаты работы тимлида видны только на дистанции. Но после дня встреч объяснить это себе получится не у всех.
Я люблю людей?
Странный вопрос для рабочего контекста, правда?
Но именно от ответа на него зависит, станете ли вы лидером — или нет.
Пока вы разработчик, вы достигаете результата своими руками. Но тимлид производит результат чужими руками. И чтобы чужие руки работали хорошо, нужно разбираться в людях, к которым эти руки приделаны. Знать, от чего у них горят глаза, а от чего опускаются. Видеть, когда человек перерос свои задачи — раньше, чем он сам это осознает и начнёт ходить на собеседования. Разруливать конфликты, которые тебя лично вообще не касаются, но отравляют команду.
Лучше меня все сказал Вилл Ларсон в своей книге «Элегантная Головоломка»:
Особый вызов менеджмента — вкладываться в карьерное развитие человека, который сам не уверен в своих целях.
Ваш успех теперь измеряется чужим ростом. Не вашим кодом, не архитектурой — а тем, что вчерашний мидл сегодня тащит проект, в который ты вы заглядываете неделями. К сожалению, никто не выдаст вам волшебную палочку, которая за вас сделает из мидла сеньора. Растить людей будете вы.
Звучит вдохновляюще, пока не сталкиваешься с реальностью: люди — это сложно.
У меня был коллега-тимлид — пусть будет Андрей. Сильный технически, спокойный, рассудительный. Команда видела в нем технический авторитет и уважала. Но Андрей любил задачи, а не людей. Он не запоминал, кто о чём мечтает. Не замечал, что его лучший сеньор полгода сидит на одних и тех же задачах и потух. Встречи 1:1 проводил как статус-митинг: «что в работе, есть ли блокеры, ок, до связи».
А потом лучший сеньор резко уволился, без объяснения причин.
Сеньор не пытался поговорить с Андреем, потому что просто не чувствовал, что Андрею это интересно. И был прав, если честно. Андрей просто не считал частью своей работы — лезть в чужие головы. А это и есть работа тимлида. Не вся, но фундамент.
Я готов к конфликтам?
Только что мы говорили про любовь к людям, а теперь вдруг с ними надо конфликтовать? Все правильно, сейчас расскажу.
Тимлиду иногда придётся отказывать. Заказчику — в сроках. Сотруднику — в повышении, потому что пока не готов (нужно проговорить и составить дорожную карту до повышения, а не просто отказать). Руководителю — в идее, которая кажется ему гениальной, а вам с вашим контекстом — нет. Иногда ваши аргументы примут.
Иногда — нет, и придётся пройти через конфликт.
Представим себе тимлида — скажем, Лена. Лена людей любит по-настоящему. Знает, у кого когда день рождения, кто чем болеет, кто о чём переживает. Команда за ней в огонь готова идти.
Но Лена не умеет говорить «нет».
И вот к Лене приходит заказчик с горящим проектом и нереальными сроками. Лена соглашается и отправляет команду в Страну Горящих Дедлайнов. Это там, где люди забывают про ворк-лайф баланс и видят сны про строчки кода. Возможно, они успеют сделать проект — но какой ценой? Нежелание идти на конфликт может стать путёвкой в выгорание. Я такое видел.
Или мой пример — я боялся сообщить сотруднику, что он не тянет. Прятался за формулировками и сглаживал углы: делал всё, лишь бы не задеть чувства сотрудника. А после очередного перформанс ревью пришло время расставаться, потому что человек не тянул. Для сотрудника ситуация выглядела как «меня увольняют на пустом месте», потому что он не понимал моих намеков. Расставание было тяжелым, и хотя самой ситуации уже более семи лет, помню я ее до сих пор.
Но постоянно отказывать всем во всём тоже нехорошо. Тимлиду предстоит научиться видеть золотую середину и набить свои шишки.
Меня пугает неопределенность?
Представьте, что вы управляете поездом. Вы должны сообщить пассажирам, когда они прибудут в точку назначения — но есть нюансы!
Во-первых, поезд уже едет. Что характерно — с разной скоростью, потому что скорость зависит от кочегаров, каждый из которых работает в своем ритме. Кто-то просто бросает уголь, кто-то решил попробовать новую модную лопату, про которую вчера прочитал на Хабре.
Во-вторых, у вас нет карты. Совсем. Есть набросок на салфетке — его составил один из пассажиров со странным именем Продакт. Но по-честному — не факт, что это прям та местность. Возможно, это даже не та страна. Вероятно, на маршруте не везде проложены рельсы. Мосты построены из веток и надежды (веток не всегда хватало).
В-третьих, в ходе поездки пассажиры могут решить, что им надо не в точку А, а в точку Б. По документации, железная дорога там есть. По факту — узнаете, когда доедете.
И вот вы стоите перед пассажирами. Вам нужно объявить время прибытия до точки назначения. А лучше — время прибытия на каждую станцию по ходу движения.
Это та реальность, в которой живет тимлид: ограниченные рычаги влияния, но полная ответственность за результат. Если поезд опоздает, нельзя сказать «Виноваты кочегары, медленно подкидывали уголь».
Тимлид не бросает уголь и не прокладывает рельсы. Но если поезд опоздает, он берет на себя ответственность.
Я хочу учиться убеждать людей?
Когда я был разработчиком, за меня говорил код: он работал, архитектура была чистой, а тесты — зелеными. В мире разработки правота очевидна. Talk is cheap, show me the code.
Когда стал тимлидом, резко осознал: talk — вообще не cheap. В мире менеджмента talk это новая валюта. Потому что в этом мире редко есть единственно правильное решение. Вместо этого, перед тимлидом есть веер решений, и у каждого есть свои плюсы и минусы. Задача тимлида — не только выбрать правильное решение, но и продать его.
Вот как тимлид может попросить время на автотесты: «Нужен один человек на автоматизацию. Повысим coverage с 43% до 78%, ускорим тесты.»
Но продакт на такое предложение просто кивнёт и скажет «рассмотрим». Потому что мы привели факты на языке инженеров. Продакт не знает нашего языка. Поэтому надо говорить на языке продукта.
Вот так: «Смотри: мы чуть не завалили два последних спринта. Если бы завалили, по MAU пролетели ниже таргета. Ты сам все видел. Давай выделим человека на два спринта для автоматизации. Устраним риски срыва в будущем, плюс начнём экономить дополнительный день каждый спринт и сможем делать больше задач».
Одна и та же идея, но разный язык. И разная вероятность успеха.
Для тимлида быть правым — недостаточно. Нужно быть убедительным. Я до сих пор этому учусь. Если статья вам кажется убедительной — значит, получается.
Я хочу зарплату тимлида или роль тимлида?
Это моя боль. Я спас несколько человек от роли тимлида — и горжусь этим.
Проблема в том, что иногда инженер видит только один путь наверх — это роль тимлида. Инженер уверен, что хочет расти. Смотрит по сторонам: наверх ведет только одна дверь. На ней написано «тимлид», а за дверью грохот и крики. Здоровые амбиции и желание развиваться подталкивают его открыть дверь, а дальше... Ну, вы уже прочитали, что дальше.
Только это неправда.
Есть и другая дверь — Individual Contributor. Во многих компаниях России она уже есть: называется staff, principal, архитектор или навигатор. За этой дверью — инженерный рай. Там инженера ждет рост в качестве крутого специалиста, который повелевает архитектурой и распределенными системами. Его ждут тонкости компиляторов, работа с инженерной культурой компании, лидерство масштабных технических инициатив.
Например, мои staff/principal инженеры руководили распилом монолитов и строили Kafka as a Service. Они проектировали NRT решения для DWH и строили хитрую систему тестирования на стейджах, которая позволяла тестировать ветку сервиса, но не ломать стабильный стейдж.
Некоторые из них перешли в Individual Contributor'ов из тимлидов и даже unit-лидов. Я это называю «спас от тимлидства». Пока ни один не пожалел о своем выборе: оказалось, что амбиции можно совместить с получением удовольствия от работы.
Как сделать выбор
Я не хочу вас отговаривать. Хороших тимлидов всегда мало, и индустрии они нужны. Путь тимлида сложный, да. Местами уровня «да сколько можно-то?» сложный. Но он меняет взгляд на работу, на продукт, на людей. Иногда — на самого себя.
Если вы ответили «нет» на один или несколько вопросов выше — это не значит, что всё пропало. Это значит, что вы видите, где вам будет больно. Видите слепые зоны. А это уже половина успеха. Все это можно развить — я точно знаю, потому что видел это десятки раз.
Я делаю так: когда один из инженеров в моих командах хочет стать тимлидом, его руководитель понемногу начинает «отсыпать» ему своих задач. Например, инженер начинает отвечать за планирование спринтов, потом — за оценку проектов, потом — за сбор и формулировку требований.
С одной стороны, это минимизирует стресс инженера, с другой — даёт возможность взять тест-драйв новой роли. Если не получится, можно откатить и вернуться в трек Individual Contributor без стресса.
Да, за дверью «тимлид» действительно грохот, крики «а когда релиз?» и кто-то отчаянно спорит про оценку в стори поинтах или часах.
Но я не пожалел, что открыл эту дверь.
Если вам понравилась статья, подпишитесь на мой телеграм-канал. Я пишу про менеджмент без корпоративной астрологии — только реальные кейсы и научные доказательства. Например, недавно разбирал, как Боб Айгер занял место CEO Диснея.
А если хотите прокачать свой навык убеждения, вот стратегия переговоров от Криса Восса — переговорщика ФБР по освобождению заложников.
