Как-то, работая в «Ситимобил», я проходил тренинг по Ситуационному лидерству (SLII®), и вот этот тренинг я до сих пор считаю лучшим, что проходил. Не столько из-за подачи и организации тренинга, хотя и это было на высшем уровне, сколько из-за самой концепции — она тогда соединила разрозненные кусочки знаний о развитии сотрудников и делегировании задач у меня в голове в единую картину и дала готовый инструмент, который можно было применять сразу после тренинга.

Тренинг базировался на модели ситуационного лидерства, которую разработали американские исследователи поведения Paul Hersey и Kenneth Blanchard и описали в своей книге «Management of Organizational Behavior» аж в 1969 году, и сейчас у неё уже десять переизданий!

В чём идея?

Идея в том, что любой человек, который переходит на новую должность, берётся за новый проект или открывает для себя новую область, неминуемо проходит через четыре уровня зрелости (Maturity Levels).

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

☝️ M1: Новичок-энтузиаст (не может, но хочет)

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

✌️ M2: Разочаровавшийся ученик (не может и не хочет)

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

🤟 M3: Способный, но осторожный исполнитель (может, но не хочет)

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

🖖 M4: Самостоятельный профессионал (хочет и может)

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

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

Каждому уровню зрелости — свой стиль руководства.

☝️ S1 для M1. Указывающий

Ты директивно даёшь чёткие указания о том, как должна выглядеть и функционировать наша платформа: как разворачивать, запускать, эксплуатировать и в каком виде выдавать результат. Внимательно следишь за процессом реализации и проверяешь результат на каждом шаге.

✌️ S2 для M2. Наставнический

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

🤟 S3 для M3. Поддерживающий

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

🖖 S4 для M4. Делегирующий

Ты сосредоточен на стратегии развитии платформы и подключаешь сотрудника к её реализации. Определяешь сроки, скоуп и точки контроля. Согласовываешь план — дальше он сам решает, как его выполнить. У него есть все права, полномочия и ответственность для реализации.

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

❗️ Но помни, не все сотрудники могут пройти все четыре уровня — кто-то застрянет на промежуточных.

Фаря Рословец позвала меня на стрим 🍿

Будем говорить про масштабирование инженерных команд, выстраивание процессов и развитие инженерной культуры. Я расскажу на примере Citydrive, как за 3 года отмасштабировал ИТ-команду в 5 раз.

Встречаемся 4 сентября (завтра!) в 19:00 по Москве.

👉 Зарегистрироваться на стрим

Только ленивый ещё не высказал свой прогноз о том, как AI изменит рынок разработки программного обеспечения. Эксперты рынка звучат так же убедительно, как и финансовые эксперты в 2014 году, которые уверяли нас, что рубль укрепляется и не надо покупать доллары… а потом случился «чёрный вторник», и доллар с 30 рублей за штуку взлетел до 80.

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

Но всё ещё я слышу другое утверждение — «middle и junior разработчики скоро будут не нужны, останутся только senior’ы». И вот, мне оно тоже кажется неубедительным. Давайте объясню почему.

Понятие senior неоднородно. Того, кого считают супер-крутым senior’ом в условной веб-студии, в большинстве случаев не возьмут даже на позицию junior в FAANG.

Почему? Да потому что наш супер-крутой senior из веб-студии может элементарно не знать, как построить масштабируемую архитектуру для проекта, чтобы выдержать 10k RPS. Он вполне может не суметь спроектировать распределённое файловое хранилище, чтобы сохранить все фотографии из VK, или быстро реализовать алгоритм Дейкстры.

А почему? Да потому что ему это и не нужно! У него нет таких задач. Всё, что требуется, так это быстро «на коленке» наклепать интернет-магазин или сайт-визитку для клиента и выложить это в прод. Ни миллионной аудитории, ни задачи коммивояжёра там не будет.

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

Senior Prompt-Engineer’ами не рождаются — ими становятся.

