Быть Лидом 😎

А знаешь ли ты, как происходит запись подкаста?Вот если очень утрированно, то путь таков. Выбирается тема подкаста, интервьюер составляет список вопросов согласно этой теме, и мы согласовываем их с PR. Потом я накидываю тезисы ответов и тоже согласовываю с PR. Встречаемся, записываемся. Первая редактура интервьюера — он там что-то вырезает, потом согласовываем с PR, и они тоже что-то просят вырезать. И, о счастье, если мы отклоняемся от списка вопросов и поговорим о чём-то отвлечённом, и это тоже не будет вырезано 😢Как ты понял, это мероприятие по большей части требует предварительной подготовки. Что было совсем не так на подкасте, про который я вам тут хочу рассказать. Я уже тизернул вам, что вписался в два подкаста — про один уже рассказал. Теперь про второй 😎Иван Чернов и Иван Елфимов, разработчики из «Ostrovok! Tech», делают подкаст «Два Ивана (название обсуждается)», в котором мне удалось поучаствовать.Я бы, конечно, хотел сказать, что тема подкаста была про инциденты в ИТ и как мы в Ситидрайв построили процесс работы с технологическими инцидентами, но ребятам удалось создать невероятно ламповую обстановку, что я даже первый куплет гимна Узбекистана по памяти пропел.В общем, очень необычный и новый для меня опыт такого рода подкастов, а послушать, что получилось, можно на:💬 Mave в Telegram🎙 Mave🎵 Яндекс Музыка📺 YouTube📺 VKP.S. На фотографии — мы с Иванами на записи этого подкаста в студии в Москве.

Мы с тобой обсудили модель менеджеров по Адизесу, а теперь начнём обсуждать каждый тип по отдельности. Начнём с Производителя (Producer, буковка P).Производитель — это менеджер, который знает, как всё устроено, глубоко понимает специфику своего дела и умеет, используя эти знания и возможности, быстро решать любые задачи и приносить максимальный результат здесь и сейчас.Производителю нужна чёткая и измеримая цель, и тогда он будет мотивирован на её достижение. Если нет конкретных показателей успеха, то Производитель теряет интерес и демотивируется — он не понимает, что именно нужно достичь и как это влияет на успех компании. Он не любит обсуждений и советов, предпочитает единолично и быстро принимать решения, считая свои мотивы понятными и очевидными, а при несогласии с ним — настойчиво и авторитарно продавливает своё мнение. Раздражается и теряет мотивацию, когда кто-то вмешивается в его работу, пытается контролировать или тормозит.Производитель не мыслит стратегически, а его решения краткосрочны. Он привык использовать знакомые инструменты и не склонен к внедрению инноваций или созданию чего-то нового.Задача, выполненная собственными силами, приносит Производителю наибольшее удовлетворение, а отсутствие признания его заслуг демотивирует.В своей крайней форме (P---) Производитель превращается в Героя-одиночку 🦸Герой-одиночка — это трудоголик, который берёт всю работу на себя. Он решает самые сложные, важные и срочные задачи, а его подчинённые — наблюдатели на подхвате. Когда Герой осознаёт, что не справляется, он, так уж и быть, в последний момент сбрасывает часть горящих задач на подчинённых. В остальное время они без дела слоняются по коридорам, потому что у Героя-одиночки нет ни времени, ни интереса заниматься административными вопросами.Как работать с руководителем-производителем❓👉 Будь кратким и конкретным: оперируй фактами и цифрами, начинай с сути, а не с контекста👉 Не начинай с проблем — начни с решения. Сначала расскажи, что предлагаешь, а потом — как ты

