Доклады конференции TeamLead Conf Siberia 2026

• Подход к внедрению ИИ в команды как к контролируемому, измеримому эксперименту
• Методика оценки экономической эффективности внедрения ИИ
• Проектирование эксперимента и управление рисками
• Коммуникация с бизнес‑лидером и командой – от старта до масштабирования

Знакомая картина: в компании внедряют AI-инструменты — генерацию кода, ассистентов, автоматизацию аналитики. Пилоты показывают отличные результаты. А через полгода инструменты используются фрагментарно, процессы не изменились, у руководителей стало больше контроля и отчётности — а не меньше.

Ответ, который разберём: результат съедает существующая модель управления. AI не меняет то, как устроена организация, — он это усиливает. Включая проблемы. Вопрос в том, где именно это происходит у вас — и что с этим делать. Разберём три повторяющихся паттерна провала: пилот не масштабируется, появляется новый bottleneck, контроль вытесняет доверие. И три принципа, которые отличают компании, где эффект всё-таки случился: перераспределение ответственности, новые метрики результата, легализация практик.

Что вы унесёте с доклада:

• Три вопроса, которые помогают увидеть, где именно теряется эффект AI: в ответственности, в контроле или в неявных практиках.
• Три шага, которые можно сделать на следующей неделе — без бюджета и отдельного проекта.
• Аргументы для разговора с руководством и командой о том, почему «внедрили, но не работает»

Это доклад не про выбор инструментов и не про сравнение моделей. Говорим про управленческую и организационную сторону AI-трансформации: почему изменения не доходят до уровня повседневной работы команд.

AI‑инициативы в командах часто ломаются не на выборе модели, а в ежедневных решениях тимлида и команды. Люди приносят в работу свои искажения — от automation bias до confirmation bias, — а LLM добавляют свои: сикофантию, самоуверенные ошибки и ложное ощущение надёжности.

Доклад покажет, как тимлиду проектировать процессы так, чтобы предвзятость людей и моделей не усиливала ошибки, а работала как система сдержек и противовесов.

В этом докладе мы честно расскажем о нашем пути AI-трансформации. Вы узнаете, как мы внедряли изменения и учили команду жить в новой парадигме, как работали с сопротивлением команды, какие шишки себе набили и как в итоге выстроили кросс-командное взаимодействие, где AI-агенты стали полноценными участниками процессов.

Рассмотрим на докладе как получить быструю пользу от внедрения ИИ и не тратить время на ночные вайбкодинг-эксперименты. Как получить получить опыт самостоятельной эксплуатации агентов и стать более профессиональным заказчиком ИИ-транформации.

Доклад о применении мультиагентных системы для казалось бы простых и рутинных задач личной жизни и ежедневного самоменджмента и тайм-менеджмента. На примере функции контроля поручений создаётся ряд агентов/скиллов, которые по очереди: 1) собирают информацию о полученных и порученных задачах из разных источников 2) классифицируют информацию и собирают second brain для хранения задач и контекста 3а) выполняют те задачи, которые ИИ может выполнить 3б) готовят информацию и черновики для задач, где требуется human-in-the-loop 4) контролируют поручения и сроки 5) проводят анализ выполненной работы для самоулучшения процессов по стандартному циклу PDCA.

Все артефакты для воспроизведения будут доступны opensource Это пример менеджерского пайплайна с очень высоким ROI, который позволяет получить личный опыт создания мультагентрого пайплана и базы знаний с семантическим графом и на практике изучить все основные подходы эксплуатации подобных систем.

В последний год мы во «Фланте» начали активно внедрять AI во внутренние процессы компании: поиск информации, работу с документами, согласования и другие рутинные операции. Очень быстро выяснилось, что главные сложности лежат не в выборе моделей и инструментов. Проект почти сразу упирается в организационные вопросы: разрозненные данные, отсутствие источника истины, неочевидное распределение ответственности и разграничение прав доступа. AI из инструмента превращается в стресс-тест операционной зрелости компании.

В докладе расскажу про наш опыт. Что реально происходит, когда компания пытается встроить AI в рабочие процессы, где модели действительно помогают, а где обычная автоматизация оказывается проще и надёжнее. Поделюсь выводами — с чего начинать внедрение, что стоит сделать заранее и как не превратить внедрение AI в бесконечную генеральную уборку.

Менеджер из разработки живёт между двумя ролями: управлять и при этом не растерять инженерную хватку. В итоге часть полезных задач годами висит в статусе «когда-нибудь руки дойдут»: посчитать метрики команды и собрать дашборд, написать маленького агента, который превращает Release Notes в понятные задачи, разобрать тысячу тикетов в Jira и найти в них закономерности. Я покажу, как ИИ убирает это «когда-нибудь»: идеи, на которые раньше не хватало вечера, превращаются в работающие инструменты за этот самый вечер. И как тот же ИИ возвращает менеджеру возможность снова погружаться в технику и доводить дела до конца — а не только ставить их в бэклог и раздавать другим.

