Мы с тобой обсудили модель менеджеров по Адизесу, а теперь начнём обсуждать каждый тип по отдельности. Начнём с Производителя (Producer, буковка P).

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

Производителю нужна чёткая и измеримая цель, и тогда он будет мотивирован на её достижение. Если нет конкретных показателей успеха, то Производитель теряет интерес и демотивируется — он не понимает, что именно нужно достичь и как это влияет на успех компании. Он не любит обсуждений и советов, предпочитает единолично и быстро принимать решения, считая свои мотивы понятными и очевидными, а при несогласии с ним — настойчиво и авторитарно продавливает своё мнение. Раздражается и теряет мотивацию, когда кто-то вмешивается в его работу, пытается контролировать или тормозит.

Производитель не мыслит стратегически, а его решения краткосрочны. Он привык использовать знакомые инструменты и не склонен к внедрению инноваций или созданию чего-то нового.

Задача, выполненная собственными силами, приносит Производителю наибольшее удовлетворение, а отсутствие признания его заслуг демотивирует.

В своей крайней форме (P---) Производитель превращается в Героя-одиночку 🦸

Герой-одиночка — это трудоголик, который берёт всю работу на себя. Он решает самые сложные, важные и срочные задачи, а его подчинённые — наблюдатели на подхвате. Когда Герой осознаёт, что не справляется, он, так уж и быть, в последний момент сбрасывает часть горящих задач на подчинённых. В остальное время они без дела слоняются по коридорам, потому что у Героя-одиночки нет ни времени, ни интереса заниматься административными вопросами.

Как работать с руководителем-производителем❓

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

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

Что делать, если руководитель-производитель — это ты❓

👉 Не принимай решения молниеносно и не беги реализовывать. Остынь, переспи и дай себе время на размышления — а нужно ли вообще это делать, есть ли в этом польза?
👉 Не отвергай мнения тиммейтов, поощряй их инициативу и участие, прислушивайся к ним, учитывай их в принятии решений
👉 Не доводи задачи до кризисных ситуаций — делегируй их на более ранних этапах. А лучше выпиши то, что можешь делать только ты, — остальное отдай команде
👉 Мысли стратегически: жёстко выделяй время в календаре для размышлений — о целях, рисках и направлениях развития. Принимая решение, задавай себе вопрос: «Как это решение будет работать через 3–6 месяцев?»

Недавно у меня был перелёт со стыковочным рейсом. У меня был целый час, и я решил взять кофе в аэропорту. С баристой у нас возникли небольшие трудности перевода, но в итоге он понял, что я хочу латте большого размера с единственным шотом эспрессо.

Когда я вернулся за кофе, бариста радостно протянул мне кружку, но вместо латте в ней был обычный американо. Я ещё раз взглянул на чек — в нём было пробито именно латте. Указав на несоответствие, бариста удивился, извинился и пошёл переделывать напиток. Вернувшись через пару минут, он снова извинился, протянул мне кружку с латте, и я ушёл ждать посадку и наслаждаясь кофе. Кстати, кофе он сделал действительно неплохой.

Казалось бы, ну допустил ошибку и допустил. Но интересно, сколько таких ошибок он делает за день. Вместо того чтобы приготовить сто порций кофе, он же может сделать и сто тридцать. А где он возьмёт время на дополнительные тридцать кружек? Будет перерабатывать, уставать, выгорать и/или выполнять другие свои функции хуже 😢

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

Ровно с такой же риторикой я столкнулся, когда пришёл в Ситидрайв. Команда из десяти backend-разработчиков с лидом, все как один, заявили мне, что им никто не выделяет время на рефакторинг.

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

Вот примеры того, что я заметил:

👉 У меня был разработчик, который регулярно получал от команды саппорта задачи по начислению различного рода компенсаций пользователям. Он открывал базу и вручную делал селекты и апдейты.

👉 Второй разработчик вручную запускал скрипт миграции карт со старого эквайринга на новый. Если какие-то карты мигрировались неверно, он пробегался по ним и пытался вручную их смигрировать.

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

