Как пасти котов: делегировать, а не писать больше кода

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

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

Вторая глава — про управление собой, с метафорой «посмотри в зеркало», и Евгений сводит её к рефлексии — основе роста любого менеджера, хотя самого слова, по его ощущению, в тексте нет. Первая ошибка нового тимлида — считать, что сам он всё делает правильно, а результата нет из-за сотрудников, смежников и обстоятельств. Дальше он выделяет две боли, которые видит чаще всего. Задачи нужно делегировать, а не тащить самому: не только код, но и организацию работы, потому что тимлид один, запросов от смежных подразделений и руководства много, а сила тимлида — его команда. Вторая боль — страх, что тебе больше не за что платить: ты не пишешь код, не тестируешь, не пишешь аналитику, а только ходишь на встречи. Александр напоминает поговорку, что побеждает команда, а проигрывает тренер, и советует вести журнал решений — архитектурных и по инженерным практикам, — иначе потом не размотать, почему всё менялось.

Главу «как вести стаю за собой» Евгений критикует: название обещает лидерские качества, а внутри процессные вещи — как сделать так, чтобы коты не разбежались по коробкам. Лейтмотив — две аксиомы: первый процесс всегда идёт дольше, чем запланировано, потому что обязательно случится то, чего вы не предполагали, от чёрного лебедя Талеба до заблокированного пропуска, из-за которого сотрудник не попал на рабочее место. Александр, сам сертифицированный проектный менеджер, напоминает, что в начале двухтысячных софт вели проектно — скоуп, сроки, команда, — и что проектное управление нужно и сейчас там, где автономные продуктовые команды обязаны сойтись: дизайн мобильного приложения все заканчивают одновременно, а Олимпиаду в Сочи из независимых проектов не собрать. Вторая половина главы — про то, как вырастить себе замену: вы уйдёте в отпуск или заболеете, а с замом система отказоустойчивее. Евгений добавляет, что в ряде крупных компаний подготовка преемника — задача менеджера номер один на новой позиции.

В главе про организацию успеха Евгений выделяет одну мысль: лидер обязан помнить, куда идёт команда, хотя мешает всё подряд — вопрос руководителя про требования регулятора, смежники, испорченное настроение. В продуктовой парадигме это труднее, чем в проектной: развороты бывают на 90, 180 и все 360 градусов, поэтому стоит зафиксировать, куда вы ведёте команду и продукт хотя бы на год, и согласовать это с руководителем. Таблицу «что контролировать можно, а что нельзя» Евгений хочет показать проектным менеджерам — институт проектных менеджеров у них с Александром общий: на правую половину усилий тратить не стоит. В главе про встречи Александр идёт по списку — еженедельная командная, встреча по проекту, которая в оригинале, кажется ему, названа design meeting, один на один, ретроспектива — и замечает, что набор ритуалов зависит от процесса: у Алексея Пименова в книге про канбан-метод каденции устроены иначе. Общий вывод — прерывать встречи без повестки.

Шестую главу, про техническое лидерство, Александр считает устаревшей: её стоило бы наполнить нынешними практиками — тестами, пайплайнами доставки, проектированием. Оба помнят время, когда отдельных тестировщиков и аналитиков не было, инженер сам описывал, делал и проверял задачу; потом сложность доменов перестала помещаться в голову, а теперь платформенные инструменты прячут её обратно и ответственность возвращается к инженерам. Закат лидера — это микроменеджмент с одной стороны и «улететь на вертолёте», бросив команду, с другой, плюс непризнанные гении, набирающие технических звёзд, и карьеристы: империя шатка, потому что у самовлюблённого императора есть любимчики, а за ошибки он наказывает мгновенно. Восход сводится в схему из пяти основ — понимание, общение, делегирование, контроль и участие. В главе про босса — шесть ожиданий сверху и запрет на потёмкинские деревни; Александр отмечает, что начальник там женщина, что для 2002 года неожиданно. Последняя глава — про удалённую работу, экономические кризисы и технологические революции, которые участники примеряют на нынешний бум ИИ, и одиночество как расплату за лидерство, а следующий выпуск обещают примерно через неделю — по книге про лидерство на флоте.