В докладе разберём реальный кейс: как команда столкнулась с ограничениями классической функциональной структуры, кадровым дефицитом и сжатыми сроками запуска новых продуктов. Расскажем, почему простое внедрение AI-инструментов не решает проблему скорости, если не менять управление, роли и взаимодействие между людьми. Покажем, как мы пересобрали работу маркетинга, продукта, дизайна и разработки, встроили AI в ежедневные процессы и смогли быстрее запускать продуктовые инициативы без резкого расширения команды. Доклад будет полезен тимлидам, техлидам, руководителям направлений и продуктовым командам, которые работают в условиях нехватки людей, давления сроков и необходимости быстрее выводить новые сервисы на рынок.

Вайбкодинг ворвался в индустрию как модный и противоречивый термин, но за ним стоит реальность, которая меняет не только скорость написания кода, но и процессы управления разработкой. В своем докладе я расскажу, как мы проходили путь от скептицизма до регулярного использования AI-ассистентов в крупной корпорации с жесткими требованиями к безопасности и почему самым ценным адвокатом этого внедрения стали те, кто больше всех не доверял нейросетям.

Мы обсудим, где вайбкодинг реально ускоряет разработку, а где становится зоной риска. Разберем ключевую ошибку - обсуждать инструмент, а не сценарий.

Вы узнаете, как изменились требования к инженерной культуре: почему сильные команды с AI становятся еще сильнее, а слабые - начинают пробуксовывать. И главное как изменился цикл "идея в решение" и почему от прототипа до продакшена все еще дистанция огромного размера.

Что обсудим Почему внедрение AI меняет не только инструменты, но и саму структуру команды. Какие этапы SDLC уже сегодня могут быть частично переданы AI. Почему после автоматизации работы главным дефицитом становится контекст, а не информация. Как меняются роли аналитика, разработчика, QA, архитектора и тимлида. Какие новые ритуалы появляются в AI-native командах. Как не потерять качество решений, когда часть работы выполняют агенты. Как выглядит команда ближайшего будущего, где люди и AI работают как единая система.

Мы расскажем о том как: - строить вектор развития команды - работать с инициативами на рост - помочь в подготовке к процессу роса, выборе задач и оформлении артефактов - обновить ИПР на основе новой роли/должности сотрудника - личные результаты и итоги, что это дало компании, бизнесу, команде, на что повлияло

AI-агенты обычно начинают жизнь в компании как локальные помощники разработчика или чат-боты. Но настоящий эффект появляется, когда агент становится участником процесса: видит задачу, статус, MR, обсуждение, логи и данные. Он умеет собрать фактуру, провести анализ или выполнить задачу и передать результат человеку.

В докладе разберем подход, где существующие информационные системы компании остаются источником правды, бизнес-процессы описаны как workflow-документы, и агенты работают рядом с сотрудниками. На примере внутренней разработки Orpheus покажу, как Redmine, GitLab, Mattermost, Grafana и внутренние инструменты можно связать в общий агентский контур: от постановки задачи и диагностики до MR, ревью, документации и поддержки клиентов.

Это доклад про переход от этапа «AI как инструмента в руках человека» к «AI как участнику бизнес-процесса» с понятными границами, аудитом и человеческими точками решения.

Можно ли сегодня дать разработчику Claude Code или Codex и получить product engineer, который закрывает backend, frontend, тестирование и весь цикл PDLC? Мы проверили это на практике. Оказалось, что узкое место не в моделях, а в знаниях о системе, процессах и контексте, которые команды копили годами. В докладе расскажу, как мы строили tiny team из 2-3 человек и ИИ-агентов, какую роль играет harness, почему автономных e2e-агентов нельзя просто «включить», и как мы постепенно идем к такой модели разработки.

Вы хотите внедрять ИИ в команде, но упираетесь в страхи сотрудников: «меня заменят», «я не понимаю, как это работает», «нет времени разбираться, и так дедлайны горят». В Cloud.ru мы прошли этот путь и за год перевели команду от сопротивления к здоровому восприятию «ИИ — помощник, а не замена». Ключевой сдвиг: люди перестали бояться и начали искать способы работать быстрее.

Мы выстроили системную модель, которая работает без принудительных курсов и выделенных бюджетов. ИИ-комитет (6 треков: от платформы до коммуникаций), сообщество, проект «ИИ-чемпионы», ежемесячный дайджест «ИИ радар» с публичными разборами ошибок, а также практическое обучение через Braindump и Agentic Engineering Lab. В результате продвижения эффекта синергии мы увеличили количество успешно запущенных проектов, создали свой корпоративный стандарт по разработке LLM приложений и получили рост вовлечённости в ИИ-активности сотрудников различных ролей.

Приходите на доклад, чтобы забрать готовую дорожную карту: как формировать у сотрудников ИИ менталитет, снять страх ошибок, как построить ИИ-комитет и экосистему активностей с нуля и как измерять прогресс, не гадая на кофейной гуще. Без магии, без принуждения — на живых факапах Cloud.ru.

