Code of Leadership

Code of Leadership

By Alexander PolomodovBusinessTechnologyEducationSelf-ImprovementManagement
Download on the App Store

Code of Leadership episodes

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

      1 hr 39 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 - Опыт, критическое мышление и польза руководителя

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

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

            1 hr 37 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 - Советы руководителям: люди, связи, решения и чтение

              1 hr 19 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 - Совет руководителю: начать с собственного опыта

                1 hr 12 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 - Внешние ограничения и следующий шаг

                  1 hr 40 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 - Расти к ответственности, а не к должности

                    1 hr 35 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

                    1 hr
                  • Продуктовый инженер — как изменится роль программистов в ближайшие 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

                      1 hr 47 min

                    About Code of Leadership

                    From the publisher's feed

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