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