Значительную часть результата кодингового агента обеспечивает не модель, а harness — инженерная обвязка вокруг неё. Мы в Альфа-Банке посадили в агентский стек открытые модели, и критичность обвязки вышла на первый план. То, что работало в пет-проектах, никак не заводилось в корпоративном кластере. Магия вайбкодинга начала таять.

Расскажу, что harness делает за вас и как строить его самим: работа с реальным, а не заявленным лимитом контекста; упаковка доменной экспертизы в правила и скиллы так, чтобы агент не растерял их по дороге; мягкий harness против жёсткого — и что дало ужесточение под открытые модели по нашим журналам вайбкодинга.

В целом: любой доклад можно превратить в круглый стол. Куда (в какую секцию) - вам на самом деле видней.

Тезисы про ИИ: ИИ на хайпе, но реально ли его применять без потерь не в лаборатории а на работющем продукте и что это дает - вы работаете меньшим числом людей но с прежней эффективностью (или выше) и качеством? Или работа с ИИ жрет больше времени чем получаемый профит? Где тут собака зарыта (доклад будет на основе реального проекта)

Второй: В 2026 году картина мира сломалась - людей много, продукты сложны и наворочены, постоянно внедряется новый и новый инструментарий который должен по идее делать житие проще - а в реалии получаем: проекты делаются долго, проекты делаются дорого, найм не ускоряет, ФОТ-ы растут, бабки тратятся задачи крутятся - у кого-то лавеха мутится.... а где реальный профит для бизнеса и компании? Какие реальные потери на поставке ценности сейчас есть, чем их пытаются заткнуть и почему это не работает....а что работает реально? Само собой с примерами

Слово эффективность последние пять лет прожужжало все уши, А погоня за ней сожгла не одну команду. Расскажу почему все же эффективность не эффективна и как я еще сейчас достигаю вместе с командой.

Расскажу, почему аргумент «это важно для ИТ» больше не работает, и как превращать ИТ инициативы в понятные для бизнеса деньги, риски и ценность. Разберу, как готовиться к бюджетному комитету, отвечать на неудобные вопросы и защищать и без «страшилок» и абстрактных формулировок.

Когда команда растёт, а баги в продакшене начинают стоить дороже фич, возникает вопрос: пора ли заводить выделенное тестирование? Часто идея встречает скепсис: «это замедлит разработку», «нет бюджета», «разработчики справятся сами». В докладе я разберу, как преодолеть это сопротивление и превратить QA из «статьи расходов» в драйвер ускорения поставки ценности.

Я поделюсь реальным опытом запуска тестирования с нуля: от обоснования бизнес-кейса и найма первого специалиста до интеграции в рабочий поток без потери скорости. Особый акцент — на доказательной базе и метриках. После внедрения мы сократили критические инциденты на 70%, уменьшили время на фиксы и ускорили релизный цикл. Эффект оказался настолько заметным, что смежные команды начали сами запрашивать тестирование для своих задач.

Вы узнаете, как выстроить доверие между разработкой и бизнесом и сделать качество естественной частью процесса, а не бюрократическим барьером.

Эффективность инженерных команд и зрелость технологических ландшафтов/платформ — одна из самых обсуждаемых тем индустрии. Но между разговорами «мы хотим быть эффективнее» и реальным результатом стоит когнитивная нагрузка — «налог», который съедает 30–40% продуктивного времени.

В докладе разберём: 1. Что такое эффективность, продуктивность и где там когнитивная нагрузка. 2. Как построить модель эффективности технологического ландшафта и измерить её. 3. Как именно устранить когнитивную нагрузку в разных типах команд: инфраструктурных, продуктовых, командах поддержки. 4. Реальные кейсы построения зрелых платформ, моделей эффективности и golden paths.

Слушатели получат чёткое понимание того, какие метрики выбрать для оценки зрелости платформы и технологического ландшафта в целом. Также они узнают, как выстроить единую модель эффективности, которой будут пользоваться все — от инженеров до C-level.

Мы предлагаем вам инхаус агента на базе LLM которые можно развернуть локально, осуществляющего анализ ваших данных на основе чатового интерфейса, агент сам пишет и исполняет необходимый код для анализа в своей изолированной среде и предоствавляет вам готовые результаты - построенные графики, экспорты таблиц или же просто текстовый результат решенной задачи, имеется возможность добавить собственные пояснения к данным а также набора правил и инструкций по проведению анализа в конкретных областях. По итогу вы получаете помощника который эволюционирует от аналитика до компаньона принятия управленчиских решений.

• Информационный хаос лида: почему забывать - это нормальная функция мозга. Как справляться с десятками контекстов.
• Концепция Second Brain: как вынести рабочую память вовне и перестать бояться что-то упустить.
• Архитектура системы управления вниманием: фильтрация шума, захват мыслей и превращение заметок в действия.
• Мой топ "оптимизаторских" провалов: честный разбор почему 80% практик умирает в первый месяц.
• Итоги года борьбы за внимание: как изменилось качество управления, уровень фоновой тревоги за год.