По сути, то время, которое разработчики могли бы потратить на исправление технического долга и на рефакторинг, они тратили на эти ручные операции. Я пару недель анализировал работу десяти разработчиков и выписал порядка трёх десятков таких кейсов, которые точно можно и нужно было автоматизировать.

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

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

Возвращаясь к баристе из кафе ☕️

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

Уверен, в твоей компании есть такой человек — или ты точно встречал его за время своей карьеры.

Упал прод и никто не знает, что делать? Звонят ему. Критический баг в пятницу, и чинить некому? Ну как некому — мы знаем, кто поможет. Он никогда не говорит «нет», всегда спешит на помощь, доступен в любое время дня и ночи и даже в отпуске (а ходит ли он вообще в отпуск?).

Он всегда приходит на помощь, тушит любой пожар и всех спасает.

Таких людей мы называем «героями» 🦸 и слагаем о них оды. Чего говорить, даже у Бориса Гребенщикова был универсальный рецепт на любой кризис — «Немедля звони человеку из Кемерова».

Как-то один, знавший жизнь, системный администратор сказал мне фразу, которую, как мне кажется, я запомнил на всю жизнь — «Героизм одних — это про*б других».

И вот так часто бывает, что в случае наших героев тот, кто проявил героизм, и тот, кто допустил про*б, — один и тот же человек.

Так, ведь и вправду.

👉 Герой не даёт команде расти

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

В такой токсичной обстановке остальные члены команды чувствуют себя второстепенными и теряют мотивацию.

👉 Герой создаёт хаос

Постоянно нарушает процессы во имя результата. Код-ревью? Не, буду пушить напрямую в мастер! Тестирование и отладка кода в дев-среде? Это лишняя бюрократия! Автотесты? Документация? Ну ты понял... 😅

Постоянная работа в авральном режиме, хот-фиксы, правки — всё это неизбежно ведёт к техническому долгу и багам.

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

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

И институт геройства — это не причина, а следствие проблем. «Герои» своими усилиями скрывают фундаментальные проблемы в процессах и архитектуре, которые иначе были бы очевидны и требовали бы решения. И стоит убрать героев, как всё рассыплется, как карточный домик.

Что делать, шеф?

☝️ Убери топливо для героизма

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

✌️ Создай ротацию

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

🤟 Почини планирование

У задач должны быть реалистичные сроки выполнения, они должны учитывать риски и системные проблемы. Вы должны уметь гибко переприоритезировать ваш бэклог, если кто-то неожиданно заболеет или уйдёт в day off. Любая задача из бэклога должна иметь возможность быть выполненной другим членом команды. Перестань выводить сотрудников на работу в выходные дни и во внерабочее время.

🖖 Регламентируй и автоматизируй

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

Герои нужны в кино❗️там есть завязка и кульминация сюжета, а в сложных сервисах, которые работают 24/7, нужны системность, отказоустойчивость и стабильность.

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

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

Это были невероятно драйвовые и продуктивные почти 4 года, но пора двигаться дальше!

Когда я пришёл в Ситидрайв на позицию СТО в марте 2022 года, я и не мог представить, сколько всего нужно будет сделать и сколько в итоге будет сделано. А сделать удалось действительно многое 😎

👉 2022 год. Подняли стабильность сервиса в 50 раз! Мы снизили потери от технологических инцидентов с 1,5% GMV в месяц до 0,03%. Это позволило сократить отток аудитории, и мы смогли подняться с третьего места на рынке каршеринга на второе.

👉 2023 год. Рост бизнеса и запуск новых бизнес-инициатив. Инженерная команда выросла в 2 раза — с 50 до 100 человек, попутно автоматизировав всё, что можно, максимально ускорив путь кода до продакшена.

👉 2024 год. Фокус на качестве после бешеного роста. Запустили направление сопровождения сервисов — быстрее реагируем на проблемы клиентов и решаем их. Повысили качество инженерных решений — запустили архитектурный комитет и технологические учения.

👉 2025 год. Мы полностью переосмыслили идею каршеринга и превратили её в платформу для автолюбителей, запустив новые направления бизнеса «Надолго» и «Rent-a-car». Инженерная команда выросла до 150 человек, и мы начали реализацию новой технологической платформы, которая позволяет быстро запускать и валидировать бизнес-инициативы.

