7 причин не становиться тимлидом
Как становятся тимлидами? Типичный путь в этот омут — «эволюционный». Ты успешно выполнил кучу экспидайт-эпик-мамонтов, принёс в своё разработческое племя благодатный огонь метрик и мониторинга, показал, что тесты — это хорошо… И вот тебя уже назначают тимлидом — просто по принципу, что ты самый сильный среди других разработчиков. А бывает, что ты слишком долго на проекте, и вот, вуаля, предыдущий тимлид сгорел в битве при Монолите, и теперь по наследству мантия обязанностей переходит к тебе. Ну, и, конечно, путь инициативы — где ты сам вызвался на эту должность, из-за того, что очень ответственный, или от скуки, ради денег, или просто по фану.
Меня зовут Константин, недавно в Каруне я стал тимдидом и тут я поделюсь причинами, почему не стоит необдуманно падать в управленческую бездну.
1. Очень много времени будет уходить на обучение. Менеджеры — это что-то типа секты, и их инициация происходит через разнообразные тренинги, курсы и факультативы. Потратить 2 полных рабочих дня на тренинг, где ищут скрепки и учат определять, какой ты тип хлеба по Юнгу? Без проблем! А ещё нужно читать всякие бизнес-книги! Нормальные люди читают только Страустропа и Драгон Бук (правда, и первое, и второе мало кто дочитывает хотя бы до середины), чтобы осуждать людей в курилке, которые их не читали. А теперь нужно читать не про компиляторы и модные фраемворки —, а про успешных и высокоэффективных.
Объективно: если ты разработчик, ты и так привык и любишь учится. И на любом тренинге всегда можно узнать что-то или кого-то нового. Тренинги зачастую довольно интересны и полезны, а проблему с чтением всяких »33 навыков идеального менеджера» нужно решать через самоцензуру: если тебе не нравится слог, или ты понял идею книги на второй главе — дропай её.
2. Твоё время больше тебе не принадлежит. Весь твой тщательно выстроенный life/work balance просто срывается с моста. Сразу после того, как ты становишься тимлидом, твой календарь начинает пухнуть от встреч, грумингов, и каких-то обсуждений. Пообедать с выключенной камерой во время митинга и отлаживать код посреди обсуждения очередной поставки задач становится нормой. 3 встречи по часу подряд без перерыва — типичная среда.
Именно в этот момент стоит чётко осознать и обозначить: твой календарь всё-таки твой. Начни вести его сам. Выставляй блокеры и обеденные перерывы заранее. Выдели себе время на свои задачи, обозначь начало и конец рабочего дня. Это будет первой линией фортификаций вокруг твоего рабочего времени. Культура онлайн-встреч только развивается: мало кто думает о времени других, и многие искренне считают, что пригласить 20 человек на обсуждение их проблемы (а вдруг пригодятся) — это нормально. Не надо облегчать таким людям задачу. Действительно важные и проблемные митинги ты сам выставишь в календаре, для всех остальных у тебя должны быть открытые слоты, но ты можешь и должен их регулировать. Если не ты организуешь своё время — его организуют за тебя.
3. Теперь ты отвечаешь за всё. Когда ты разработчик, у тебя одна простая задача — сделать так, чтобы твои таски перешли из левого края борды в правый. Канбан или скрам, да наплевать — цель очевидна, мы тащим таску в релиз на прод. Для тимлида все таски его команды — его таски. И то, как они движутся по доске, не попадут ли они в reject после недели разработки, не тормозят ли они — это теперь твоя головная боль. Отчего какая-то фича находится в производственном аду уже больше 2-х месяцев? Как это не повторить?
Самая большая проблема на данном этапе — понять, что жонглировать парой задач легко, а вот целой доской без базовых знаний об организации процессов — ближе к поговорке про слепого лося, который бежит через горящий лес. Если твой PM умеет и хочет объяснять, зачем нужны лимиты, играет с тобой в канбан-игры, или пояснит, как лучше планировать спринт — тебе повезло. Но чаще всего тимлид получает уже кое-как настроенные процессы и в первую очередь пытается сохранить этот уклад — они же худо-бедно работают. И тут важно осознать, что в твоих силах не только сохранять имеющийся порядок вещей, но и менять его. И знания о всяких канбанах, скрамах понадобятся.
4. Теперь ты ещё и должен знать всё. Твои знания о кодовой базе текущего проекта — вероятная причина деменции в старости. Твоя голова хранит как карту и логику безумных объектно-реляционных отношений сущностей легаси монолита, помнит, откуда они появились, и какую идею туда закладывали, так и относительно свежие микросервисы — и то, как они работают и связаны между собой. А теперь во всю эту мешанину добавляются ещё и бизнес-процессы и их ценность. Как делать ту или иную задачу? Стоит ли её вообще делать? Как понять, что твой продакт-менеджер не сошёл с ума, и что это реально нужно реализовать? При всём этом — ты несёшь ответственность за детали реализации, где и когда нужно посылать алерты, где лучше поставить эксепшен, а, может, вообще стоит сделать целый микросервис под эту фичу? Техническая возможность и стоимость с рациональностью реализации будут всегда дамокловым мечом висеть над твоим воспалённым мозгом.
Тебя спасёт твоя команда и продуктолог. Не пытайся проектировать и оценивать каждую фичу. Доверяй коллегам — их экспертиза и инициатива могут стать твоим спасительным кругом. Оставь в прошлом доктрину «Никто, кроме меня». Тимлид, который не доверяет команде и просчитывает каждую фичу — это успешно несущийся (и ведущий команду) к выгоранию метеорит. И дружи с продуктологом или бизнес-заказчиком. Я видел и знаю команды, которые буквально ведут окопную войну с бизнесом: регламенты, митинги, процессы — всё это поле боя, где каждый не хочет отдавать ни строчки кода, и хочет чтобы техническая или бизнес-реализация была на первом месте. Объясняй продуктологу, как рефакторинг на 2 недели поможет команде и ему. Старайся понять, почему срочная реализация данной непроработанной фичи поможет вам и всему бизнесу целиком. Проси продакта сделать ретроспективу для всей команды: как ему помогла реализация той или фичи, или что выяснилось после провала очередной мегаидеи.
5. А что есть ещё что-то, кроме материальной мотивации? Один из самых больных пунктов. Когда ты растёшь из джуна или мидла, материальная стимуляция работает отлично. Поэтому на подкорке образуется устойчивая связь, что есть только один стимул, и он выражается в виде пуш-уведомления от твоего банка. Но вот ты тимлид и теперь ты осознаёшь, что никто не даст поднимать коллегам зарплату каждую неделю, всего вам доброго и хорошего настроения!
Чтобы понять, что может мотивировать коллег, стоит начать с честного ответа себе —, а что, кроме денег, мотивирует меня каждый день вставать и открывать ноутбук? Решение более сложных задач, дух соперничества, возможность конструировать элегантные сервисы, наводить рефакторингом порядок среди легаси хаоса, возможность ходить пить пиво с отличными и умными коллегами и шутить шутки — всё это хорошо работает в той или иной мере на любого члена команды. Будь честным — ты сам вряд ли вписываешься в блудняк с тимлидством ради денег (спойлер — их там особо и не дают). Материальный стимул важен, это базис, фундамент, а на основе его нужно работать уже другими методами.
6. Роль менеджера портит отношения с коллегами. Коллеги во время обеда уже не рассказывают про «дебильные вопросы об алгоритмах с того собеса». На дни рождения не зовут, мемасы про очередного СТО не шлют. Да и до тимлидства коллеги делятся на тех, с кем ты ходишь пить пиво, и на остальных, а теперь тебе интересны все коллеги. И теперь ты должен давать как хорошую обратную связь, так и плохую — причём доносить её явно, в форме помягче, чем «ну ты и фекалокодер!». Радости в жизни это не добавляет.
Поддерживать нормальную атмосферу в команде теперь — твоя обязанность. Задавать тон дискуссий — сложно, но нужно. И готовых рецептов, как это сделать, нет. Построить доверительные отношения с каждым членом команды — трудная задача. Мемасы про очередного СТО можно слать самому. Ну, и ещё стоит опасаться момента, когда в ходе поиска самого токсичного члена команды ты неожиданно выйдешь на свой собственный след.
7. Ты практически перестанешь кодить. Главная радость в жизни разработчика уйдёт на второй план. А даже если не уйдёт, то станет второстепенной. Более того — то время, которое ты раньше мог тратить на кодинг, теперь займут, на первый взгляд, бессмысленные митинги на 20+ человек, которые обсуждают рисование красной кнопки чёрным маркером и прочие не такие приятные как разработка активности. Отлично мысль про то, что тимлид или не должен кодить вовсе, или кодить, но нормально, описал мой коллега Антон Околелов в своём треде.
К менеджменту стоит относиться так же, как и к разработке: это решение загадок и задач, но только другими инструментами и традиционно без документации. Это такой же хаос, который нужно автоматизировать и привести к порядку. Кодинга станет меньше, но главное — поймать похожий вайб от организации работы команды, чтобы получать такое же удовольствие от рабочего процесса, как в прежней роли.
Опытный разработчик имеет все признаки менеджера: он ответственен, способен организовать свой и чужой рабочий процесс, планировать, составлять правила работы и заставлять других их придерживаться. Но не всегда он может и хочет быть тимлидом. Я слишком много знаю разработчиков, которые сгорели в роли менеджера и снова стали просто кодить. Разработчик гораздо более независим и свободен, а у тимлида больше ответственности и гораздо меньше ресурсов и средств для решения проблем. Плюньте в тех, кто проповедует идею, что тимлид — это следующая ступень для роста разработчика, это не так. Это совершенно другая роль, она не лучше и не хуже — просто она другая.
Идти ли туда — решение должно совпадать с вашим внутренним стремлением, а не возникать просто из-за того, что вас хотят туда назначить.
