TechnologyBusinessManagementEducationSelf-Improvement

Code of Leadership

Alexander Polomodov

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

Play

Open in

34 episodes
Avg 1 hr 28 min
Russian

Episodes 34

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

S2 · E28
October 23 · 1 hr 28 min
Агенты пишут код. Как понять, что разработка стала эффективнее?
22 октября в 17:00 в прямом эфире Code of Leadership встречаемся с Владимиром Долговым. Поговорим про developer productivity и то, как меняется разработка, когда в команде появляются AI-агенты. Допустим, агент быстро написал код. Дальше кто-то проверил его, попросил переделать, встроил в систему и довёз до пользователя. Хочется посчитать весь этот путь: сколько времени и сил потратили, что получили на выходе и где на самом деле случилось ускорение. Счётчик токенов сам на эти вопросы не ответит :) Владимир Долгов — технологический и продуктовый лидер с более чем 20-летним опытом управления командами и крупными проектами на уровне CxO в финансах и телекоммуникациях. В Сбере он руководил AI-трансформацией процесса разработки, внедрял AI-ассистентов и развивал продукты Developer Experience: GigaCode, GigaIDE, GigaView и API/Function Studio. Ранее построил с нуля CRM/MDM-направление, управлял распределёнными командами до 430 человек и внедрял крупнейшие Oracle Siebel CRM. Математик по образованию, выпускник СПбГУ. С Владимиром разберём несколько больших тем: 🔸 Как развиваются инструменты разработки IDE, CLI, фоновые агенты — как меняются рабочие привычки, что стоит строить самим и по каким признакам новый инструмент заслуживает места в команде. 🔸 Что мы называем developer productivity Скорость отдельного инженера, движение задач через команду, качество, польза для бизнеса — как связать всё это и понять, что именно удалось улучшить. 🔸 Как устроена агентная разработка От постановки задачи и подготовки контекста до тестов, ревью и выпуска. Что можно поручить агенту, где нужен человек и сколько стоит проверка результата. 🔸 Как оценивать эффект AI Что сравнивать до и после внедрения, как учитывать переделки и отличать пользу инструмента от изменений в составе команды или сложности задач. И что делать, если PR стали появляться быстрее, а релизы выходят с прежней частотой. И будет демо DevOptify (https://devoptify.ru/) — платформы для оценки developer productivity, которую строит Владимир. Посмотрим, как устроен переход от инженерных данных к выводам и решениям руководителя. Заодно обсудим границы метрик: что они способны показать, где им не хватает контекста и как разработчик может оспорить оценку своей работы. Приходите, если внедряете агентов, развиваете инструменты или отвечаете за результат команды. Приносите вопросы и свои истории: что происходило с командой и продуктом после того, как вы научились быстрее писать код.
S2 · E27
October 15 · 1 hr 38 min
FDE: кто отвечает за то, чтобы AI заработал у клиента
14 октября в прямом эфире Code of Leadership поговорим про Forward Deployed Engineering — работу инженеров, которые погружаются в задачи заказчика и доводят решение до работающего результата. В гостях — Павел Голубев, Principal AI FDE Manager в Microsoft, автор Telegram-канала Corporate AI (https://t.me/corporateAI). За его плечами — промышленный консалтинг, оптимизация цепочек поставок, Data Science в Beat и EPAM, проекты для клиентов Azure в Европе, на Ближнем Востоке и в Африке. Павел работал и руководителем, и инженером на Principal IC-треке, поэтому обсудим обе стороны: как самому внедрять AI и как руководить людьми, которые этим занимаются. В прошлом выпуске (https://www.youtube.com/watch?v=ONbIBITmMeo) мы уже добрались до темы FDE и договорились вернуться к разговору. Теперь хочется разобраться, что за это время изменилось в самой работе и ответственности инженера. У FDE интересная задача: отвечать за результат, когда данные, процессы, доступы и значительная часть решений находятся у других людей. Причём заказчик тоже не один человек: у руководителя, пользователя и службы безопасности могут быть совершенно разные представления об успешном внедрении. Написать код в такой ситуации — только часть работы. Обсудим: Чем FDE отличается от консультанта, solution architect и инженера продуктовой команды? Как выглядит путь от «хотим внедрить AI» до системы, которой действительно пользуются? Как договориться о критериях успеха и удержать границы проекта, когда запросы продолжают расти? Что AI меняет в стоимости внедрения и где по-прежнему приходится долго разбираться с людьми и процессами? Как FDE Manager распределяет инженеров между проектами, проверяет качество и помогает в сложных ситуациях? Кому подходит эта роль, какие навыки нужны для входа и когда компании вообще не нужен FDE? Попробуем пройти одно внедрение по шагам: от исходного запроса до запуска и дальнейшей поддержки. Поговорим о решениях, компромиссах и о том, кто отвечает за систему после ухода команды. Timeline 00:00 - Павел Голубев: от инженерного трека к FDE 03:28 - Как меняется клиентская работа Microsoft 10:57 - От потребления Azure к оплате проектов 21:20 - Раннее участие инженеров в переговорах 24:52 - Бюджетный цикл клиента и загрузка команды 26:23 - Обязательства по результату и разделение выручки 31:39 - Риск обещаний до проверки данных 36:43 - Два пакета услуг и проблема негибкости 47:13 - Кто отвечает за изменения у заказчика 52:36 - Доступы, Copilot Studio и сопротивление IT 57:11 - Зачем инженер участвует в продажах 1:05:06 - Как договор ограничивает риск проекта 1:07:52 - Мандат заказчика и отбор запросов 1:17:41 - FDE-менеджер, матрица и работа команды 1:27:38 - Кому подходит FDE и чему эта работа учит
S2 · E26
October 6 · 1 hr 28 min
Разработчик становится менеджером в эпоху AI?
Ты хорошо пишешь код, закрываешь задачи, коллеги доверяют. А потом оказывается в эпоху AI все поменялось: с соседней командой нужно договориться, бизнесу объяснить стоимость решения, новичку помочь, а приоритеты кто-то должен расставить. Должность осталась прежней, работа заметно изменилась. Обсудим тезис Андрея: разработчик становится менеджером, хочет он того или нет. На примерах из его опыта в разработке, управлении командами и бизнесе разберём: Где расширение ответственности помогает расти, а где на человека просто свалили слишком много. Что значит «думать как бизнес» и какие полномочия для этого нужны. Как перестать переделывать за коллегами, даже когда кажется, что «проще самому». Как руководителю слышать несогласие и узнавать о проблемах до срыва сроков. Кто и за чей счёт выращивает самостоятельных инженеров. Можно ли оставаться сильным специалистом без желания управлять людьми. Timeline 00:00 - Андрей Дмитриев и новая ответственность инженера 03:22 - Почему разработчик становится руководителем 05:23 - Как появились узкие специализации 08:59 - Язык программирования или знания предметной области 20:12 - Что агенты берут на себя в цикле разработки 24:06 - Потребности пользователя и продуктовый инженер 30:34 - Инженер сам начинает ставить задачи 33:10 - Продукты, поиск и интерфейсы для агентов 40:30 - Подключить, развивать и вовремя отключить агента 45:05 - Проверять пользу работы до её автоматизации 50:42 - Знания в головах людей и риск их потери 56:49 - Пересобирать код из намерений, правил и проверок 1:04:40 - Самоулучшение моделей и неопределённость профессий 1:11:31 - Бот для сайта и личный инструмент выбора района 1:16:22 - Опыт, критическое мышление и польза руководителя
S2 · E25
October 3 · 1 hr 27 min
Как инженер учится договариваться
2 октября в 10:30 по МСК в прямом эфире поговорили с Сергеем Киселевым о том, как меняется инженер, когда от его решений начинает зависеть всё больше людей. У Сергея больше десяти лет работы с инфраструктурой Яндекса и Yandex Cloud, а с 2023 года он строит Development Platform в MWS Cloud Platform. Ещё он входит в программный комитет DevOops и ведёт канал «Буду погроммистом!» (https://t.me/intr13_riot). Мне интересно это сочетание ролей: Сергей делает инструменты для коллег, нанимает инженеров и помогает выбирать, о чём говорит сообщество со сцены. Хочется проверить, как инженерные убеждения выдерживают встречу с людьми, сроками и последствиями собственных решений. Обсудили: Что пришлось пересмотреть при переходе из Яндекса в MWS и что сильному инженеру труднее всего перестать делать самому, когда он становится руководителем? Как появляются общие правила платформы: кто вправе отказаться от стандарта и кто платит за отсрочку миграции, если команда уже пообещала клиенту срок? Как в найме отличить совместимость с командой от желания нанимать похожих на себя — и как через полгода заметить собственную ошибку отбора? Что делает руководитель в аварии: когда самому разбираться с техникой, а когда взять на себя коммуникацию? Вспомним доклад Сергея на HighLoad++ о большом инциденте. Что сегодня стоит за словом DevOps и чему начинающему инфраструктурному инженеру учиться самому, если часть рутины забирает AI? Timeline 00:00 - Сергей Киселёв: инженер, руководитель и участник сообщества 03:44 - Студенческая компания: первый опыт руководства 09:01 - Переезд в Петербург ради людей и новых задач 14:30 - Возвращение в инженерную роль и работа в Яндексе 28:10 - Зачем компаниям единая инфраструктура 32:58 - Достаточное качество вместо бесконечного совершенствования 36:23 - Запуск облачных сервисов и передача самостоятельной команды 42:16 - Переход в MWS и выбор компонентов для облака 48:47 - Собрать ядро команды и ускорить найм 53:43 - Четыре направления платформы разработки 57:02 - Договариваться с продуктовыми и инфраструктурными командами 1:01:51 - Инциденты: надёжность, дежурство и связь с пользователями 1:10:53 - Разбор инцидента должен приводить к изменениям 1:15:31 - ИИ, документация через MCP и правила работы команды 1:22:06 - Метрики, переговоры и команда как продукт руководителя
S2 · E24
October 1 · 1 hr 36 min
Зачем руководитель возвращается к коду
1 октября в 11:00 по МСК в прямом эфире поговорим с Никитой Белокопытовым о том, что происходит с инженерным руководителем, когда он снова может многое сделать сам. У Никиты опыт мобильной разработки и руководства инженерными командами — в том числе в Nepos, AutoScout24 и Playrix, а недавно он перешёл в Bluefish и занимается там Applied AI. Повод для разговора — его собственные посты. В одном Никита пишет, что часть управленческих слоёв станет не нужна, и рассказывает, как сам вернулся к практической разработке. В другом — что люди продолжают отвечать за системы, которые проектируют и проверяют машины. С такими тезисами интересно спорить предметно, на конкретных историях. Обсудим: Когда инженер впервые отвечает за результат продукта целиком, а не только за свой код? Какое управленческое решение за других людей Никита пересмотрел бы сегодня? Зачем руководителю снова садиться за разработку и как понять, когда задачу лучше сделать самому, а когда отдать команде? Как устроен один реальный AI-процесс: кто ставит задачу агенту, где нужен человек и как проверяют результат? Какие задачи менеджера действительно исчезают — и что инженер должен уметь объяснить без AI, прежде чем взять ответственность за изменение? Попросим Никиту отделить личные наблюдения от прогноза и назвать условия, при которых его тезис про менеджмент не работает. Timeline 00:00 - Никита Белокопытов: из управления обратно в разработку 03:47 - Семья инженеров, математика, графика и мобильная разработка 12:01 - Первое лидерство, конфликт с менеджером и честная обратная связь 22:32 - Как подбирать самостоятельность, поддержку и контроль 31:18 - Playrix: техническая ответственность и разные команды Gardenscapes 41:28 - Внедрение Cursor и поздний переход сильнейших программистов 44:42 - Разбор багов с агентами: граф состояний и ограничения неопределённости 51:09 - Gemini и Firebase Studio: личный перелом в отношении к разработке 58:40 - Завершение трансформации в Playrix и выбор Bluefish 1:04:14 - Как опыт управления помогает инженеру без прямых подчинённых 1:07:32 - Почему корпоративным клиентам нужны человеческий контроль и ответственность 1:14:14 - Инструменты клиентской команды: эксперименты и общие требования 1:22:42 - Автономный агент: от небольшой задачи в Jira до запроса на включение кода 1:26:51 - Предел ручной проверки и дорогие циклы исправлений между агентами 1:30:31 - Ответственность за продукт и глубокое погружение без микроменеджмента
S2 · E23
September 29 · 1 hr 18 min
Как руководить тем, в чём пока не разбираешься
В прямом эфире поговорим с Леонидом Черным, автором канала Irregular CDO (t.me/irregular_cdo), о ситуации, в которой должность уже новая, ответственность уже твоя, а в предмете команда разбирается лучше тебя. У Леонида за плечами тестирование и продюсирование игр в Nival, запуск Яндекса в Турции, Rambler, работа с данными в «МегаФоне» и Uzum, операционное управление в oneFactor. Интересно пройти этот путь и понять, что помогало ему при каждой смене области, а чему приходилось учиться заново. Обсудим: Как быстро стать полезным команде, когда сам ещё разбираешься, что здесь вообще происходит? Какие решения оставлять экспертам и как добиться, чтобы они не ждали разрешения начальника? Как управлять через языковой и культурный барьер — на примере запуска «Аллодов» в Японии и работы Яндекса в Турции? Как учиться делегировать, спорить с начальством и вовремя просить помощи? Что на практике означают два правила руководителя: «помогать» и «не мешать»? В плане есть и истории из его канала: переводчица, превращавшая отказы в обещания, премия сотруднику из собственного кармана и испытательный срок, пройденный с 23% выполненных целей. Попросим Леонида рассказать, как так получилось и что сегодня он сделал бы иначе. Timeline 00:00 - Знакомство с Леонидом: от системного администратора к данным 05:54 - Cybiko: первые тесты и обучение у разработчиков 09:42 - Nival: как появилось системное тестирование игр 13:31 - Руководство новой функцией и путь к результату 16:49 - От тестирования к выпуску и продюсированию игр 22:06 - «Аллоды Онлайн»: работа с Японией и Кореей 24:03 - Локализация, культурные особенности и экономика игры 27:20 - Переход в Яндекс и запуск в Турции 38:08 - Лучший поиск не всегда меняет привычки пользователя 42:02 - Rambler Top 100: от продукта к данным 49:25 - «МегаФон»: отношения, учёба и право спорить 53:11 - Культура подразделения и защита команды 58:17 - CDO: ответственность и недостающие полномочия 1:02:49 - oneFactor и Uzum: процессы и новый бизнес 1:12:45 - Советы руководителям: люди, связи, решения и чтение
S2 · E22
September 24 · 1 hr 11 min
Команда с ИИ: что меняется в работе руководителя | Разговор с Димой Твердохлебовым
Поговорим о том, как меняется руководитель, когда после больших компаний начинает строить собственную. Здесь интересен сам переход: какие навыки помогают, от каких привычек приходится отказываться и что происходит с управленческими убеждениями, когда правила теперь устанавливаешь ты. Начнём с карьеры Димы: геймдев, YouDo, Яндекс, Эвотор, VK, МТС. Как он переходил от работы над продуктом к ответственности за людей, какие решения оказались трудными и почему в какой-то момент решил выйти из найма. А дальше — собственная команда, люди и AI-агенты. Обсудим вопросы Где заканчивается возможность делать всё самому, даже если под рукой несколько агентов? Что можно делегировать модели, кто проверяет результат и как работа продолжается без постоянного участия основателя? Кого нанимать в такую команду: какие инженерные и продуктовые навыки действительно нужны, как их проверить на собеседовании? Какие корпоративные процессы хочется вернуть, когда сам начинаешь отвечать за сроки, качество и чужую работу? Отдельно разберём talant.club. Проект предлагает собирать несколько независимых команд под одну задачу бизнеса. Тут сразу хочется понять, как выбирают решение, оплачивают работу участников и совмещают конкуренцию с обменом знаниями. И кто потом поддерживает то, что получилось. Ещё поговорим о границе между быстрым пилотом и работающим сервисом у заказчика: что остаётся после демо, кто занимается интеграцией и по чему судить о результате. Попросим Диму разобрать конкретные решения и рассказать, что сегодня он сделал бы иначе. Приходите, если руководите командой, развиваете продукт или думаете о собственном деле с ИИ. И приносите вопросы — оставим время для чата. Timeline 00:00 - Знакомство с Дмитрием и Omnius.team 02:43 - Что задерживает ИИ-проекты у больших заказчиков 05:52 - Самостоятельные люди и общая память команды 09:12 - Пилоты на внешних данных 11:34 - От первого результата к внутреннему внедрению 15:09 - Поиск новых решений внутри и вне корпорации 19:38 - Три примера: налоги, реклама, новые материалы 28:43 - Исследовательские задачи за пределами привычных отраслей 30:34 - Что меняется в работе инженера 35:55 - Знания о системе вне пересоздаваемого кода 39:11 - Зрелость ИИ-помощника и рост организации 45:24 - Правила помощника на основе реальных ошибок 50:15 - Три критерия найма в небольшую команду 57:29 - Talant.club: несколько решений для одного заказчика 1:06:30 - Совет руководителю: начать с собственного опыта
S2 · E21
September 23 · 1 hr 39 min
Код, автомобиль, страховка: чему заново учится CTO
Что из опыта технического руководителя можно забрать с собой в новую отрасль? А что придётся пересмотреть, когда после торговой платформы берёшься за автомобиль, а затем за страховой продукт? Пройдём этот путь вместе с Фёдором: от первых задач в CBOSS и работы в Orange — к OTC.ru, Arrival и QIC digital hub. Меня здесь особенно интересует, как меняется само понимание «продукт готов», допустимой ошибки и ответственности за результат. В Arrival разберём путь одной функции от требований и кода до работы в автомобиле. Где возникают зависимости между софтом, электроникой и физическим устройством? Что делать, если каждая команда закончила свою часть, а целиком всё ещё не работает? И как руководить, когда планы и ресурсы компании меняются? В QIC поговорим о цифровых страховых продуктах: зачем им общая платформа, как развивать её рядом со старыми системами и договариваться о приоритетах между командами. Попробуем на конкретном изменении понять, что ускоряет выпуск — архитектура, организация работы или их сочетание. Отдельно обсудим AI в разработке: что уже можно поручить агентам, что проверяет инженер и как оценивать пользу с учётом переделок. И вернёмся к карьере: как заслужить доверие команды в незнакомой отрасли и какие вопросы задать себе и компании перед следующим переходом. Приходите, если руководите разработкой, растёте в эту роль или присматриваетесь к другой отрасли. Приносите вопросы — обсудим их в прямом эфире. Timeline 00:00 - Переносимость опыта и знакомство с Фёдором 05:28 - От МИФИ к разработке биллинга в CBOSS 17:58 - Технический центр во Вьетнаме 22:18 - Orange: очередь задач, ресурсы и свой биллинг 32:45 - OTC.ru: от раннего продукта к растущей площадке 39:33 - Переход в Arrival: люди, автомобиль и физический мир 51:09 - Функция как единица поставки и уровни готовности 57:41 - Четыре уровня требований и ранняя интеграция 1:04:30 - Ответственные за функции и проверка связей 1:07:44 - Смена приоритетов и повторное использование 1:12:54 - Откуда пришли практики и зачем проверять код 1:24:37 - После Arrival: переход в QIC Digital Hub 1:28:27 - Общий язык продуктов, требования и владельцы 1:31:11 - Выделение страховых функций из монолита 1:35:09 - Внешние ограничения и следующий шаг
S2 · E20
September 11 · 1 hr 34 min
Где у 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 - Расти к ответственности, а не к должности
S2 · E19
September 9 · 59 min
Первые 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
S2 · E18
September 9 · 1 hr 46 min
Продуктовый инженер — как изменится роль программистов в ближайшие 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
S2 · E17
September 4 · 1 hr 5 min
Как действовать среднему бизнесу с 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
S2 · E16
September 2 · 54 min
Джун после кода - как растить инженеров, когда исполнение уезжает агентам
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 - Код дешевеет, инженерное суждение — нет
S2 · E15
August 31 · 51 min
Последние 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
S2 · E14
August 24 · 1 hr 26 min
Дешёвый код: подняться на метауровень
Что остаётся дефицитным, когда код становится дешёвым: инструменты, инженерное мышление или доверие между компанией и разработчиками? В очередной серии подкаста Code of Leadership поговорим с Сергеем Бережным — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и одним из соавторов методологии БЭМ (https://veged.ru/). Сергей работает в Яндексе с 2005 года и прошёл путь от разработки интерфейсов до DevRel, open source и образования. Но разговор будет не про карьерную ретроспективу. Хочу понять, как техническое лидерство выходит за границы одной команды и проявляется в методологиях, платформах, работе с сообществом и публичной ответственности. Обсудим: - Зачем бизнесу DevRel и чем измерять его результат; - Почему внутреннюю технологию стоит открывать миру и как выбирать проекты для open source - Как разработка проходит путь от автодополнения к AI-агентам и harness-системам; - Что происходит с ролью руководителя, когда частью команды становятся агенты; - Кого и чему учить, если привычные entry-level задачи всё чаще забирает AI. Смотрите выпуск и приносите в комментарии свои вопросы и примеры.
S2 · E13
August 23 · 1 hr 33 min
AMA с подписчиками - чтение, карьера, пет-проекты и AI-разработка
23 августа в 16:00 по москве Александр Поломодов отвечает на вопросы подписчиков «Книжного куба». В программе: Чтение нескольких книг и white papers, выбор материалов и тайм-менеджмент; Личный процесс исследования, Knowledge Base и публикационный конвейер; Практическое обучение и развитие System Design Space; Пет-проекты и AI-greenfield; Вход в IT, рост джуна и переход выше уровня лида; Уход с топ-менеджерской позиции, переезд и следующий карьерный этап; SDD, размер AI-generated PR, детерминированные контроли и границы автономности; Ответственность за инциденты и экономика AI-разработки. Плюс еще был ряд дополнительных вопросов в чате трансляции
S2 · E12
August 19 · 1 hr 45 min
Как выстроить собственную систему управления с Михаилом Тюргановым
Как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? 17 августа в 19:00 МСК в эфире Code of Leadership вместе с Михаилом Тюргановым, руководителем Департамента разработки цифровых сервисов Альфа-Банка, поговорили про его путь от тестировщика, программиста и CEO малого бизнеса до технологического директора. В эфире мы обсудили: - Чем CTO малого бизнеса отличается от CTO в enterprise; - До какого масштаба работают сильные люди и неформальные договорённости; - Как отличить нужный найм от попытки закрыть организационную проблему численностью; - Что дают метрики эффективности и когда команда начинает играть с дашбордом; - Почему сильный инженер не обязан становиться менеджером; - За что CTO должен отвечать лично, а что превращать в платформу, процесс и инженерный карьерный трек; - Как AI и вайбкодинг меняют требования к скорости, проверке и эксплуатации. #Management #Leadership #Engineering #Architecture #PlatformEngineering #AI4SDLC
S2 · E11
August 13 · 1 hr 8 min
AI-внедрение: решает протокол, а не модель
В четверг в 13:30 по Москве вместе с Алексеем Литвиновым в прямом эфире продолжили говорить про AI-Assisted Engineering и про то, как вообще строить AI-Native организацию. Первые две AMA сессии прошли плотно и мы разобрали порядка 15 вопросов, но еще осталось около шесть, которые мы разобрали с Лёшей в третьей серии. Кстати, у Леши есть свой tg-канал - t.me/tip_podcast, подписывайтесь на него.
S2 · E10
August 12 · 1 hr 25 min
PRD == evals: как AI стирает границу между продактом и ML Engineer
Обсуждение с Альбиной Мунировой из Т-Банка последние изменения в профессии продакт менеджеров, когда граница между ним и ML-инженером становится заметно тоньше. Прототип теперь можно собрать за несколько дней, но главный вопрос начинается после демо: кто превратит продуктовое намерение в воспроизводимые проверки и возьмёт ответственность за поведение вероятностной системы? Альбина Мунирова - лидом продуктов в AI-центре Т-Банка, бывший ML-инженер и тимлид, лидером и создателем профессии ML-продакт-менеджера в банке. Центральная формула разговора - PRD == evals. Разберём, что она означает в реальной работе и почему это не просто замена одного документа таблицей тестовых вопросов. Поговорили о том: - Кто такой AI Product Builder и действительно ли это новая профессия; - Что продакт теперь должен уметь делать руками, а где специализация MLE остаётся критичной; - Как перевести требования к ассистенту в eval-набор, порог выпуска и продуктовые метрики; - Почему быстрый MVP ещё ничего не говорит о стоимости проверки и промышленной эксплуатации; - Как, по словам Альбины, её команда в 2023 году строила инвест-ассистента на RAG, когда готовая обвязка только формировалась; - Почему ассистент «по всему банку» - это не один большой промпт, а маршрутизация, данные, права, инструменты, память, безопасность и разные владельцы качества; - Что опыт ассистента Олега может дать современным LLM-продуктам. Для меня главный вопрос эфира такой: AI Product Builder - это новая клетка в оргсхеме или новый минимальный уровень владения результатом от проблемы до доказательства качества? #AI #Product #MachineLearning #Evals #Engineering #Agents
S2 · E9
August 7 · 1 hr 40 min
Цифровой тимлид или можно ли измерить эффективность разработчика по коду?
Работают ли ваши разработчики на 100%? И можно ли вообще ответить на этот вопрос по коду - без табелей, дополнительных отчётов и субъективной оценки руководителя? А если в работе случился спад - отличить недозагрузку от сложного легаси, техдолга, незнакомой технологии или месяца тяжёлой отладки? 6 авугста в 17:00 по Москве со мной в прямом эфире будет Иван Гель, основатель компании Dex, в рамках подкаста Code of Leadership. Мы поговорим об UpCore - системе, которую команда называет «цифровым тимлидом». Идея амбициозная: анализировать код без дополнительных отчётов от разработчика, оценивать его трудоёмкость с учётом десятков факторов, сопоставлять результат с грейдом и показывать руководителю причины изменения эффективности. По заявлению команды UpCore, система может определить, сколько времени заняла бы работа у разработчика определённого уровня, увидеть долю сохранившегося кода, переделок и отладки, учесть сложность архитектуры, легаси, баги и технологии проекта. В презентации заявлена точность на уровне 85% относительно экспертной оценки, а также рост эффективности в среднем на 12% за три месяца после внедрения. Но здесь и начинается самый интересный разговор. Код - важный результат работы инженера, но далеко не вся его работа. Архитектурные решения, помощь команде, ревью, исследование, предотвращённые ошибки и сложность контекста плохо сводятся к одному числу. А метрика, от которой зависят грейд, бонус или увольнение, быстро становится целью для оптимизации. Обсудим: - Что именно UpCore считает эффективностью и как нормализует разные проекты, стеки и типы задач; - Можно ли автоматически определить грейд и трудоёмкость только по коду; - Как в текущих условиях, когда код пишется с помощью ИИ, можно измерить эффективность программиста. - Как отличить слабую работу от легаси, техдолга, сложного ядра системы и длительной отладки; - На каких данных проверялись заявленные 85% точности и рост на 12%; - Повышает ли полная прозрачность осознанность разработчика или разрушает доверие в команде; - Как защитить такую систему от накрутки и саму команду - от ошибочных управленческих выводов; - Где проходит граница между полезной инженерной телеметрией и цифровой слежкой. Приходите не на продуктовую демонстрацию, а на честный разговор о том, можно ли сделать работу команды прозрачнее, не потеряв контекст, доверие и ответственность руководителя.

Showing 1–20 of 34 episodes