Главное достижение, которым поистине горжусь за эти 4 года — это команда, которую удалось собрать и вырастить. Команда, где каждый инженер силён, уникален и является экспертом в своей области.

И сейчас, когда IT-стратегия на 3 года защищена, а бюджет на 2026 год утверждён, самое время передать управление команде и двигаться дальше — к новым вызовам и возможностям 🚀

И пользуясь моментом, хочу поздравить всех с наступающим Новым годом — увидимся уже в новом году! 🎄✨

Ого, я тут посмотрел — а с последнего поста уже полгода прошло 🙈

Если кто успел соскучиться — всем привет 😎 Нет, я не умер, живой как никогда.

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

Отдельное спасибо всем, кто иногда пишет мне в личку что-то вроде: «Ау, ты где?», «Ну шо, где посты?», «А ты чего канал забросил?»

Продолжайте, это правда помогает не пропасть окончательно 💪

А пока для всех, кто соскучился и давно не слышал моего голоса: я записал выпуск Podcast++ с Александром Чистилиным, руководителем отдела автоматизации продаж Ви.Tech.

Поговорили про карьерный даунгрейд — когда шаг назад по роли или деньгам может быть не поражением, а инструментом роста.

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

Если ты сейчас думаешь про смену карьерного трека — тебе будет полезно это послушать.

Выбирай платформу:
🎧 ВКонтакте
🎵 Яндекс Музыка
🎙 mave

Ну и ждите новых постов. Я правда постараюсь чаще 🚀

Слушайте, кажется, я понял, почему пропал на полгода и ничего не писал. Всё это время я пытался разобраться, кто вообще такой лид в новой реальности и нужен ли он в том виде, в каком я про него весь последний год тут писал. И вот чует моё сердце, что тот лид, про которого я тут с сотню заметок написал, становится нужен всё меньше и меньше.

Когда-то IT-компании запускались двумя-тремя единомышленниками в гараже. Потом они росли, сервисов становилось больше, и под них требовалось всё больше и больше программистов. Под этот спрос открывались всевозможные курсы «Войти в АйТи» для будущих разработчиков, тестировщиков и дата-аналитиков, и в отрасль повалили все кому не лень из своих прошлых профессий. Мы как-то собеседовали скрипача, который 20 лет играл на скрипке, а потом прошёл курс в Skillbox и решил стать фронтендером 🙃

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

А что поменялось?

❗️Написание кода больше ничего не стоит.

Не «подешевело», а именно ничего не стоит — ноль рублей, ноль копеек на фоне всех остальных затрат на развитие компании. Один человек с Claude или Codex сегодня работает как целая кросс-функциональная команда из десяти. Ему не нужны отдельные iOS- и Android-разработчики, бэкенд, фронтенд, тестировщики — он закрывает всё это сам, в консоли, за своим компьютером. Один.

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

Вот индустрия и сжимается. Команды снова становятся маленькими — это прям тренд современного мира. Теперь нередко в команде всего два человека — продакт-менеджер и разработчик. Причём продакт тоже пишет код: с тем же Codex или Claude он херачит не меньше разработчика. Разница только в фокусе — разработчик глубже сидит в инженерии, понимает, как правильно собрать код, как его задеплоить, как смотреть в инфраструктуру, а продакт смотрит в продукт и бизнес, а в код — поменьше. Но садится и пишет наравне. И вот такая двойка спокойно запускает проекты любой сложности за очень короткий срок 🚀

Ну и ты меня спросишь — а что тогда происходит с тем самым лидом, который про процессы, фреймворки и управление десятком людей? А я и сам не знаю! Сам с интересом наблюдаю, как меняется отрасль, и буду приходить сюда и рассказывать тебе, что вижу 😎

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

Ну ладно. Давайте снизим градус футурологии и вернёмся к нашей управленческой классике.

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

Теперь поговорим про Администратора (Administrator, буковка A).

Администратор — это менеджер, который отвечает за порядок и делает так, чтобы работа команды была предсказуемой, повторяемой и управляемой.

Если Производитель спрашивает, что надо сделать и когда будет результат, то Администратор спрашивает, по какому процессу мы это делаем, кто владелец, где это описано и что будет, если всё пойдёт не так.

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