В IT области, где результат нематериален и вклад каждого человека или команды часто бывает неочевиден, благодарность - один из немногих эффективных инструментов авторизации результата, признания и мотивации. На этой встрече мы рассмотрим инструменты осознания своей благодарности и повышения ее эффективности (модель Пинка, пирамида Дилтса, анализ коммуникации), обсудим, как сделать из нее привычку, проговорим основные анти-паттерны и подводные камни, например, где граница между осознанным использованием благодарности и манипуляцией

«Большинство из нас уже управляет людьми. Но даже лучшие руководители знают: точка "Б" всегда выше точки "А". Ключ к этому росту — не хаотичные усилия, а качественный индивидуальный план развития.

Что сделаем на мастер-классе?

Разберем на примеры реальных ИПР, которые привели к цели.

Увидим разницу между формальным и "рабочим" планом.

Сфокусируемся на вас: работа в мини-группах, чтобы создать каркас вашего личного ИПР.

Результат: вы уйдете не с теорией, а с четким пониманием своей мотивации, готовым шаблоном и конкретными первыми шагами. Ваш рост — в ваших руках. Создадим его вместе!»

Сотрудник спорит по мелочам, замыкается или со всем соглашается, а потом саботирует? Мы часто записываем таких людей в «сложные». Но нередко проблема не в характере и не в мотивации.

Когда человек считывает социальную угрозу, например удар по статусу, автономии или ощущению справедливости, включается защитная реакция: бей, беги или замри. И тогда одних логических аргументов уже недостаточно.

На воркшопе разберём модель SCARF как рабочий инструмент руководителя. Формат максимально практический: начнём с живого демо, в котором зал будет угадывать скрытый триггер сотрудника, а затем участники в тройках отработают кейсы из жизни команд разработки, побывав в ролях руководителя, сотрудника и наблюдателя.

Научимся распознавать триггеры по поведению и вести разговор так, чтобы снижать угрозу, а не усиливать её. Каждый уйдёт с памяткой по работе со всеми пятью триггерами.

1. Важность DevX, его атрибуты и влияние на команду.
2. Как архитектура влияет на ответственность, а стек технологий на мотивацию.
3. Как помочь разработчикам и самому себе в эпоху развивающегося сильного ИИ.

Команда как продукт: чему тимлид может научиться у маркетинга? "От velocity к value" посмотрим на маркетинговые метрики в управлении командой. Почему некоторые команды закрывает задачи, но бизнес всё равно недоволен? Почему одни тащат, а другие только делают вид и им это сходит с рук? Как начать воспринимать команду не как фабрику задач, а как продуктовую систему создания ценности.

Расскажу о проблемах времени, как команда может их преодолеть и какие преференции можно получить только благодаря тому что ваша команда живет в разных часовых поясах.

Я покажу вам подход, который поможет найти новые точки роста для вас и вашей команды. Через честный разговор с собой, самоанализ и благодарности.

Ключевой вопрос, который мы будем обсуждать: "Как выиграет команда благодаря мне сегодня?". Мы попробуем несколько подходов, которые помогут нам найти неожиданные ответы для себя.

Дисклеймер. Воркшоп содержит грустные мысли и сцены самонасилия и, ввиду своего содержания, не рекомендуется НИКОМУ.

Расскажу как планировать и выстраивать стратегию развития если ты рядовой тимлид или руководитель

Начинающие руководители тонут в многозадачности: приоритеты меняются, ресурсов не хватает, команда выгорает, а топ-менеджмент требует результатов. Мастер-класс «Ход Дум» — это 60-минутная игровая симуляция, где вы безопасно отработаете управление потоком создания ценности: приоритизацию, WIP-лимиты, реакцию на срывы и срочные запросы — без риска для реальных проектов. За один раунд вы пройдёте цикл доставки ценности от идеи до запуска, увидите, как переключения контекста «съедают» скорость, и получите готовый фреймворк для внедрения лимитов незавершённой работы. Минимум теории, максимум практики: разберём ваши решения в реальном времени и типичные ошибки начинающих тимлидов. После игры — 15–30 минут на обсуждение инсайтов и сложных игровых кейсов.

У тимлида часто есть ответственность за результат, но нет реальной власти — ни бюджета, ни полномочий принимать решения. Это классический управленческий разрыв, который мешает эффективной работе команд. Как в таких условиях убеждать руководство, добывать ресурсы и при этом сохранять доверие? В докладе — проверенные тактики влияния, основанные на реальном управленческом опыте автора. Мы разберем, почему эмоциональные просьбы не работают и как перевести потребности команды на язык, понятный бизнесу. Поговорим о том, как фиксация рисков меняет отношение руководителя к вашим запросам, о важности метрик и статистики и о том, почему убеждение начинается задолго до того, как вам что-то понадобилось.

