Code of Leadership

Alexander Polomodov

Подкаст Александра Поломодова, технического директора и Fellow. В каждом эпизоде есть приглашенный гость-эксперт, с которым идет разговор про менджмент и лидерство.

  1. 3 days ago

    Где у CTO больше свободы — в стартапе или корпорации с Кириллом Евсеенко

    В стартапе CTO может утром принять решение, а вечером увидеть его в продукте — но людей, денег и времени почти всегда не хватает. В корпорации ресурсов гораздо больше, но любое серьёзное изменение приходится проводить через множество зависимостей. Так где в итоге больше свободы? И что важнее — свобода принимать решения или способность реально менять большую систему? 11 сентября в 18:00 МСК будет новый прямой эфир Code of Leadership с Кириллом Евсеенко — CTO музыкального сервиса «Звук». Кирилл начинал с заправки картриджей и системного администрирования, работал над туристическими сервисами и медицинским стартапом, руководил технологиями и продуктом в START, а теперь — CTO «Звука». Поэтому стартап и корпорацию будем сравнивать не по привычным мемам про скорость и бюрократию, а по реальным решениям, ограничениям и цене ошибки. У Кирилла есть свой канал https://t.me/tak_ya_vse_pridumal Поговорим о том: Какие привычки из стартапа помогают на большом масштабе, а какие превращают самого CTO в узкое место; Где согласования действительно защищают от дорогой ошибки, а где просто размывают ответственность; Какие решения CTO должен оставлять за собой, а какие принципиально не должен принимать; Как перейти от личного контроля к системе сильных лидеров и при этом не потерять контакт с инженерной реальностью; Что вообще происходит со скоростью, ответственностью и влиянием руководителя, когда команда вырастает от десятков до сотен человек. Отдельно проверим формулу «быстрый стартап — медленная корпорация». Возможно, с ростом масштаба скорость никуда не исчезает. Просто раньше ты ускорял компанию тем, что быстро действовал сам, а теперь — тем, что создаешь систему, в которой сотни людей могут быстро принимать хорошие решения без тебя. И попробуем ответить на главный вопрос: в какой момент технический руководитель перестает быть главным инженером и становится CTO? Timeline 00:00 - Где у CTO больше свободы 02:04 - Путь из системного администрирования в CTO 10:19 - Медицинский стартап и рост команды START 19:48 - Стартап: широкие роли и быстрые решения 27:53 - Когда выгодно строить свою платформу 31:38 - Деньги и экономика технологических решений 43:51 - Полгода на понимание правил корпорации 50:39 - Влияние через руководителей и платформенные команды 57:45 - Техническая карьера без обязательного менеджмента 1:06:49 - Кто решает, как быстро и на каких данных 1:14:49 - Что может остановить готовое решение 1:17:16 - Как закрывать ненужные инициативы 1:21:20 - Почему инициатива бывает невыгодна руководителю 1:24:17 - Чему стартап и корпорация могут научиться друг у друга 1:28:39 - Расти к ответственности, а не к должности

    Где у CTO больше свободы — в стартапе или корпорации с Кириллом Евсеенко
  2. 5 days ago

    Первые 90 дней CTO

    В среду в 11:00 расскажу в прямом эфире про первые 90 дней технического директора. Начну с небольшого переворота: первый рабочий день — уже середина перехода. В докладе разберу весь маршрут: - Как выбирать задачу, а не красивый шилдик; - Зачем до выхода договориться о полномочиях, ресурсах и критериях успеха; - Почему первый месяц лучше потратить на сбор реальной карты компании, а не на формирование портфеля изменений; - Как к 90-му дню выбрать одну-две системные ставки, показать первый результат и не пропустить красные флаги. Это не универсальный чек-лист «успешного успеха», а практическая модель: исследование → взаимный контракт → диагностика → первые изменения. И ещё: компания в эти три месяца тоже проходит испытательный срок. Timeline 00:00 - Первые 90 дней начинаются до первого рабочего дня 03:44 - Почему титул CTO не определяет содержание работы 06:26 - Исследование рынка и выбор типа карьерного перехода 10:22 - Какие публичные сигналы собирать о компании 14:13 - Как связаны деньги бизнеса и технологическая зрелость 18:35 - Почему оргструктура не показывает реальную карту влияния 23:04 - Интервью как взаимная проверка ожиданий 25:20 - О чём договориться до выхода: полномочия, ресурсы и критерии 29:32 - Первый месяц: наблюдать и слушать 39:55 - Семь направлений диагностики здоровья организации 42:00 - Что нужно понять и зафиксировать к 30-му дню 45:34 - Как выбрать одну-две системные задачи на дни 30–90 47:52 - Почему стратегия до диагностики приводит к проблемам 51:01 - Красные флаги и пересмотр договорённостей 57:50 - Итоговая модель первых 90 дней CTO

    Первые 90 дней CTO
  3. 5 days ago

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

    Код писать становится заметно быстрее. Но если всё большую часть реализации можно делегировать AI-инструментам, что тогда остаётся ядром работы программиста: знание синтаксиса, инженерное суждение или ответственность за продукт целиком? В новом выпуске Code of Leadership попробуем разобраться в этом вместе с Глебом Михеевым — CPO ГигаАгента в Сбере. Глеб в коммерческой разработке с 2003 года: работал в NVIDIA и Skillbox, основал и девять лет развивал студию заказной разработки, восемь лет отвечал за программу FrontendConf, а сейчас руководит программными комитетами AgenticDevConf и AI Native Conf. Ещё Глеб ведёт отличный Telegram-канал [«Уставший техдир»](https://t.me/tired_glebmikheev), где пишет про агентную разработку, инженерную культуру, управление командами и продукт. Поговорим о том: какие изменения уже происходят в разработке ПО, а что пока остаётся красивым прогнозом; чем эти изменения обусловлены и почему дело не сводится к появлению ещё одного инструмента; как меняются требования к разработчику и чем продуктовый инженер отличается от человека, который просто закрывает задачи; что делать с джунами, если типовые стартовые задачи всё чаще автоматизируются, и как готовить молодых инженеров без искусственной «теплицы»; как опытному разработчику учиться, пробовать новые подходы, сохранять техническую глубину и не отставать от прогресса; какой может стать роль программиста в ближайшие три года — и что здесь пока слишком рано выдавать за факт. Отдельно хочу проверить границу здравого продуктового мышления. Продуктовый инженер — это специалист, который понимает проблему пользователя и отвечает за результат, или просто удобное название для человека, которому предлагают одновременно побыть продактом, аналитиком, архитектором и разработчиком? Если у вас есть вопросы к Глебу или собственные примеры того, как уже меняется работа разработчика, приносите их в комментарии. Timeline 00:00 - Глеб Михеев: будущее программистов и продуктовый инженер 02:34 - Полгода инженерной работы после управления командами 04:05 - Когда GPT-3.5 показал, что обратного пути нет 15:20 - Параллельная работа с агентами и дофаминовая петля 22:24 - Почему продуктовый инженер существовал и до AI 26:10 - Как большие организации будут переходить к агентной разработке 34:07 - Как меняется состав автономной продуктовой команды 42:00 - В пять раз быстрее выпускать изменения — не значит создавать больше ценности 51:26 - Новые ограничения: исследование потребностей и эксплуатация 58:35 - Почему опытному инженеру перемены могут даваться тяжелее 1:00:29 - Задача инженера — решать проблемы, а не писать код 1:05:11 - Ценность замысла, стратегии и проектирования системы 1:08:57 - Что должен знать начинающий инженер 1:18:30 - Почему готовый результат больше не доказывает профессиональный рост 1:39:03 - Любопытство, возможности и месяцы практики с AI #CodeOfLeadership #AI4SDLC #Engineering #Leadership #Product #Career

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

    Как действовать среднему бизнесу с AI, которому «по-науке» дорого?

    У среднего бизнеса с AI есть неприятная развилка. Лаборатория, платформа и команда редких специалистов — тяжёлый входной билет. Но личные подписки, разрозненные демо и один «AI-волшебник», работающий по вечерам, ещё не складываются в практику. Сегодня в 17:00 проведем прямой эфир (https://www.youtube.com/watch?v=S5-I72_K004) и обсудим это вместе с Александром Воронцовым, партнером @revelio_tech и автором канала AI Subjects (@aisubjects, изучает когнитивные ошибки при работе с ИИ). В прошлом разговоре (https://www.youtube.com/watch?v=gpYZr8RQlSw) мы дошли до важной точки: внешний эксперт уйдёт, а внутри должен остаться человек, который понимает задачу, проверяет результат и продолжает изменение. Теперь разбираемся, как получить и удержать эту способность, если сильные люди заняты основной работой, а нанимать AI-департамент рано. Мы обсудим: — как отличить задачу для AI от сломанного процесса, плохих данных и управленческого долга; — как выбрать первый сценарий, снять исходную метрику и заранее определить критерии приёмки и остановки; — кого растить внутри, кого нанимать или временно брать с рынка и что покупать готовым; — как освободить время доменного эксперта и не превратить AI в его вторую смену; — что нужно кроме учётных записей: доступы, тестовые примеры, журнал ошибок, ручное подтверждение и откат; — как считать входной билет: лицензии, интеграции, внутреннее время, контроль качества, поддержку и цену ошибки; — когда понравившийся сотрудникам пилот всё равно нужно закрыть. Timeline 00:00 - Александр Воронцов: AI без лаборатории и многомиллиардного бюджета 01:52 - Что считать средним бизнесом и практическим внедрением AI 05:55 - Маржа, логистика и конкретная проблема как отправная точка 10:10 - Почему доступ к Claude или Codex ещё не меняет работу 12:25 - Удачный кейс торговой компании: начать с сотрудников 14:55 - Конкурс прототипов, денежная мотивация и системный аналитик 16:56 - Чувствительные данные и ограничения облачных моделей 20:20 - Кому поручить ответственность за внедрение AI 22:30 - Неоднозначный кейс растущей аутстаффинговой компании 27:40 - Почему разрозненным инициативам нужен внутренний IT-партнёр 32:00 - Один лидер, внешняя команда или несколько специалистов 36:40 - Почему ускорение написания кода не ускоряет весь процесс 39:30 - Как небольшой масштаб помогает запускать изменения за часы 48:50 - AI как новый слой автоматизации: работа с дебиторской задолженностью 59:00 - Короткая диагностика, первые задачи и ценность живого диалога #CodeOfLeadership #AI #Consulting #Leadership #Management #DigitalTransformation

    Как действовать среднему бизнесу с AI, которому «по-науке» дорого?
  5. 2 Sept

    Джун после кода - как растить инженеров, когда исполнение уезжает агентам

    AI-агенты сделали первый вариант решения быстрым и дешёвым. Джун теперь может за короткое время подготовить убедительный прототип, тесты и pull request. Но готовый артефакт ещё не доказывает, что инженер понимает систему, способен проверить результат и готов отвечать за последствия изменения. Как в этих условиях отличить выполнение от настоящего навыка? Где начинающим инженерам набирать опыт, если агенты забирают задачи, с которых раньше начиналась карьера? И как перестроить найм, наставничество и развитие, чтобы ускорение не разрушило инженерную лестницу? В этом выпуске Александр Поломодов разбирает, как AI-агенты меняют путь от джуна до самостоятельного инженера. В выпуске: чем отличаются скорость выполнения, компетентность и ответственность; почему одинаковые патчи могут нести совершенно разный сигнал об уровне инженера; как сохранить продуктивное усилие и не делегировать агенту сам процесс обучения; почему критерий правильности должен оставаться у человека; как измерять рост через радиус самостоятельности и серию рабочих эпизодов; почему ответственность не заканчивается после merge и должна доходить до наблюдаемого результата; как перестроить техническое интервью вокруг полного рабочего цикла: плана, истории решений, diff, тестов и меняющихся ограничений; зачем компании формальная система наставничества, если она продолжает нанимать джунов; как разделить ответственность между наставником, менеджером и платформенной командой; какие метрики показывают не только сегодняшнюю полезность, но и будущую самостоятельность инженера. Timeline 00:00 - Зачем заново определять путь джуна в эпоху AI 01:07 - Почему одинаковое демо не означает одинакового понимания системы 02:38 - Артефакт, рабочая задача и развитие системы 08:22 - Что исследования говорят об ускорении начинающих инженеров 12:30 - Почему опыт в конкретной задаче важнее формального грейда 17:51 - Почему ускорение написания кода теряется на пути к выпуску 19:08 - Джуну отдали весь продукт: как справиться с ответственностью 22:27 - Как агенты убирают нижнюю ступень инженерного обучения 25:44 - Как делегировать работу агенту и сохранить собственное суждение 30:21 - Рост от готового артефакта к ответственности за систему 36:43 - Стабильность, защитные ограничения и инженерные компромиссы 42:55 - Ответственность мидла и портфель решённых инженерных задач 46:17 - Интервью, на котором видна работа кандидата с агентом 49:30 - Как превратить ученичество в работающую систему 51:57 - Код дешевеет, инженерное суждение — нет

    Джун после кода - как растить инженеров, когда исполнение уезжает агентам
  6. 31 Aug

    Последние 90 дней в компании начинаются до заявления

    Мы много говорим о первых 90 днях в новой роли. Мне захотелось разобрать обратную сторону перехода — последние 90 дней в компании. 31 августа проведу сольное выступление Code of Leadership #Ω — выпуск «Омега». Оно не только про увольнение. У этого процесса есть три равноправных исхода: остаться в пересобранной роли, перейти внутри компании или уйти. Поговорим о том, как не принять карьерное решение после одной плохой недели; понять, что именно перестало работать; описать следующую роль через ответственность, а не должность; проверить внутренние возможности и внешний рынок; выбрать исход и передать управление так, чтобы старая роль больше не зависела от вашего незримого присутствия. Отдельно разберу важную для руководителей часть: документ не равен переданному знанию. Сначала новому владельцу нужно передать право принимать решения, затем — контекст, отношения, рабочие ритмы и доступы. И дать ему начать управлять ещё до вашего последнего дня. Для меня главный тезис такой: последние 90 дней — это не обратный отсчёт до увольнения. Это управляемый переход между двумя профессиональными главами. И следующие 90 дней фактически начинаются ещё до завершения предыдущих. Слайды и материалы: https://polomodov.tech/2026-08-31-last-90-days-in-company/ #Management #Leadership #Career #Engineering #CodeOfLeadership

    Последние 90 дней в компании начинаются до заявления
  7. 24 Aug

    Что остаётся дефицитным, когда код становится дешёвым с Сергеем Бережным

    Что остаётся дефицитным, когда код становится дешёвым: инструменты, инженерное мышление или доверие между компанией и разработчиками? В очередной серии подкаста Code of Leadership поговорим с Сергеем Бережным — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и одним из соавторов методологии БЭМ (https://veged.ru/). Сергей работает в Яндексе с 2005 года и прошёл путь от разработки интерфейсов до DevRel, open source и образования. Но разговор будет не про карьерную ретроспективу. Хочу понять, как техническое лидерство выходит за границы одной команды и проявляется в методологиях, платформах, работе с сообществом и публичной ответственности. Обсудим: - Зачем бизнесу DevRel и чем измерять его результат; - Почему внутреннюю технологию стоит открывать миру и как выбирать проекты для open source - Как разработка проходит путь от автодополнения к AI-агентам и harness-системам; - Что происходит с ролью руководителя, когда частью команды становятся агенты; - Кого и чему учить, если привычные entry-level задачи всё чаще забирает AI. Смотрите выпуск и приносите в комментарии свои вопросы и примеры.

    Что остаётся дефицитным, когда код становится дешёвым с Сергеем Бережным

About

Подкаст Александра Поломодова, технического директора и Fellow. В каждом эпизоде есть приглашенный гость-эксперт, с которым идет разговор про менджмент и лидерство.