Но логика у него простая. Если что-то в компании случилось один раз, значит, это может случиться ещё раз. А если это может случиться ещё раз, значит, надо придумать, как в следующий раз не зависеть от удачи, памяти конкретного человека и ночного героизма.

Поэтому Администраторы очень не любят героев.

Для Производителя герой — красавчик, который затащил и спас ситуацию. Для Администратора герой — живое доказательство, что где-то процесс дал слабину.

Он, конечно, понимает, что человек выручил команду. Но всё равно смотрит на этот подвиг как на незакрытый баг в своём регламенте.

Злится, вздыхает и идёт дописывать регламент 🙃

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

А вот где Администратор раскрывается по-настоящему, так это в большой компании. Там появляются смежники, дежурства, отпуска, онбординг, доступы, релизы, поддержка, performance review, должности, грейды, разные часовые пояса — и Администратор прикладывает все усилия, чтобы знания не жили только в головах людей, а превращались в понятный и последовательный регламент 💪

Главная опасность Администратора — перепутать порядок с результатом.

Пока процесс помогает команде спокойнее приходить к результату, всё хорошо. Он убирает хаос и не даёт наступать на одни и те же грабли.

Но иногда Администратор так увлекается порядком, что процесс становится важнее смысла.

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

И вот пользователям больно, команда бесится, сроки едут, а руководитель не понимает, что не так. Отчёты заполнены, встречи проведены, галочки стоят — значит, всё работает.

В крайней форме (-A--) Администратор превращается в Бюрократа, у которого регламент уже не помогает реальности, а пытается её заменить.

Идею Администратору нужно продавать через управляемость.

Если твоя задача — убедить руководителя-Администратора, не пытайся вдохновлять его красивой картинкой будущего. Он всё равно быстро вернёт разговор к рискам, владельцам, процессам и последствиям.

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

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

Ну а если так случилось, что Администратор — это ты, то периодически проверяй, не слишком ли дорого команде обходится твой порядок 😎

Ну что, друзья, кажется, я понял, что делать. Пишу про AI — и получаю кучу реакций, хоть и вида 🥴, зато кучу! Пишу про классический менеджмент — реакции уже такие, 😎, но в разы меньше. Видимо, надо как-то писать про AI в классическом менеджменте, чтобы сразу убивать двух зайцев. Ну а пока я до этого дойду опытом, давай чуть поговорим про найм.

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

И вот здесь важно понимать, что правильно ответить на все вопросы — это ещё не гарантия оффера. Дальше идёт внутреннее обсуждение, и сделают тебе оффер или нет во многом зависит от того, будет ли там кто-то топить за твою кандидатуру.

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

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

И я сам не раз бывал таким адвокатом. Как-то, работая руководителем разработки, я нанимал людей под себя и сам выступал их адвокатом. Я хорошо понимал потребности команды и какой профиль сотрудников ей сейчас нужен, и однажды позвал сразу троих бывших коллег с прошлой работы — я успел с ними хорошо сработаться, знал их очень близко и не сомневался, что это топ-перформеры как раз под нашу команду 💪 Я формально провёл с ними свой технический этап собеседования и передал дальше, к вышестоящим руководителям.

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

И ещё один момент, про который часто забывают. Высокая должность твоего знакомого сама по себе мало что значит. Когда я был на позиции CTO, мне регулярно писали бывшие коллеги и присылали резюме в расчёте, что я увеличу их шансы попасть к нам. Но, как и полагается по процессу, я отправлял эти резюме в общий поток к HR, и дальше человек шёл по обычным собеседованиям. Проходил — хорошо, но повлиять на решение я уже не мог, да и не считал правильным. Было бы странно через несколько уровней давить своей должностью и настаивать, чтобы взяли именно этого кандидата. В конце концов, нанимающий менеджер сам решает, подходит ему человек или нет.

Так что дело даже не в том, хочет ли твой знакомый тебе помочь — захотеть-то он может. Важно, насколько он близок к самому найму. Если он в той же команде или функции, куда тебя берут, он реально может за тебя вписаться. А если он на несколько уровней выше, повлиять на решение он уже не сможет, да и лезть в чужой найм через всю вертикаль попросту непрофессионально.