Ты же заметил, что на позапрошлых двух неделях я выпал и ничего не публиковал? 😢Расслабился и обленился, подумал ты? А вот и нет! Я вписался в парочку подкастов, и на днях вышел один из них — хочу поделиться 🔥Мы встретились с Олей и за час поразмышляли о том, кто такой СТО, стоит ли вообще идти по этой карьерной дорожке и почему роль технического директора бывает такой одинокой.Можно слушать, смотреть — или делать всё сразу. Осталось только выбрать платформу:📺 YouTube📺 VK Видео🎙 Аудио подкаст🎵 Яндекс подкаст📺 RutubeВсе больше втягиваюсь в тему подкастов — сидишь, разговариваешь о чём-то интересном, это записывают, монтируют, выкладывают, обсуждают 😎Если ты хостишь подкаст — приглашай меня обязательно, буду рад составить компанию в выпуске.

В жизни каждого руководителя наступает такой момент, когда нужно продать свою идею своему руководителю — будь то инициатива по внедрению новой технологии или изменению процесса.И вот здесь важно понимать, что успех этой «продажи» зависит не столько от самой идеи, сколько от того, кому ты эту идею продаёшь и как ты это делаешь. Ведь по типу управленческого мышления все руководители разные, и то, что вдохновит одного, может вызвать неприязнь и раздражение у другого 😡Существует множество разных практик того, как можно «упаковать» идею и какую лидерскую технику коммуникации выбрать для чтобы её «продать».В этой заметке я хочу рассказать про модель Адизеса. Точнее, этой заметкой я открываю серию из пяти публикаций про эту модель и её типы руководителей.Ицхак Кальдерон Адизес — писатель и бизнес-консультант, сформулировал концепцию, согласно которой любой руководитель в любой компании выполняет четыре функции:👉 приносит результат, выступая производителем (Producer)👉 строит порядок и процессы, выступая администратором (Administrator)👉 генерирует идеи и указывает направление развития, выступая предпринимателем (Entrepreneur)👉 соединяет людей и создаёт систему ценностей, выступая интегратором (Integrator)Адизес утверждает, что только идеальный менеджер, у которого одновременно прокачаны все четыре функции, может привести компанию к успеху. Правда, Адизес ещё отмечает, что таких идеальных менеджеров не существует, потому что невозможно одновременно владеть всеми четырьмя функциями на высоком уровне. Чего уж говорить — по этой модели даже три функции выполнять успешно параллельно видится мне крайне затруднительным.Поэтому хороший менеджер — это тот, кто выполняет две функции на отлично, а остальные две на хорошо.И получается, что у нас есть руководители, у которых какая-то функция развита, а какая-то — нет. Адизес предложил систему кодирования руководителей по четырём буквам 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, который не включая голову выкатывает всё на прод и считает свои задачи закрытыми.А насколько отказоуст

И вот твоя первая рабочая неделя на позиции лида в новой компании почти подходит к концу — ты познакомился с ребятами из своей новой команды и уже даже успел погрузиться и дать архитектурные комментарии по нескольким запускаемым фичам.И вдруг — бац 💥! Тебе пишет разработчик: «Привет, я хочу уволиться».Не проходит и месяца, как на созвоне с другим разработчиком он говорит, что у него оффер, и он тоже хочет уйти из компании.Прошёл всего месяц, а двое из шести членов команды уже на выходе. У тебя тревога, тебе кажется, что ты не справляешься, и в голове мысли: а что думает мой руководитель? Мол, я пришёл, создал кризис и все разбежались?На самом деле кризис создал прошлый руководитель команды. Скорее всего, именно из-за этого его и уволили — низкий перформанс команды и его низкая вовлечённость завели команду в тупик, ребята выгорели и уже настроились на выход. Его увольнение лишь заморозило эту ситуацию на некоторое время. Но обычно, если человек решил уйти — он уйдёт. Появление нового руководителя лишь становится идеальным триггером для тех, кто давно собирался уйти.Что делать, шеф?☝️ Спрогнозируй рискиПойми, какие ребята за что отвечают и какой экспертизой обладают. Определи, кто может уйти и какие риски это несёт — какие проекты пострадают и какие знания и компетенции команда может потерять.Составь план минимизации этих рисков, например это может быть шэринг знаний или перераспределение задач. Постепенно реализуй этот план.✌️ Дай оттоку оттечьНе нужно бросаться удерживать выгоревших сотрудников любой ценой. Отток — это прекрасная возможность пересобрать команду. Чем быстрее уйдут те, кто не готов работать дальше, тем быстрее ты перезапустишь команду, и она начнёт приносить пользу бизнесу.Говори ребятам спасибо за прошлые заслуги и спокойно отпускай их покорять новые горизонты.🤟 Коммуницируй внутри командыТем не менее кризис должен быть контролируемым. Уход людей почти всегда порождает в команде слухи и вопросы. Тут важно ничего не замалчивать, а честно и открыто п

