Статья «Почему тимлид перестает справляться: 7 системных причин, а не слабая личность» Автор психолог в IT, и это чувствуется: много про «ловушки», «идентичность» и «ресурсы». Идея понятна: защитить несчастного руководителя от злых языков, которые посмели назвать пробуксовку выгоранием или слабостью.

Статья выстроена вокруг тезиса, что пробуксовка руководителя почти никогда не связана с его личными качествами. Во всем виновата система: она создает ловушки, не дает ресурсов, не снимает старых задач и вообще ведет себя как вредитель. Зерно правды в этом есть, и оно крупное. Компании действительно нередко нагружают новоиспеченных тимлидов так, будто те внезапно обзавелись второй парой рук и лишними восемью часами в сутках. Однако чем дальше продвигаешься по тексту, тем отчетливее проступает перекос. Автор с таким усердием обеляет руководителя, что под конец тот превращается в безвольную фигуру, с которой обстоятельства делают что угодно, а она лишь страдает и ждет внешней помощи.

Попробуем пройтись по ключевым утверждениям статьи и понять, где в этой картине мира потерялась сама суть управления.

Тезис первый. Переход из инженера в руководителя это ловушка

Автор пишет, что компания берет сильного технаря, вешает на него людей, но не меняет ни задачи, ни ожидания. В итоге ни кода, ни управления. И это подается как «системный сбой».

Я читаю и думаю: а где в этом уравнении сам тимлид? Человеку дали новую должность, новые обязанности. Что мешает ему задать прямой вопрос: «Ребята, а что с моими старыми задачами? Я теперь отвечаю за работу целой команды, код в прежнем объеме писать не смогу» Почему автор статьи нежно называет это «ловушкой идентичности» и «страхом отпустить код», а не называет вещи своими именами, неумением вовремя обозначить новые границы своей роли? Можно спорить о том, насколько легко такой разговор дается в конкретной корпоративной культуре, но сам факт, что этот разговор необходим — очевиден.

Тезис второй. Хронический разрыв между требованиями и ресурсами

Автор ссылается на модель JD-R и объясняет, что выгорание случается, когда требования превышают ресурсы. С этим никто не спорит. Но дальше идет странный вывод: «это не вопрос личной слабости, это дисбаланс, который поддается коррекции, если на него обратить внимание».

Позвольте. А кто должен обратить на это внимание? Система? Прилетит фея-ресурсница и сама все поправит?

В оригинальной статье субъект, ответственный за эту самую коррекцию, так и не назван. Дисбаланс предлагается просто заметить, как будто от факта наблюдения он рассосётся.

Вот здесь и зарыта главная методологическая ошибка статьи. Автор выносит за скобки самого тимлида как субъекта управления. Дисбаланс требований и ресурсов это не погода, которая случается с человеком против его воли. Это управленческая ситуация, которую руководитель обязан отслеживать и регулировать. Если он не может её отследить и предъявить руководству в цифрах, то управленческой функции нет. Есть только функция исполнителя, который молча принимает входящий поток.

В статье есть прекрасная фраза: «В такой ситуации даже самый сильный управленец рано или поздно начинает пробуксовывать». Неправда. Самый сильный управленец в такой ситуации не пробуксовывает. Он эскалирует, торгуется, фиксирует KPI, снимает с себя лишнее, перераспределяет задачи внутри команды или уходит туда, где ресурсы соответствуют задачам. Пробуксовывает тот, кто пытается быть удобным для системы, которая его жрёт.

Тезис третий. Тимлид не может делегировать, потому что устал

Автор честно пишет: «Когда тимлид уже на пределе, он не может качественно делегировать. Вместо подготовленной передачи задач происходит хаотичный сброс».

