Быть Лидом 😎

Сейчас все вокруг делают B2B SaaS — кто-то вечерами после работы, кто-то на выходных.

А кто-то уже всерьёз прикидывает, как бы поскорее уволиться и уйти в свой продукт 🙃

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

И вот тут мы попадаем в очень старую ловушку, которая с AI просто стала выглядеть по-новому.

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

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

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

AI этот ограничитель почти убрал.

И получается, что AI увеличивает не только productivity, но и scope. Ты не делаешь тот же самый MVP в пять раз быстрее — ты очень часто начинаешь делать продукт в пять раз больше.

👉 Авторизация? Ну давай сразу через все возможные социальные сети.
👉 Дашборд? Умный, с автоматической генерацией всех возможных отчётов.
👉 Мобильное приложение? Почему бы и нет.
👉 AI assistant? Ну без этого сейчас вообще не модно.

Своего рода feature inflation, когда каждая отдельная фича стала настолько дешёвой, что кажется глупым её не сделать.

❗️Самая опасная фича сейчас — та, которую «можно быстро добавить».

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

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

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

И есть ещё забавный эффект.

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

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

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

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

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

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

В общем, довольно обычное выгорание. Не он первый, не он последний.

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

И вот слушаю я его и думаю, что дело-то не только в компании.

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

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

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

С работой ровно так же.

Этот человек сам выбрал работать в этой компании, сам выбрал не пушбэчить сроки, быть максимально полезным и доступным 24/7, отвечать на вопросы и снова и снова спасать ситуацию. Наверное, в какой-то момент ему это было интересно, он видел в этом смысл и получал от этого удовольствие.

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

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

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

❗️Компания может создавать условия для выгорания, но человек сам отвечает за то, где заканчивается его готовность эти условия принимать.

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

Потому что выгорание — это не только вопрос «что со мной сделала компания», но и «как я сам себе устроил эту работу».

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

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

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

Сменить компанию иногда правда помогает. Но если не изменить собственный способ работать — привычку всегда спасать и всегда быть доступным — очень легко через два года выгореть уже в новом месте.

А ты когда последний раз пушбэчил внутренний дедлайн? 😎

B2B SaaS сам себя не напишет, подумал я — и забросил блог на месяц 🙃

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

Первая ☝️ Если ближе к вечеру у меня стоят какие-нибудь митинги, идти на них не хочется совершенно. Ощущение такое, будто я весь день с кем-то разговаривал и к вечеру просто наговорился.

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

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

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

Так что ощущение не обманывает — я правда весь день разговаривал. Просто не с людьми.

А вторая проблема ✌️ посерьёзнее. Это количество решений, которые приходится принимать.

Есть такая штука — decision fatigue, усталость от принятия решений. Исследования говорят, что за день человек может принять ограниченное количество решений, в среднем что-то около 30 тысяч. И даже какой носок надеть, какого цвета и на какую ногу — это уже три решения из этих тридцати тысяч 🙃

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

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

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

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

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

И что ты делаешь, пока он пишет? Переключаешься на следующую задачу, открываешь следующую сессию, снова читаешь, снова споришь, снова выбираешь.

❗️Получается бесконечный цикл: план → решения → агент пишет → следующий план. Раньше между решениями лежал большой спокойный кусок работы, а теперь его из пайплайна просто выкинули.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А знаешь ли ты, как происходит запись подкаста?

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

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

Иван Чернов и Иван Елфимов, разработчики из «Ostrovok! Tech», делают подкаст «Два Ивана (название обсуждается)», в котором мне удалось поучаствовать.

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

В общем, очень необычный и новый для меня опыт такого рода подкастов, а послушать, что получилось, можно на:
💬 Mave в Telegram
🎙 Mave
🎵 Яндекс Музыка
📺 YouTube
📺 VK

P.S. На фотографии — мы с Иванами на записи этого подкаста в студии в Москве.

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

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

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

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

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

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

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

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

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

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

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

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

Ты же заметил, что на позапрошлых двух неделях я выпал и ничего не публиковал? 😢

Расслабился и обленился, подумал ты? А вот и нет! Я вписался в парочку подкастов, и на днях вышел один из них — хочу поделиться 🔥

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

Можно слушать, смотреть — или делать всё сразу. Осталось только выбрать платформу:
📺 YouTube
📺 VK Видео
🎙 Аудио подкаст
🎵 Яндекс подкаст
📺 Rutube

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Вот сейчас проведём 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°, если, например, разработчик был десантирован на внешний проект и фидбэк к тебе не доходил. Но чудес ждать не стоит — лучше сам иногда заходи к смежникам и спрашивай — всё ли ОК?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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