В итоге всё сводится к простой вещи. В большой компании тебя оценивают не только по ответам на собеседовании, но и по тому, захотел ли кто-то внутри за тебя бороться. Так что не рассчитывай только на свои ответы и ищи себе адвоката 😎

Когда становишься лидом, очень хочется быть для команды тем самым честным руководителем, которому нечего скрывать от своих.

Твой руководитель что-то сказал, и ты сразу принёс это команде. На какой-то встрече обсуждают изменение структуры, закрытие проекта или перенос людей — и ты сразу проинформировал команду 🫡

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

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

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

Ты хотел быть честным и прозрачным руководителем, а в итоге сам добился обратного эффекта и устроил хаос, потому что команда услышит совсем другое.

Команда услышит, что проект закрывают. Что работа, которую люди делали последние недели или месяцы, может оказаться никому не нужна. Что надо начинать переживать, спрашивать друг друга, строить версии и ждать, что будет дальше. И даже если ты десять раз добавишь «это ещё не точно», тревогу ты уже запустил.

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

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

Тут важно понимать простую вещь. Часто на таком обсуждении ещё и рассказывать нечего. Утром обсуждаем один вариант, днём прилетает новая вводная, вечером на столе уже другой. Решение появится потом, а пока это просто рабочая текучка.

Но команде незачем жить внутри всей этой неопределённости, пока решения ещё нет.

Твоя задача как лида — не тащить в команду каждую мысль, которая мелькнула на какой-то встрече. Иногда хорошее решение — подождать и дать информации немного настояться.

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

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

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

Дай обсуждению пройти хотя бы один-два круга. Пусть из набора вариантов появится решение или хотя бы понятная развилка. Вот тогда уже можно идти к команде — ты приносишь не слух, а реальность, с которой дальше можно работать 👌

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

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

Как-то мы с женой собрались в кино. Премьера, кинотеатр на Курской, попкорн, уже почти заходим в зал, и тут на телефон прилетает критический алерт — прилёг биллинг.

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

В итоге поворачиваюсь к жене и говорю, что кино отменяется. Садимся в машину и едем домой к ноутбуку 🫠

Быть доступным 24/7 и готовым в любой момент помочь команде — вообще обычная история для CTO. Особенно остро я это почувствовал в начале своей работы CTO в Ситидрайве. Сложно строить личные планы, когда они вот так легко рушатся 🙃

И понятно, что инцидент чинит не CTO в одиночку. Когда горит прод, ты вызваниваешь нужных инженеров хоть вечером, хоть ночью, хоть в выходной. Потому что упавший сервис нужно поднять этой же ночью — чтобы утром следующего дня компания и команда спокойно продолжили работать в штатном режиме.

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

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

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

В таком ритме мы прожили месяца полтора. При этом будни тоже были не по восемь часов — я приходил в офис к десяти утра и закрывал ноутбук где-то в 9 вечера.

И довольно быстро стало понятно, что магии не происходит.

В субботу приходишь в офис, а там пусто. Кафешки вокруг закрыты, город живёт своим выходным днём, а ты зачем-то сидишь и закрываешь рабочие тасочки. В будни проще втянуться, потому что вокруг люди, встречи, задачи, а в кафешке напротив, в конце концов, подают бизнес-ланч!

По моим ощущениям, в эти субботы мы делали меньше, чем в обычный рабочий день.

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

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

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

И вот тут есть ещё одна ловушка. Почти всегда дедлайн кажется финишем, до которого надо любой ценой дотянуть. Мол, сейчас потерпим, запустимся, а потом выдохнем.

Но дедлайн вообще не финиш ❗️

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

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

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

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

Команда не становится сильнее от того, что у неё забрали выходной. Она просто приходит в понедельник ещё более уставшей, а потом тебе же с этой командой переживать post-launch — запускать, чинить и разгребать всё, что всплывёт 😎

Мне кажется, в коммуникации со своим руководителем есть две крайности.

☝️ В первой руководители приходят на one-on-one и на вопрос своего руководителя «как дела?» отвечают что-нибудь в духе «всё нормально, всё бодрячком, работаем» и дальше сами варятся в своих проблемах. Не эскалируют, не обсуждают, не просят помощи, потому что вроде как руководитель должен справляться сам.