Окей. Допустим, человека назначили вчера. У него действительно не было времени ни воспитать людей, ни выстроить систему. Но это не отменяет главного: обнаружив, что старые задачи никуда не делись, а новые уже висят, он обязан это озвучить. Не «воспитать команду за неделю», а сказать: «Я теперь отвечаю за десятерых, поэтому мой личный вклад в код сокращается в десять раз. Давайте решать, кто берет мои старые задачи». Это не требует месяцев подготовки. Это требует одного разговора. Если этого разговора не происходит и тимлид молча пытается успеть всё, то проблема не в отсутствии времени на построение системы. Проблема в том, что он даже не попытался обозначить новые правила игры. Когда я читаю про «страх отпустить код» и «зону комфорта», у меня возникает простой вопрос: а вы уверены, что перед нами руководитель, а не старший разработчик с доплатой за то, что он ходит на митинги?

Тезис четвертый. Культура героизма и отсутствие поддержки сверху

Автор сетует, что в компаниях романтизируют тушение пожаров и работу на износ, а тимлид, который уходит домой вовремя, выглядит нелояльным.

И снова вопрос: кто транслирует эту культуру в команду? Если тимлид спускает вниз, что «надо пахать», а наверх не может продать идею «устойчивая команда работает лучше, чем загнанная», зачем он нужен? Он что, просто ретранслятор чужих неврозов без собственной позиции?

Тимлид это тот, кто должен защищать команду от «героизма», насаждаемого сверху, а не быть его проводником. Если он этого не делает, он часть культуры выгорания, а не её жертва.

Тезис пятый. Практики спасения

Статья предлагает практики: визуализация роли, поэтапное делегирование, защита времени для стратегии. Я не спорю с их содержанием. Более того, я полностью с ними согласна. Проблема в том, что это не «практики» в смысле специальных управленческих техник, которые надо где-то осваивать на курсах. Это базовый здравый смысл взрослого человека, оказавшегося на руководящей должности. Четко понимать, за что ты отвечаешь. Не хвататься за всё самому. Выделять время подумать. Слышать свою команду. Менять критерии оценки работы. Если тимлиду нужно объяснять такие вещи как откровение, то у меня вопрос не к системе, а к тому, как этот человек вообще оказался на позиции руководителя.

В реальности, когда человек уже по уши в дерьме и не спит ночами, совет «создать буферные зоны для рефлексии» звучит как «просто начните дышать, когда вас душат». Если он не смог выбить себе эти буферные зоны в спокойное время, откуда они возьмутся в горячке? Волшебством?

Если вам предложили стать тимлидом сегодня

Допустим, вы хороший разработчик и вам только что сказали: «Поздравляем, теперь ты руководишь командой». Первое и единственное, что вы должны сделать в этот момент, не воображать себя капитаном корабля, а включить режим переговорщика.

Возьмите время на подумать. Не соглашайтесь с ходу на всё, что на вас повесят. Задайте прямые вопросы руководству, желательно письменно, чтобы потом было чем тыкать.

Как именно изменятся мои задачи с понедельника? Какие задачи становятся приоритетными, а какие с меня снимаются? Кто будет делать мою прежнюю работу и в каком объеме? Какое время мне дается на адаптацию и вхождение в роль? Кто теперь отвечает за найм и увольнение людей в моей команде? Потому что если отвечаете вы, а права голоса у вас нет — вы не тимлид, а нянька с расписанием. Какой у меня бюджет на обучение команды, инструменты или аутсорс? Если ответ «никакого», то фраза «развивай команду» превращается в «сделай конфетку из того, что есть, бесплатно». Кому я эскалирую проблемы, которые не могу решить на своем уровне? И есть ли у этого человека время и желание меня слышать. Или вы будете кричать в пустоту. По каким метрикам будет оцениваться моя работа через полгода? Кто принимает финальное решение по техническому долгу и архитектурным спорам внутри команды? Если это всё еще вы единолично, то делегировать вы не сможете никогда, потому что последнее слово всегда за вами. Что будет с моей зарплатой, если я решу вернуться обратно в разработчики? Многие боятся спрашивать, а потом сидят в тимлидах, потому что «назад дороги нет». А она либо есть, либо нет. Лучше знать сразу. Как часто пересматриваются KPI и загрузка команды? Если ответ «по ситуации», значит пересматривать будут только когда кто-нибудь уволится.