Пару недель назад я рассказывал Фаре Рословец про работу каршеринга. Мы обсудили устройство блоков телеметрии, инциденты с прямыми и косвенными убытками, но больше всего Фарю заинтересовала тема масштабирования команд.Я пришёл в Ситидрайв в апреле 2022 года. Тогда ИТ-департамент насчитывал около 30 человек, из которых примерно 12 были в одной большой команде NodeJs-разработчиков во главе с лидом.И вот с перформансом этой команды была большая проблема. Лид не имел опыта управления таким количеством людей и умения фокусировать их на результате. В итоге задачи распределялись хаотично: вчера разработчик писал бэкенд для мобильного приложения, сегодня он получал задачи по обработке телеметрии, а завтра менеджер уже заготовил задачки по внешним интеграциям.Постоянное переключение контекста мешало ребятам погружаться в доменные области. Каждый раз при возвращении к коду приходилось заново разбираться в изменениях и искать место, куда вставить свои пару строчек. Неудивительно, что такие переключения почти всегда порождали баги и инциденты.Функциональные командыЧтобы решить описанные выше проблемы, я решил перестроить бэкенд: выделил ключевые домены, вокруг которых велась активная разработка, и сформировал вокруг них отдельные функциональные команды вместе с лидом.Так появились команды, отвечающие за:👉 финансы (эквайринг, биллинг, рейтинги, программы лояльности, бонусы и начисления)👉 бэкенд для мобильного приложения👉 телеметрию (интеграция с блоками и обработка данных)👉 бэк-офис (админки и системы управления парком)Каждая команда полностью отвечала за свой домен: выносила бизнес-логику из монолита, сокращала технический долг, внедряла мониторинги и алертинги, дежурила и самостоятельно закрывала инциденты.Направления разработкиЗа следующие полгода бизнес-инициатив стало значительно больше, и это привело к росту новых доменов и команд вокруг них.Например:👉 команда бэк-офиса разделилась на две: одна отвечала за админки и внутренние сервисы, вторая — за системы управления п

Как-то один из моих лидов несколько месяцев не мог закрыть позицию в свою команду. И не то чтобы позиция была какая-то особенная — рядовой Golang-разработчик. Да и с рынком тогда всё было нормально — собеседования шли регулярно. Но каждый раз у него было «что-то не то»: то кандидат не до конца знаком с нашим стеком, то глубины знаний Golang не хватало, то где-то по софтам недотянул.Месяцы шли, задачки копились, а мы всё искали идеального кандидата... 🫠Как-то я читал про концепцию руководителей типа А и B:👉 Руководитель типа А — это лидер, который не боится конкуренции и нанимает людей не слабее, а иногда даже сильнее себя👉 Руководитель типа B — напротив, опасается нелояльных сотрудников, поэтому предпочитает брать людей слабее, чтобы сохранить контрольЕсть даже целая теория о том, что руководитель типа А собирает вокруг себя команду А-игроков, а руководитель типа B — команду С-игроков.Но у руководителей типа А, особенно начинающих, есть своя ловушка — погоня за идеальным кандидатом. Они пытаются найти человека, который будет соответствовать всем ожиданиям и идеально решать все задачи.Но идеальных кандидатов (может быть, даже к счастью) не существует. Каждая позиция уникальна, каждая команда со своими особенностями, и всегда найдётся то, чего кандидату будет не хватать для «идеального» соответствия.Поэтому, чтобы не попасть в такую ловушку, мой совет 💡 — перестань искать идеальных, а сфокусируйся на перспективных.Вот три вопроса, которые я задаю себе после каждого собеседования:☝️ Чего именно кандидату не хватает, чтобы быть максимально подходящим для этой позиции?Это могут быть конкретные технологии, практики и подходы. Или, например, умение обосновывать и отстаивать свою позицию, «продавать» решение команде, справляться с задачами в условиях неопределённости.✌️ Смогу ли я научить этому кандидата?Готов ли я инвестировать своё время и силы в его развитие? Будет ли у меня достаточно ресурсов? Смогу ли подключить к этому кого-то из команды?🤟 Готов ли сам кандидат