• Event Storming: когда IT и бизнес перестали нуждаться в переводчике Как визуальный язык помог командам договариваться без бесконечных созвонов и согласований.

• Как научить ИИ писать сценарии встреч, которые готовы к использованию (и почти не требуют правок) ИИ берёт на себя чистовик, фасилитатор сосредотачивается на смыслах и живом ведении встречи.

• Тимлид — не единственный фасилитатор: как вырастить эту компетенцию в команде без найма Внутренняя школа фасилитации для менеджеров и техлидов: 16 выпускников, 50+ встреч, руководители перестали быть бутылочным горлышком.

• Чек-лист «5 признаков, что команда разучилась договариваться» Короткая диагностика, которую можно провести с командой на следующей ретроспективе.

Разберём, как говорить с DevOps, ИБ, бизнесом и финансами на их языке, чтобы согласовывать архитектуру, защищать бюджет и не становиться крайним за инфраструктурные решения и как тимлиду выбирать ИТ-инфраструктуру не “по привычке” или “подешевле”, а исходя из SLA, RPO, RTO, бюджета, рисков и экономики конкретного проекта.

Руководитель проекта часто оказывается «буфером» между бизнесом, который говорит на языке дедлайнов и метрик, и разработкой, мыслящей архитектурой и ограничениями. Разрыв в терминологии и ожиданиях приводит к циклическим доработкам, срыву сроков и выгоранию команд. Проблема не в отсутствии коммуникации, а в отсутствии единого языка и структуры передачи требований.

В докладе я разберу основные проблемы взаимопонимания и предложу как делать то, что нужно бизнесу, а не то, о чем он говорит и тогда когда нужно, а не тогда, когда просят.

В моей практике внедрение этих инструментов сократило количество итераций на уточнение ТЗ с 5 до 2, уменьшило время на согласование требований на 40–60% и позволило закрывать задачи с первой попытки в 8 из 10 случаев.

Техническая коммуникация — набор практик, методик и артефактов, позволяющих передавать технические знания внутри команды и за ее пределы. Традиционно к артефактам технической коммуникации относят документацию, обучающие курсы и учебные материалы.

Казалось бы, все эти вещи полностью находятся в сфере умений ИИ: в 2026 нам наконец-то не нужно писать все это вручную.

Но хорошие практики технической коммуникации применимы и к тем аспектам коммуникации, которые пока не подхвачены ИИ, например:

• короткая письменная коммуникация в мессенджерах и почте;
• описания тикетов в багтрекере;
  • устное рабочее общение;
  • внутрикомандные и публичные выступления.

Почти все эти коммуникационные аспекты подвержены шуму и ошибкам: мы часто не понимаем и недопонимаем друг друга, у нас не всегда получается донести то, что хотелось бы донести, на уточнение информации тратится драгоценное время, плохо сформулированные задачи приходится переделывать, и т.д.

В этом докладе мы обсудим практики из фреймворка технической коммуникации, которые позволят снизить уровень коммуникативного шума и ошибок, и прочертим неожиданные параллели между технической коммуникацией и хорошей технической документацией.

Кросс-командные коммуникации в больших IT-продуктах ломаются не только из-за процессов, но и из-за различий в том, как люди воспринимают информацию, реагируют на изменения и принимают решения. В результате команды теряют время на бесконечные согласования, конфликты и скрытое сопротивление.

В работе над внутренней GenAI-платформой банка мы постоянно взаимодействуем с десятками сервисов и команд одновременно. В такой среде аналитику и тимлиду важно понимать не только процессы, но и человеческую архитектуру организации: кто влияет на решения, кто ускоряет изменения, а кто создаёт сопротивление.

На мастер-классе мы разберём модель «корпорация как школьный класс». Через знакомые роли — староста, отличник, хулиган, тихоня, бунтарь-умник — участники научатся распознавать коммуникационные роли внутри команд и строить Communication Role Map для реальных рабочих ситуаций.

На тренинге разберём, что такое источники влияния в группе: почему одни люди легко задают вектор и получают поддержку, а другие упираются в сопротивление?

Шаг за шагом, через диагностические упражнения мы исследуем все 7 источников влияния и увидим, что еще возможно, вместо эскалации, давления, запугивания, подкупа и манипуляций.

Что по итогу: создадите свой личный профиль лидера и будете понимать на что можете опираться в работе уже сейчас, а где у вас наиболее перспективные точки роста.

Главный навык, который появится у участников - это способность даже в сложных разговорах вдумчиво формулировать наиболее выгодный ответ, а не выдавать тот, который первым пришел в голову.

1. На практике типичных для отрасли ситуаций разберем, как замечать эмоции в разговоре и управлять эмоциональным фоном диалога так, чтобы эмоции работали на ваши результаты и отношения с собеседником, а не против них.

2. Смоделируем те самые ситуации, когда «о таком вообще то не принято говорить», научимся поднимать неудобные темы и потренируемся структурно доносить свои ожидания до других, чтобы вас понимали именно так, как вы хотели.