✌️ Во второй руководители, наоборот, приходят и во всех красках рассказывают, с чем они сражались, как всё победили и как без них тут вообще всё бы развалилось.

И я как раз и был из первых.

Когда мой руководитель спрашивал меня, как дела, я отвечал, что всё хорошо, проблем нет, всё решаем. Мне правда казалось, что это правильное поведение самостоятельного руководителя. Мол, зачем мне беспокоить его своими проблемами, если я сам могу с ними разобраться? У меня есть зона ответственности, значит надо брать и делать 💪

И вот вы можете представить моё удивление, когда на очередном ревью я услышал от своего руководителя, что это, оказывается, не очень хорошее поведение 🙃

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

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

И ещё интересно, у ребят иногда возникают проблемы, с которыми я сам раньше не сталкивался, и тогда просто интересно послушать, что это за проблема и как её вообще нужно решать.

❗️ Окончательно меня перевернула история другого моего руководителя.

Мой руководитель был заместителем вице-президента в очень большой корпорации. Как-то его руководитель, тот самый вице-президент, по семейным обстоятельствам ушёл в отпуск на полгода, и всё это время мой руководитель его замещал, репортя напрямую руководителю корпорации.

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

Когда вице-президент вернулся, моему руководителю стало интересно, какой фидбек о его работе дал руководитель корпорации. И оказалось, что нормального фидбека почти нет, потому что руководитель корпорации просто не понимал, с какими проблемами мой руководитель столкнулся за эти полгода и как именно он их решал.

И после этого эту фразу я часто стал использовать в своей работе.

💡 Как я могу оценить твою работу, если я не знаю, с какими проблемами ты сражался и как ты их решил?

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

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

Иначе можно полгода героически сражаться, всё выдержать, никого не потревожить, а потом внезапно обнаружить, что никто и не может оценить твой героизм по достоинству 😎

Как-то, когда я был лидом и ходил по собеседованиям на эту роль, я часто натыкался на один и тот же разговор: мы ждём, что лид будет писать код. И дальше начинались игры с цифрами — где-то говорили 30 на 70, где-то 50 на 50, где-то вообще 70 на 30.

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

Я писал код, когда был разработчиком, писал код, когда был лидом, и даже когда был на позиции CTO, всё равно иногда что-то пописывал. Мы всё-таки инженеры, и если нужно засучить рукава, расчехлить клавиатуру и порешать проблему кодом, то очень странно в этом случае говорить: извините, я теперь руководитель, у меня лапки и я могу только на созвоне с вами посидеть, пока вы тут код пишете 😎

Но тут важно не перепутать две разные вещи. Лид должен писать код, но он не должен имитировать фуллтайм-разработчика. Потому что, чтобы качественно решить задачу и написать хороший код, нужно выделить часа 4 сфокусированного времени, полностью погрузиться в задачу — вгрузить в себя её контекст, погрузиться и разобраться в проблеме, реализовать решение, протестировать его, выкатить на прод и продолжать быть за этим кодом ответственным и чинить, когда что-то поломается.

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

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

Лиду, как по мне, и без продуктовых задач есть чем заняться в команде, он может:
👉 чинить маленькие баги и технический долг;
👉 выполнять R&D по архитектуре, библиотекам и инструментам;
👉 делать прототипы для будущих решений.

Вот это, на мой взгляд, и есть здоровый hands-on для лида. Не отнимать у команды задачи из спринта, а брать то, что требует инженерного взгляда, спокойного разбора и готовности самому покопаться внутри.

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

Но для этого нужно пройти техническое собеседование: код, архитектура, trade-off’ы, технологии, системный дизайн. И если ты несколько лет руководил так, что вообще не открывал IDE, то будет довольно больно.

Я поэтому с большим удивлением отношусь к позиции «я код писать не буду». Ну окей, если ты только пришёл в новую команду, тебе может быть вообще не до кода: найм, процессы, смежники, ожидания руководителя... Но эта работа конечна, и в какой-то момент команда уже собрана, процессы работают, люди вошли в рабочий ритм.

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

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