Только ленивый ещё не высказал свой прогноз о том, как AI изменит рынок разработки программного обеспечения. Эксперты рынка звучат так же убедительно, как и финансовые эксперты в 2014 году, которые уверяли нас, что рубль укрепляется и не надо покупать доллары… а потом случился «чёрный вторник», и доллар с 30 рублей за штуку взлетел до 80.Радует одно, ребята, которые выкрикивали на каждом углу, что, мол, «скоро AI полностью заменит разработчиков», разочаровались в волшебности AI и подостыли. И сейчас таких утверждений всё меньше и меньше.Но всё ещё я слышу другое утверждение — «middle и junior разработчики скоро будут не нужны, останутся только senior’ы». И вот, мне оно тоже кажется неубедительным. Давайте объясню почему.Понятие senior неоднородно. Того, кого считают супер-крутым senior’ом в условной веб-студии, в большинстве случаев не возьмут даже на позицию junior в FAANG.Почему? Да потому что наш супер-крутой senior из веб-студии может элементарно не знать, как построить масштабируемую архитектуру для проекта, чтобы выдержать 10k RPS. Он вполне может не суметь спроектировать распределённое файловое хранилище, чтобы сохранить все фотографии из VK, или быстро реализовать алгоритм Дейкстры.А почему? Да потому что ему это и не нужно! У него нет таких задач. Всё, что требуется, так это быстро «на коленке» наклепать интернет-магазин или сайт-визитку для клиента и выложить это в прод. Ни миллионной аудитории, ни задачи коммивояжёра там не будет.И вот если мы все перестанем писать код и превратимся в промпт-инженеров, будем лишь валидировать на галлюцинации и корректировать решения от LLM, то со сложностью задач ничего не поменяется. Будут простые задачи — типа, запромтить проект уровня интернет-магазина для продажи носков в Саратове. И будут сложные задачи — типа, запилить децентрализованную систему распределённых транзакций. И вот для этих задач нужны будут промпт-инженеры разного уровня.Senior Prompt-Engineer’ами не рождаются — ими становятся.И поэтому будут и senior

Фаря Рословец позвала меня на стрим 🍿Будем говорить про масштабирование инженерных команд, выстраивание процессов и развитие инженерной культуры. Я расскажу на примере Citydrive, как за 3 года отмасштабировал ИТ-команду в 5 раз.Встречаемся 4 сентября (завтра!) в 19:00 по Москве.👉 Зарегистрироваться на стрим