3. В формате живого диалога потренируемся общаться под давлением. Поймем, как анализировать природу давления и работать с ним так, чтобы в результате разговора сохранить свой авторитет и минимизировать риски на будущее.

4. Немного побудем на стороне зла – изучим мозг манипулятора изнутри. На примерах разберем, как манипулятор вкладывает подтекст в безобидные ситуации и извлекает выгоды для себя. Это поможет лучше видеть, когда такую структуру применяют в жизни по отношению к вам, и не идти на поводу у манипулятора.

5. Соберем навыки работы с эмоциональным фоном, неудобными вопросами и своими ожиданиями, давлением и манипуляциями в единую гибкую систему управления разговором. В конце цикла участники научатся оценивать эффективность приемов для их ситуации в разговоре, видеть риски и возможности изученных приемов.

Переход на позицию руководителя команд такого же или более высокого уровня может представлять собой настоящий challenge даже для опытных руководителей и тимлидов, имеющих солидный профессиональный уровень и значимый послужной список. Конечную проблему можно обозначить так: вы были топ-перформером в прошлой компании, но при переходе в новую команду огромная асимметрия знаний между вами и людьми в новой компании по полгода и более держит вас в середнячках или того хуже - в кандидатах на вылет. Ваша адаптация в новой среде существенно затягивается, и дело здесь может быть не только в уровне новой команды. Часто практика адаптации тимлидов различных уровней не поставлена в компании на системные рельсы, делается от случая к случаю по принципу AS IS (делаем как можем и как умеем) и имеет длинные и непредсказуемые сроки реализации (от месяца до девяти месяцев). Руководители же тимлидов и пиры часто не располагают достаточным бюджетом времени на системную передачу знаний и обучение. Для условно уникальных позиций (например, CTO AI стартапа) говорить о системной практике адаптации и вовсе крайне трудно, поскольку она не носит массового характера и «золотой стандарт» попросту отсутствует. Новая среда может предоставлять весьма ограниченный объем помощи в адаптации в новой команде для ее нового руководителя. Принципы самоадаптации могут позволить не только упростить адаптацию в новой команде и сделать ее более предсказуемой и обозримой по срокам, снизить риски менеджерского фиаско, но и де-факто позволяют в условиях ограниченной внешней помощи во многом взять этот процесс в собственные руки. В докладе на основе многократного личного опыта перехода teamlead=> teamlead, а так же team lead => CTO расскажу, какие практики самоадаптации можно применять, чтобы повысить эффективность адаптации и осуществлять вход в новые команды более просто.

Увольнение часто воспринимается как неприятный финал, хотя на деле это просто ещё один сложный этап, который можно пройти комфортно. В докладе я покажу, как открытые разговоры, регулярная обратная связь и понятные договорённости помогают сделать расставание честным, предсказуемым и безопасным для сотрудника и компании. Разберём практики, которые снижают количество внезапных увольнений, помогают возвращать сотрудников из зоны просевшего перформанса и убирают лишний шум из сложных разговоров.

В рамках данного доклада вы узнаете:

• Как не потерять команду, когда изменения становятся новой нормой • По каким сигналам понять, что команда уже работает на пределе • Какие действия руководителя помогают сохранить мотивацию, доверие и темп работы • Какие ошибки в коммуникации и управлении чаще всего разрушают команду в период перемен • Какие простые практики помогают пройти через турбулентность без потери ключевых сотрудников

Я расскажу как мы в Контуре подбираем и взращиваем менеджеров разработки, а так же с какими сложностями сталкиваемся на этом пути. На нашем примере покажу, какие инструменты применимы не только в бигтехе, но и в совсем небольших компаниях. А на закуску - какой навык сейчас наиболее востребован для управленца и как его развивать.

Расскажу о том, как фрод-сотрудники и кандидаты изменили наш процесс найма и адаптации: - Какие бывают уловки со стороны кандидатов - Что мы изменили в процессе найма: методы оценки, которые помогают вычислить обманщика руководителю и HRу - Как HRу защититься от фродеров: меняем внутренние нормативные акты - Остаемся в правовом поле, сокращаем время подбора и сохраняем лояльность к компании со стороны кандидатов с реальным опытом

Рано или поздно любой руководитель сталкивается с вопросом: сотрудника нужно увольнять или ещё можно спасти ситуацию?

На словах решение кажется простым. На практике же одна "неправильно поставленная запятая" может стоить команде мотивации, доверия, производительности и даже других сотрудников.

В докладе разберём, как принимать кадровые решения не на эмоциях, а через оценку влияния сотрудника на систему команды.

“Нам предстоит неприятный разговор…” - услышав эти слова от руководителя, сердце сотрудника цепенеет и по спине может начать идти холодный пот.

Нередко именно такими словами начинается путь к расставанию с сотрудником.

