Карьера руководителя: ценность через людей

Андрей начинает с определения: инженерный руководитель управляет множеством инженеров и отвечает за то, что это множество приносит пользу бизнесу. Он видит три потока работы — поставка бизнес-ценности и денег; состояние системы: стабильность, забагованность, скорость выкатки и актуальность стека; и строительство команды вплоть до того, каким был бы LTV разработчика, если бы такая метрика существовала. На стыках потоков рождаются метрики, а из метрик — процессы; сами процессы для него не отдельная функция, а инструмент балансировки трёх целей. Александр добавляет разрез из своего доклада на HighLoad года три назад: баланс зависит от стадии компании. В стартапе важнее всего понимать домен, а инженерная часть — про физибилити целей роадмапа; на scale-up надо найти руководителей, чтобы не стать бутылочным горлышком; в крупной компании выходят вперёд процессы вместе с тулингом; на зрелом рынке — операционная эффективность и косты, потому что доли уже поделены.

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

Зачем вообще идти в менеджмент, Андрей отвечает неожиданно: он никого не мотивирует и не считает, что разработчику стоит становиться менеджером. Одним достаточно узнать, что такая работа бывает; другим нравится всё в инженерии, и им менять ничего не надо. У него самого интерес к задаче заканчивался в момент, когда решение придумано: первые пять раз кодить интересно, а на шестой уже нет. Драйвило влияние на внешний мир — не красивый код, а то, что люди получают еду за пять минут вместо пятидесяти или что виртуалку стало можно перевезти между облаками; он работал в стартапе, который такой софт и строил. Руками он был бы эффективен максимум как пять разработчиков, а есть продукты, которые делают сто и тысяча человек. Уговорённых в менеджеры инженеров он видел много: рейт успеха невелик, и довольными они не выглядят.

Опасное ожидание — быстрые деньги: лиды первого уровня часто получают не больше синьоров, а работы становится сильно больше. Александр вспоминает свой переход лет тринадцать назад, когда менеджмент был фактически единственным способом расти: поначалу он делал меньше, а не больше, пока команда проходила форминг, шторминг, норминг и перформинг. Придя в Т-Банк в 2016 году, он получал меньше инженеров собственной команды и сравнялся с ними лишь через год. Ступени Андрей описывает так: начинающий тимлид с тремя-пятью разработчиками, который на партайме ещё пишет код; руководитель примерно на десять человек, который код уже не пишет совсем, — вот с него начинается полноценный управленец; лиды лидов на несколько десятков; дальше команды до сотни, где в небольших компаниях уже сидит CTO; и произвольное число директорских ступеней с сотнями и тысячами людей. Оба смеются над инфляцией тайтлов: когда-то CTO был директором разработки, а теперь за разработку отвечает целый технический топ-менеджмент.

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

Тайм-менеджмент Андрея держится на двух инструментах: одном календаре и личной тудушнице. В календарь записано всё личное, от завтрака до сна, и поверх этих блоков встречу не поставить. Рабочие встречи он делит на присмотр за процессами (факапы и даунтайм, забагованность продукта), чейндж-проекты, где ошибка слишком дорога, личное общение с подчинёнными и стейкхолдерами и пару часов в день на интеллектуальную работу и разбор тудушницы; задачи приоритизирует экспертно — импакт от S до XL плюс дедлайн. Восемьдесят процентов непродолбанных дедлайнов он считает отличным результатом и старается не выходить за восемь-десять часов. Техничность держится на двух с половиной способах: по часу в неделю на каждую из нескольких ключевых инженерных строек, чтение постов ради сигнала (сорок статей на Хабре за квартал — повод прочитать хотя бы пять) и разговоры с перами; кодить руками выходит только в свободное время. Александр добавляет пейперы вместо книг и Cursor с Perplexity, которые закрывают потерянный hands-on.