И поэтому будут и senior и даже junior промпт-инженеры в веб-студиях, и junior и middle промпт-инженеры в средних компаниях. Все они будут расти, развиваться, создавая нормальное распределение уровней должностей промпт-инженеров.

Но поживём — увидим 😎

Как-то один из моих лидов несколько месяцев не мог закрыть позицию в свою команду. И не то чтобы позиция была какая-то особенная — рядовой Golang-разработчик. Да и с рынком тогда всё было нормально — собеседования шли регулярно. Но каждый раз у него было «что-то не то»: то кандидат не до конца знаком с нашим стеком, то глубины знаний Golang не хватало, то где-то по софтам недотянул.

Месяцы шли, задачки копились, а мы всё искали идеального кандидата... 🫠

Как-то я читал про концепцию руководителей типа А и B:
👉 Руководитель типа А — это лидер, который не боится конкуренции и нанимает людей не слабее, а иногда даже сильнее себя
👉 Руководитель типа B — напротив, опасается нелояльных сотрудников, поэтому предпочитает брать людей слабее, чтобы сохранить контроль

Есть даже целая теория о том, что руководитель типа А собирает вокруг себя команду А-игроков, а руководитель типа B — команду С-игроков.

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

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

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

Вот три вопроса, которые я задаю себе после каждого собеседования:

☝️ Чего именно кандидату не хватает, чтобы быть максимально подходящим для этой позиции?

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

✌️ Смогу ли я научить этому кандидата?

Готов ли я инвестировать своё время и силы в его развитие? Будет ли у меня достаточно ресурсов? Смогу ли подключить к этому кого-то из команды?

🤟 Готов ли сам кандидат учиться и расти?

Насколько он открыт к развитию и получению новых знаний? Не будет ли он упираться и цепляться за старые подходы и навыки?

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

❗️ Тут важно понимать, что сильные команды рождаются не из идеальных кандидатов, а из умения руководителя видеть потенциал и развивать людей.

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

Я пришёл в Ситидрайв в апреле 2022 года. Тогда ИТ-департамент насчитывал около 30 человек, из которых примерно 12 были в одной большой команде NodeJs-разработчиков во главе с лидом.

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

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

Функциональные команды

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

Так появились команды, отвечающие за:
👉 финансы (эквайринг, биллинг, рейтинги, программы лояльности, бонусы и начисления)
👉 бэкенд для мобильного приложения
👉 телеметрию (интеграция с блоками и обработка данных)
👉 бэк-офис (админки и системы управления парком)

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

Направления разработки

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

Например:
👉 команда бэк-офиса разделилась на две: одна отвечала за админки и внутренние сервисы, вторая — за системы управления парком
👉 появилась команда по процессингу заказов
👉 выделился домен пользователя (регистрация, рейтинги, риск-профили), вокруг которого мы начали собирать команду из Golang-разработчиков

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

И я выделил новый уровень организационной структуры. Сначала сгруппировал команды в функциональные направления (мобильная и серверная разработка), а затем пересобрал их в доменные направления разработки.

В итоге получилось три направления:
👉 клиентское, отвечающее за разработку мобильного приложения и веб-версии
👉 парковое, отвечающее за сбор и обработку телеметрии, системы управления парком и внутренние сервисы
👉 платформенное, отвечающее за общие сервисы и инструменты для разработчиков

Кросс-функциональные команды

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

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

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

Команды отвечают за:
👉 маркетинговые инициативы
👉 финансы и оплаты
👉 пользовательский опыт во время аренды
👉 регистрацию клиентов и допуск в сервис
👉 веб-версию

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

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

И вдруг — бац 💥! Тебе пишет разработчик: «Привет, я хочу уволиться».

Не проходит и месяца, как на созвоне с другим разработчиком он говорит, что у него оффер, и он тоже хочет уйти из компании.

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

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

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

☝️ Спрогнозируй риски

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

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

✌️ Дай оттоку оттечь

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

