Code of Leadership

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 и чему эта работа учит

Ты хорошо пишешь код, закрываешь задачи, коллеги доверяют. А потом оказывается в эпоху 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 - Опыт, критическое мышление и польза руководителя

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 - Метрики, переговоры и команда как продукт руководителя

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 - Ответственность за продукт и глубокое погружение без микроменеджмента

В прямом эфире поговорим с Леонидом Черным, автором канала 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 - Советы руководителям: люди, связи, решения и чтение