Увольнение - штука неприятная и болезненная, особенно если происходит не по желанию специалиста. Но задумывались ли вы когда-нибудь, как во всём этом чувствует себя руководитель?

Что если у руководителя тоже есть свои страхи и переживания в таких ситуация?

На выступлении поговорим о том, как подготовиться к разговору о расставании с сотрудником, как вести себя, если сотрудник не принимает новости об увольнении и как не попасть в ловушки руководителей во время увольнения сотрудников.

Вы сталкивались с тем, что команда выросла до 15+ человек, фичи разрабатываются параллельно, а время от идеи до релиза всё равно ползёт? Люди начинают ждать друг друга, согласования «чей бэкенд?», «чей слот?» съедают до трети времени, а скорость падает. Мы через это прошли - сначала в мобильной команде, потом при объединении с вебом.

Главный механизм, который перевернул нашу разработку - это фича-лидство. Это когда роль лидера не закреплена за человеком навсегда, а передаётся как шляпа от фичи к фиче. Фича-лидом может стать разработчик, тестировщик или дизайнер. Именно это снимает главное ограничение тимлида - быть единственным, кто может вести сложные задачи. Я расскажу, как мы слепили потоковую структуру и фича-лидство в одну работающую связку, и она реально убрала бутылочные горлышки. Мы пошли на серьёзный, даже рискованный шаг. И это сработало: новый продукт в жёсткие сроки в параллель с адаптацией к новым ценностям. И да - никто не уволился.

Кажется, что рост команды автоматически масштабирует систему. Но на практике после 30–50 человек часто начинает ломаться то, что раньше работало «само собой»: передача контекста, коммуникации, инициативность сотрудников и базовые процессы. Особенно когда вокруг постоянные изменения, давление бизнеса и фриз найма.

Поговорим о том, почему организации начинают незаметно откатываться обратно в модель «маленькой команды», и как лидерство и работа с контекстом становятся главными ограничениями роста.

Мой доклад для тех, кто уже столкнулся или вот-вот столкнётся с ростом, масштабированием. Либо когда из одного продукта вырастают в экосистему, появляется несколько платформ, десятки команд и сотни зависимостей. В этот момент классические процессы перестают работать: теряется предсказуемость, команды начинают конфликтовать за ресурсы и приоритеты, а управление превращается в постоянное «тушение пожаров». Я расскажу, как с этой сложностью работать не через усложнение процессов, а наоборот через их упрощение. Покажу практическую модель выстраивания полного цикла от идеи до релиза в условиях экосистемы, где одновременно развивается 60+ компонентов и работают сотни людей.

Участники вынесут из выступления не теорию, а применимый подход: поймут привычные процессы ломаются при масштабировании, где на самом деле рождается хаос и как его убрать, как управлять зависимостями между командами и при этом сохранять скорость. Я поделюсь инструментами, которые помогают повышать предсказуемость без бюрократии и выстраивать синхронную работу команд вместо конкуренции. Скорее всего они могут увидеть лишнюю сложность в своих процессах и понять, как их упростить. Появляется понимание, что даже самые сложные продуктовые системы можно сделать управляемыми и понятными, если правильно спроектировать процессы.

▪️Клиенты - внешний контур:  Как «чтение» эмоций клиента помогает закрывать сложные сделки. Почему высокий EI - это главный драйвер роста LTV и лояльности в B2B/B2C.

▪️Команда - внутренний контур: Как замечать скрытое напряжение в команде до того, как сотрудник положит заявление на стол. EI как инструмент удержания сильных специалистов.

▪️Лидер - иммунитет к выгоранию: Как вовремя сканировать свое состояние и понимать маркеры «я на грани». Инструменты восстановления.

▪️Эмоциональный тайм-менеджмент : Как не бороться со своим настроением, а использовать его. Подбор задач под эмоцию: почему легкая злость идеальна для поиска информации, грусть - для диагностики проблем, а радость - для креатива и мотивации команды.

Расскажу о том, как планирование влияет на качество и продолжительность жизни, приведу примеры исследований по теме, которые это доказывают. Детально разберем с примерами: * что такое личное стратегическое планирование; * инструменты работы с планированием; * как ставить цели, чтобы они работали; * как внедрять в жизнь новые привычки; * как проводить чек ап или ревизию целей.

Не жди, пока сгорит: как психология помогает видеть кризис до того, как он станет пожаром

Выгорание в команде - это не внезапный баг. Это технический долг, который накапливается месяцами. Но в отличие от кода, психологические маркеры кризиса часто остаются «невидимыми» до момента срыва.

На этом мастер-классе вы получите авторский инструмент прогнозирования выгорания, основанный на 13 годах работы с тимлидами и научных исследованиях в области психологии личности. Мы разберём, как применять регрессионные модели из академической психологии для предсказания поведенческих паттернов в команде и превращать «интуицию» в диагностируемые метрики.