Как-то, работая в «Ситимобил», я проходил тренинг по Ситуационному лидерству (SLII®), и вот этот тренинг я до сих пор считаю лучшим, что проходил. Не столько из-за подачи и организации тренинга, хотя и это было на высшем уровне, сколько из-за самой концепции — она тогда соединила разрозненные кусочки знаний о развитии сотрудников и делегировании задач у меня в голове в единую картину и дала готовый инструмент, который можно было применять сразу после тренинга.Тренинг базировался на модели ситуационного лидерства, которую разработали американские исследователи поведения Paul Hersey и Kenneth Blanchard и описали в своей книге «Management of Organizational Behavior» аж в 1969 году, и сейчас у неё уже десять переизданий!В чём идея?Идея в том, что любой человек, который переходит на новую должность, берётся за новый проект или открывает для себя новую область, неминуемо проходит через четыре уровня зрелости (Maturity Levels).Например, ты поручаешь своему разработчику создать платформу для нагрузочного тестирования сервисов.☝️ M1: Новичок-энтузиаст (не может, но хочет)Это задача, о которой он давно мечтал: ресёрч, выбор инструмента, настройка окружения, первые тесты. Всё новое, ничего не понятно, у него горят глаза и полные штаны энтузиазма, он готов вкладываться, но опыта, знаний и компетенций в этой области у него пока нет.✌️ M2: Разочаровавшийся ученик (не может и не хочет)Всё оказалось не так увлекательно, как казалось вначале, нормальных инструментов нет, из коробки ничего не работает, надо допиливать, тесты падают, нормального препрод-окружения, чтобы гонять тесты, нет. Энтузиазм угас, горящие глаза затухли.🤟 M3: Способный, но осторожный исполнитель (может, но не хочет)Инструмент найден, как-то допилен и интегрирован, окружение как-то работает, и тесты даже запускаются и не падают. Опыт, набитый шишками, уже имеется, но вот большого желания доводить это до совершенства и развивать почему-то нет.🖖 M4: Самостоятельный профессионал (хочет и может)Тут он уже эксперт п

На прошлой неделе мы батлились с Катей Лысенко, задавая друг другу управленческие кейсы. Если тебе не удалось попасть на стрим, то можешь посмотреть его запись на YouTube.Мы успели рассмотреть с Катей 8 кейсов, и тут я бы хотел детальнее обсудить один из них. Как мне кажется, это один из старых, популярных, на вид простых кейсов, но он полностью раскрывает способность лида действовать структурно и поэтапно, не хватаясь за всё подряд и не решая проблем, которых нет.Итак, кейс 💼Ты вышел на работу лидом команды.Руководитель разработки говорит, что уволил прошлого лида из-за низкой скорости работы команды, и твоя задача на испытательный срок — разобраться с этой проблемой.Твои действия?Что делать, шеф?Во-первых ☝️, уточни у руководителя, по каким метрикам и критериям он оценивает «низкую» и «высокую» скорость командыИ тут могут быть две развилки:👉 Субъективное восприятие: руководитель оторван от контекста работы этой команды, не погружён в её детали, и его оценка скорости субъективна — базируется на прошлом опыте, который не релевантен этой команде.👉 Объективное восприятие: руководитель хорошо понимает команду и её специфику, может быть, даже сам когда-то был выходцем из этой команды и может дать реальную оценку сложности той или иной задачи. Но сейчас что-то сбойнуло, и работа идёт медленнее, чем раньше.Во-вторых ✌️, выслушай руководителя и возьми время на собственный анализ (около недели). Погрузись в команду и проведи аудит текущего состоянияТут важно понять:👉 Есть ли у команды метрики и показатели (velocity, capacity, throughput, cycle time, lead time)?👉 Как команда оценивает задачи? Насколько точны оценки: не завышены ли, не занижены ли?В-третьих 🤟, накидай гипотезы улучшений и изменений👉 Если метрик нет — надо их внедрить👉 Если у команды постоянное переключение между задачами — переработай систему приоритизации👉 Если слабое описание задач заставляет команду много коммуницировать — проработай шаблон задач👉 ... в конце концов, может быть там CI/CD, выполне

