Команда может прожить без руководителя не неделю и не месяц, но примерно через год начинаются вполне земные проблемы: уходят самые инициативные, копится техдолг, а продукт продолжает приносить новые идеи, как будто ресурсов бесконечно много. Именно этот разрыв между внешней устойчивостью и внутренним распадом лучше всего объясняет, зачем вообще нужен тимлид в IT и почему роль лида не сводится к статусу «самый опытный разработчик в комнате».
В разговоре, о котором сообщает Habr / Карьера, тимлид Авито Маша Кондрашина обсуждает с ведущими подкаста «Мы обречены» не абстрактное лидерство, а очень прикладные вещи: как меняется роль лида после перехода из инженерии в менеджмент, почему корректирующий фидбэк не должен быть ни унижением, ни сахарной ватой, и что происходит, когда сильная команда надолго остаётся без человека, который держит рамку. Для российской IT-аудитории этот разговор интересен именно тем, что бьёт по нескольким болезненным точкам сразу: рынок стал жёстче, внутренних ожиданий к лидерам больше, а цена управленческих ошибок растёт даже там, где кажется, что всё под контролем.
Один из самых точных фрагментов беседы касается перехода из разработчика в управленца. По словам Кондрашиной, многих на этом этапе «шатает»: старые навыки уже не являются основной работой, а новые ещё не стали естественными. Отсюда знакомое многим ощущение «я уже не программист, но ещё не менеджер». И это не просто эмоциональный дискомфорт. Если лид долго не пишет код руками, он по-прежнему может читать архитектуру, понимать систему и замечать технические риски, но вернуться в режим ежедневной разработки быстро не получится: на это, по оценке героини, нужны месяцы. Важна и другая мысль: на рынке лидов нанимать сложнее, чем разработчиков. Если ожидания к инженерам старших уровней относительно унифицированы, то у компаний может быть совершенно разное представление о том, что именно должен уметь лид. В бигтехе, по её словам, обычно смотрят на два трека сразу: сохраняет ли человек компетенцию сильного инженера и умеет ли он управлять людьми. Это, по сути, и есть минимальный набор, без которого тимлид в IT быстро превращается либо в «бывшего разработчика с календарём», либо в технически слабого администратора.
Самый показательный кейс в разговоре связан с командой, которая осталась без лида на год. Сначала всё выглядело обнадёживающе: процессы уже были выстроены, люди самостоятельные, исследования и решения команда брала на себя, а прежний руководитель много делегировал. Такая конструкция снаружи выглядит почти как мечта любого зрелого подразделения. Но дальше начался медленный распад. Самые инициативные сотрудники стали уходить туда, где есть перспектива роста и человек, способный эту перспективу заметить. На команду наваливали новые проекты, а сказать «стоп, у нас нет ресурса» было некому. Продукт продолжал генерировать фичи, но никто не удерживал баланс между новыми задачами и техдолгом. В какой-то момент пять человек поддерживали пять проектов и уже не успевали за всем. Качество сервисов начало проседать. Это важный контраргумент против популярной идеи, что зрелой команде руководитель нужен только для найма, отпусков и one-to-one. На практике тимлид в IT часто незаметен ровно до того момента, пока его не убрали. И тогда выясняется, что он держал не только людей, но и границы системы: приоритеты, реалистичность обещаний, техническую гигиену и право команды не превращаться в бесконечный конвейер чужих хотелок.
Не менее приземлённо в беседе разобран корректирующий фидбэк. Здесь Кондрашина спорит сразу с двумя крайностями. Первая крайность знакома по историям старой школы: разнести человека так, чтобы он запомнил ошибку на всю жизнь. Вторая, более корпоративная, выглядит приличнее, но работает не лучше: завернуть неприятный разговор в «бутерброд» из комплиментов, критики и финального поглаживания. По её словам, этот метод давно считается слабой практикой: человек либо слышит только похвалу по краям, либо начинает воспринимать любую добрую реплику как сигнал надвигающегося удара. Вместо этого она описывает более жёсткую и при этом профессиональную схему: сначала фиксируется ситуация без оценочных ярлыков, затем конкретное поведение, затем последствия, а после этого ожидание, что именно нужно изменить. Фактически это попытка вернуть разговор из режима «ты плохой» в режим «вот где расхождение между ожиданием и результатом». Для инженерной среды это особенно важно: разработчики обычно терпят высокий уровень требований к качеству, но плохо переносят расплывчатость и личные наезды. И наоборот, прямой разговор без оскорблений часто воспринимается лучше, чем вымученная «эмпатия», за которой неясно, что вообще нужно исправить.
Отдельного внимания заслуживает кейс про сотрудника, который две недели делал большую задачу и принёс результат, неправильный «вообще во всём». Здесь Авито, по сути, предлагает простой тест для руководителя: сначала разберись, была ли задача в рамках уровня человека. Если да, значит проблема в несоответствии ожиданиям грейда, и разговор должен быть прямым: это не получилось, требования были такими, давай переделывать и поставим более ранние точки контроля. Если же задача изначально была выше уровня, то это уже не только ошибка исполнителя, но и ошибка планирования со стороны лида. В таком случае разговор смещается в сторону итеративности: не прыгать с места на сложную задачу, а разбивать путь на промежуточные проверки. На фоне нынешней моды на быстрое обучение, «вайбкодинг» и обещания войти в профессию за несколько месяцев эта часть разговора звучит почти как холодный душ. Иллюзия простоты в разработке по-прежнему продаётся отлично, но в реальной команде за неё платят сроками, качеством и выгоранием тех, кто потом разгребает последствия.
В итоге этот разговор интересен не шутками про «вредителя-инопланетянина», а довольно неприятной для отрасли честностью. Сильная команда не становится самоуправляемой навсегда только потому, что в ней сидят умные люди. Хороший фидбэк не обязан быть мягким, но обязан быть точным. А переход в лиды остаётся одним из самых рискованных карьерных разворотов в IT: слишком технический человек начинает задыхаться в менеджменте, слишком менеджерский быстро теряет доверие инженеров. Для компаний это означает простую вещь: экономия на сильном лиде нередко выглядит рациональной только до первого года без него. После этого уже приходится считать не зарплату руководителя, а стоимость упущенного роста, просевшего качества и ухода тех, кого обычно сложнее всего заменить.