Говори ребятам спасибо за прошлые заслуги и спокойно отпускай их покорять новые горизонты.

🤟 Коммуницируй внутри команды

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

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

🖖 Держи руководителя в курсе

Докладывай о ситуации в команде, проговаривай с ним свой риск-план.

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

Важно показать руководителю, что ты контролируешь процесс и держишь всё под контролем.

«Вот сейчас проведём performance review, вычислим слабых разработчиков и уволим их!» — заявил мне как-то HR.

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

Вот мой чек-лист, в каком порядке я оцениваю разработчиков.

Efficiency 🚀

Это то, как много задач разработчик закрывает за единицу времени — и больших, и маленьких.

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

Всё это характеризует высокопроизводительного разработчика — high performer 💪

Есть ещё low performer. Он не закрывает много задач за единицу времени, систематически не попадает в свои же оценки, не автономен — постоянно просит помощи и уточняет детали. Не берёт ответственность, тяжело переключается между контекстами, теряет фокус, зависает и уходит в пустые рассуждения.

💡 Как выявить?

Не нужны burn down chart’ы и скрытые механизмы слежки. Достаточно недельку поработать с человеком, послушать, что и как он говорит на daily, — и всё станет ясно. Разбуди ночью тимлида, и он сразу назовёт своих high и low перформеров.

Руководителю разработки с несколькими командами и десятками разработчиков стоит на 1-2-1 с тимлидами спрашивать, кто у него молодец, а кто нет. Если из раза в раз «немолодцы» одни и те же — вот и список low перформеров.

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

Reliability 🦾

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

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

Да, конечно, у всех есть error budget, и high performer в абсолютных значениях может ошибаться чаще, чем low performer, но зависимость между количеством закрытых задач и числом проблем на продакшене не должна быть линейной.

💡 Как выявить?

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

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

Loyalty 💎

High performer, который редко ошибается, — но как он работает в команде?

Моментально ли подключается к инцидентам и оперативно катит фикс? Или закрывает ноутбук в 18:00 — и гори оно всё синим пламенем?

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

Команде и смежникам комфортно с ним работать? Или это токсичный сгусток желчи, разлагающий коллектив?

💡 Как выявить?

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

Вот тут и может помочь perf review и оценка 360°, если, например, разработчик был десантирован на внешний проект и фидбэк к тебе не доходил. Но чудес ждать не стоит — лучше сам иногда заходи к смежникам и спрашивай — всё ли ОК?

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

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

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

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

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

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

👉 приносит результат, выступая производителем (Producer)
👉 строит порядок и процессы, выступая администратором (Administrator)
👉 генерирует идеи и указывает направление развития, выступая предпринимателем (Entrepreneur)
👉 соединяет людей и создаёт систему ценностей, выступая интегратором (Integrator)

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

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

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

Например:
👉 руководитель, у которого идеально развита только организационная работа (Administrator), будет кодироваться как pAei
👉 руководитель, который силён в генерации идей и производстве результата, но слабее в других функциях — PaEi
👉 руководитель, способный только лишь генерировать идеи — --E-

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

А ещё бывают руководители, которые выгорели и потеряли смысл, — у них потухли все четыре функции:
👉 ничего не производит (P↓),
👉 не управляет процессами (A↓),
👉 не генерирует идей (E↓),
👉 не поддерживает людей (I↓).

Это управленец, который формально занимает позицию, но не создаёт никакой ценности — ни для команды, ни для компании. Для такого руководителя даже придумали специальный термин — «мёртвый пень». Он кодируется отсутствием всех функций как ----.

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

А пока можешь поставить лайк этой заметке и пройти тест, чтобы определить свой тип по Адизесу. Меня, например, этот опросник оценил как PAei, что соответствует правде 😎

Мы с тобой обсудили модель менеджеров по Адизесу, а теперь начнём обсуждать каждый тип по отдельности. Начнём с Производителя (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 — запускать, чинить и разгребать всё, что всплывёт 😎