Я в ИТ лет 20, 15 из которых ежедневно писал код, 10 из них — на PHP.Последние лет 5 про PHP я ничего не слышал — в Ситимобил мы ушли на Golang, а в Ситидрайв PHP никогда и не было — JavaScript/TypeScript, переходящий в Golang.А оказывается, мало того что PHP живее всех живых 🔥, так ещё и в самом расцвете сил!И даже ребята запускают интересные конференции про PHP, а именно — Пых.конф’25, про которую меня попросил рассказать Пётр Мязин. Из уважения к PHP-сообществу и Петру не могу не рассказать!С Петром мы знакомы довольно-таки давно, и я даже в 2018 году на его подкасте «Пятиминутка PHP» рассказывал про JWT (рекомендую послушать 🔉).Так вот, Пых.конф’25!19 сентября, Москва, Конгресс-центр ЦМТ (+ он-лайн).👉 Асинхронность и протоколы для неблокирующего I/O👉 RAG в PHP-бэкендах и круглый стол «Кодим с ИИ»👉 И... аж олдскулы свело: Yii3, Doctrine, Swoole, WordPress и Битрикс!Билеты можно купить вот по этой ссылке.

Так уж исторически сложилось, что я собеседую всех кандидатов на руководящие позиции в свой ИТ-департамент в Ситидрайв. Это небольшая встреча-знакомство на 30–40 минут, на которой я составляю второе мнение о кандидате и передаю его нанимающему менеджеру для оценки рисков. Сейчас у нас открыто несколько таких позиций, поэтому за последние несколько недель у меня было достаточно встреч, чтобы заметить одну тенденцию у некоторых кандидатов.В этом потоке мне отчётливо запомнились два кандидата. Опыт лидерства у них только на последнем месте работы, и лидами они там стали не за выдающиеся управленческие навыки и не за умение организовывать работу, развивать людей, собирать команду и отвечать за результат, а за то, что были самыми опытными разработчиками в команде и лучше всех понимали, как устроен проект. Так, после ухода лида их кто-то назначил лидом вместо ушедшего.И вот третий такой кандидат и побудил меня написать эту заметку. Он — крепкий технарь, но точно не руководитель. И я ему задаю вопрос: «Слушай, а если вместо руководящей позиции мы тебе предложим инженерную, ты согласишься?». Тут он сразу приободрился, одобрительно начал кивать головой и подчеркнул: «Это будет даже лучше!». Я ему начал объяснять, что в этом случае мы будем оценивать его как инженера, и есть немаленькая вероятность, что именно столько, сколько он хочет, мы предложить не сможем, и спросил – готов ли он двигаться по своим ожиданиям. Тут я получил категоричный отказ, мол, он уже привык к такому уровню заработка и меньше получать никак не хочет.Что говорить, и в моей практике был аналогичный случай, когда я пришёл в небольшую команду, где был супер-гуру-разработчик, который знал проект до последнего винтика, спасал сервис при инцидентах и писал сложный код. Людей стало чуть больше, и я назначил его лидом небольшой команды. Но вместо того, чтобы развивать команду и фокусировать её на достижении результата, он продолжал тушить пожары и писал код за троих. Год я вкладывался в него и растил из него л

Я тут напросился к Саше Поломодову на подкаст.Если кто не знает Сашу — прямо сейчас рекомендую вбить в YouTube «Поломодов» и наслаждаться бесконечным количеством роликов про то, как Саша рассказывает, как проводить и как проходить секции system design интервью.С Сашей я познакомился пару лет назад на выезде CPO&CTO-клуба Avito в Бодруме (мы, кстати, на фото оттуда), и до сих пор не перестаю восхищаться его продуктивностью и энергией.Поговорили очень лампово про мой карьерный трек, как я запускал биржу контента 15 лет назад и сделал своё казино с крестиками-ноликами 🙈В такую серую дождливую летнюю погоду самое то — укутаться в плед, взять чай с лимоном и 2,5 часа послушать подкаст.Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.