И вот вы задали эти вопросы. Дальше возможны два сценария.

Сценарий первый, здоровый. Вам отвечают по существу. Где-то идут навстречу, где-то торгуются, но в целом понятно, что руководство осознает: смена роли требует перенастройки. Можно работать.

Сценарий второй, он же самый частый. Вам не отвечают, а начинают увиливать и манипулировать. В ход идут коронные фразы: «Ну ты же понимаешь, какая сейчас ситуация в компании», «Нам нужен сильный руководитель, который не боится трудностей», «Ты что, считаешь, что не справишься?». Это не диалог. Это проверка на вшивость. Если вы проглотите эти скользкие формулировки и согласитесь на размытые условия, руководство довольно потирает руки. Они только что сэкономили на нормальном найме управленца, получив ваше согласие пахать за двоих в обмен на сомнительный статус.

И вот здесь остановитесь. Еще раз подумайте. Очень хорошо подумайте. Выгорание это не просто слово из статей психологов и не модный диагноз для ленивых. Это инфаркты в сорок лет. Инсульты. Разрушенные отношения с близкими, потому что вы постоянно на взводе и не вылезаете с работы. Таблетки от давления и антидепрессанты горстями. Вы готовы поставить на кон свое здоровье и свою жизнь ради прибавки в 30% и красивой строчки в резюме? Ради компании, которая с вами торгуется как на базаре, не давая ни полномочий, ни ресурсов, ни внятных ответов?

Почему управленцы так делают? Ответ простой. Они экономят. Нанять профессионального руководителя с рынка стоит дорого. Взрастить своего долго и тоже дорого. А назначить сильного технаря, пообещать ему красивую должность, не снимая старых задач, и закрыть прореху в оргструктуре бесплатно. Это обычная корпоративная лень и жадность.

Что в итоге

Статья полезна ровно в одном: она честно описывает признаки нездоровой организации. Но вывод она делает неверный. Автор пытается исправить систему, забывая, что тимлид это не пассивный винтик, а тот, кто вполне способен подкручивать гайки в нужную сторону.

Если тимлид не умеет зафиксировать свои границы, перевести управленческую нагрузку в метрики и цифры, продать наверх необходимость ресурсов, выстроить делегирование до того, как его накрыло, защитить команду от токсичной культуры, то это не «системный сбой». Это человек пока не на своем месте.

Называть такого человека «слабой личностью» неправильно, потому что не управленческие навыки делают личность сильной или слабой. Называть «жертвой системы» тоже неверно, будто бы человек вообще ни на что не влияет, хотя на самом деле ему просто не хватает конкретных компетенций. Управленцы это не особый «элитный» тип людей. Управленческие навыки можно развить. По сути это комплекс компетенций, необходимых для эффективного планирования, организации и контроля работы команды и процессов.

Если вы пока ведущий разработчик и у вас есть цель стать тимлидом, это хорошая цель. Вы уже сейчас можете читать профессиональную литературу, делегировать мелкие задачи, собирать фидбеки и задавать вопросы. Только не команде, а самому себе. Что я сделаю иначе, если завтра стану тимлидом? Где мои слабые места как управленца? Вот что стоит анализировать. Кто-то умный сказал: сложно управлять одним человеком, как ни странно, собой. А когда научитесь, сможете управлять сотнями.

Управленец обязан уметь торговаться за условия своей работы. Не умеешь пока — учись. Не хочешь учиться — добро пожаловать обратно в код. Там тоже нужны герои.

Если прямо сейчас вы не умеете выбить себе приемлемые условия, как вы будете отстаивать интересы команды потом? Сложно управлять другими, когда не научились управлять своим положением в системе.