Что будет: 1. 5 ранних сигналов кризиса: не «человек устал», а конкретные поведенческие маркеры (срыв дедлайнов без объяснений, молчание на ретро, токсичность в чатах, искажение самоотношения, падение эмпатийного отклика) 2. Модель «4 батарейки» для быстрого восстановления ресурсного состояния - своего и команды, помогающий встроить психологическую устойчивость в рабочие ритуалы. 3. Скрипты экстренного 1:1 разговора на случай, если прогноз сбылся 4. Ответы на сложные вопросы

Для кого: тимлиды, руководители команд, HR-партнёры, все, кто управляет людьми в условиях неопределённости.

Что унесёте с собой: готовый инструменты прогнозирования, чек-лист экстренной интервенции и понимание, как отличить выгорание от профнепригодности.

Спикер: Екатерина Камчатова - магистр психологии, практикующий психолог с 14-летним опытом работы с тимлидами в корпоративном секторе, основатель центра психологии и корпоративного развития "БЕРИ МЕНЯЙ", автор исследований по прогнозированию профессиональной компетентности взрослых.

Если вы не собираетесь менять высоконагруженный темп, и при этом не желаете дойти до выгорания - этот воркшоп поможет понять, что с этим делать. А ещё, поможет понять, по какой причине вы до этого не отдыхали вовремя, а может даже уже выгорали.

Будет игровая практика (ничего эпатажного, но надо будет подвигаться), микропорции теории и обсуждение в тройках. Проверенные решения тоже будут - поделюсь успешными кейсами высоконагруженных и не выгоревших.

О чём поговорим:

• Почему нельзя построить оргструктуру один раз и на века

• Какие есть триггеры к изменению оргструктуры и почему какие-то из них очевидны, а какие-то «выдумало начальство»

• Как оргструктура сказывается на поставке бизнес-ценности и развитии сотрудников

• Как можно влиять на оргструктуру, даже если ты думаешь, что никак

Доклад будет полезен всем, кто хочет принимать активное участие в жизни своей команды и влиять на общую организацию работ.

У IT и производства общая боль: решения сверху работают недолго, идеи снизу тонут в обсуждениях, потому что изменения процессов — это всегда про людей, а не про сферу деятельности. Покажу, как мы применением гибкие методологии в негибкой производственной отрасли, что нам помогает улучшать бизнес-процессы в командах, далёких от проектной культуры.

Рассмотрим как сильно может отличаться позиция тимлида в зависимости от структуры компании, как в этих компаниях происходит становление позиции тимлида, как они сталкиваются со своими задачами, и какие есть механизмы для их решения. Найдем как отличия, так и общие паттерны

Почти в любой команде люди отличаются сильнее, чем кажется на первый взгляд. Этому способствуют различный опыт, этап в карьере и мотивация, плюс все по-разному относятся к риску, обратной связи, ответственности, правилам или темпу изменений. И на ежедневной основе руководителю довольно легко эти различия не заметить или обобщить – и в итоге либо ждать, что все одинаково воспримут задачи, изменения и коммуникацию, либо навесить ярлыки и работать скорее не с людьми, а со своими представлениями о них.

В докладе хочу показать, какие различия действительно влияют на совместную работу и как вместо раздувания конфликта можно использовать их как точку роста для команды. Вдобавок на практике научимся диагностировать, как, например, отличать разницу в опыте от разницы в мотивации и находить корень проблемы – будь он в жизненном этапе, профессиональной культуре или просто в несовпадении ожиданий.

Команда поставила цели, составила планы, запустила инициативы, проводит синки, ретроспективы и планирования. Все заняты, работа кипит, но стратегические результаты движутся гораздо медленнее, чем ожидалось. Обычно такие ситуации объясняют слабой дисциплиной, плохим целеполаганием или необходимостью внедрить очередную управленческую практику. Однако во многих случаях проблема находится глубже.

На основе анализа более 350 клиентских кейсов мы с Надеждой Беловой разработали диагностическую карту разрывов в цепочке достижения целей. Она позволяет определить, где именно возникает разрыв между целью и результатом, какие симптомы на это указывают и на каком уровне находится проблема: управленческом, организационном, культурном или когнитивном.

Это не доклад, а практический мастер-класс. Каждый участник проведёт диагностику собственной команды, определит наиболее вероятные точки разрыва в своей цепочке достижения целей, разберёт причины их возникновения и сформирует индивидуальный план действий по их устранению на ближайшие три месяца. В результате участники уйдут не только с новой моделью мышления, но и с конкретным инструментом для работы со своей командой.

• Почему классические ИПР часто не работают в менеджерских командах и как этого избежать при запуске процесса с нуля.
• Модель OSKAR: разбираем структуру коучингового подхода (Outcome, Situation, Know-how, Affirmation, Review).
• Как переложить ответственность за развитие с плеч руководителя на сотрудника, не потеряв контроль.
• Практики соединения скучных бизнес-задач с личными целями сотрудника.
• Результаты года практики: как изменилась вовлеченность команды из 5 человек и сколько моего времени это сэкономило.