Как делегировать: отпускать контроль так, чтобы ничего не ломалось

Спикер: Олег Федоткин

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

Главная ошибка — делегировать всем сотрудникам в команде одинаково. Один сотрудник уже готов владеть скоупом, другому пока нужно объяснить, почему задача вообще важна. Для того, чтобы адаптировать стиль делегирования под конкретного человека, можно использовать фреймворк с уровнями делегирования.

Фреймворк работает, когда:
— Руководитель и сотрудник одинаково понимают текущий уровень делегирования.
— Уровень относится к задаче, а не к человеку.
— Уровень — это не оценка.

Уровень 1. Инструктор

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

Вы — инструктор, вам следует:
• объяснить, почему задачу важно решить;
• дать инструкцию по выполнению;
• контролировать выполнение;
• провести ретроспективу.

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

Уровень 2. Коуч

Сотрудник находится в позиции «есть варианты, нет решения».

На этом уровне сотрудник уже способен предложить решения, но не всегда может оценить, какое решение выбрать. Главная ошибка на этом уровне — решать за сотрудника. Это быстро и удобно для руководителя, но не развивает самостоятельность сотрудника.

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

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

Уровень 3. Штурман

Сотрудник находится в позиции «есть план, но нет уверенности в нем».

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

Вы помогаете сотруднику пройти уже выбранный им маршрут, а не нарисовать новый.

Уровень 4. Страхующий

Сотрудник находится в позиции «есть план, буду действовать».

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

Вы наблюдаете, ваша помощь потребуется, только если что-то пойдет не так.

Уровень 5. Продюсер

Сотрудник находится в позиции «я владею скоупом».

Если на уровнях 1–4 руководитель делегировал проблему или задачу, то на данном уровне руководитель погружает человека в скоуп работы. И сам сотрудник уже через запросы и обратную связь формирует задачу и план по ее выполнению, выполняет и отчитывается по результатам.

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

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

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

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

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

@pplsense

Почему сотрудники конфликтуют. Как перевести напряжение в управляемое решение

Спикер: Екатерина Миронова

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

Это провоцирует тревогу. Чтобы справляться с тревогой, психика включает защиты. И одна из них — конфликт. Серая зона выбила нас, профессиональная шляпа слетела, работать мы нормально теперь не можем. Зато мы отлично можем эмоционировать, причем часто с избытком. Что делать в таких случаях?

Мы, как руководители, можем уменьшать количество таких серых зон для наших сотрудников. И важно помнить: наша задача — разобраться, что неясно, а не искать виноватых.

Один из инструментов для этого — диагностика по модели BART.
B — boundaries / границы зоны ответственности: где заканчивается ваша зона ответственности и начинается зона другого человека или команды?
A — authority / достаточность полномочий: есть ли у вас все ресурсы, чтобы выполнить задачу? Вас воспринимают как человека, который уполномочен это делать, или нет?
R — role / ясность роли: какую роль вы исполняете в этом проекте? Человек, принимающий решение / консультант / исполнитель?
T — task / понятность задачи: а что конкретно вы должны делать и какой образ результата от вас ожидают?

Каждый из четырех пунктов можно подкрутить с помощью понятных инструментов.

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

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

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

А что делать, если ваш сотрудник уже провалился в эмоции?

«Бесполезно учить человека плавать в момент, когда он тонет» — отличная иллюстрация такой ситуации. Поэтому ваша задача — сбавить градус эмоций до уровня, на котором сотрудник сможет перейти к конструктивному обсуждению ситуации:
— Даем безопасное пространство и ограниченное время, чтобы выразить эмоции.
— Меняем фокус на профессиональный контекст (можем использовать вопрос «А какую рабочую задачу ты пытался решить?»).
— Определяем, где находится серая зона по BART.
— Подбираем инструмент, чтобы разобрать конфликт и предотвратить его повторение.

Также важно помнить, с какой позиции смотреть на конфликт, чтобы достичь успеха:
1) Сотрудник vs сотрудник: «я против тебя».
2) Коллега и коллега vs проблема: «мы вместе против ситуации».
Какой из вариантов поможет прийти к решению и сохранить отношения? Думаю, ответ вы знаете.

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

И напоследок: конфликты — это нормально. Они подсвечивают вам серые зоны и показывают, что вашим сотрудникам не все равно. Если вы умеете решать конфликты — это дорогой навык. А если в команде совсем нет конфликтов, это тоже повод присмотреться: возможно, люди не спорят, не предлагают идеи и не чувствуют, что могут влиять на результат. И с этим тоже нужно что-то делать. Но это уже совсем другая история.

@pplsense

Внедрение искусственного интеллекта на 500 инженеров: как его растить и почему быстрее не становится?

Спикер: Марат Киньябулатов

Согласно опросам McKinsey, 88% организаций в 2025 году используют хотя бы один ИИ-инструмент. При этом всего 6% получили реальный эффект, а 43% инициатив были отменены или провалились. Основная причина провалов — отсутствие четкого понимания, зачем внедрять ИИ. Далее расскажу про наш опыт: гипотезу, примеры внедрения и эффект, который мы получили.

В нашей компании мы фокусируемся на том, чтобы быстро доставлять ценность клиенту. В delivery мы следим за тремя метриками:
1. Lead time — время от взятия задачи в работу до релиза.
«За сколько сделаем?»
2. Throughput — количество реализованных элементов.
«Сколько делаем?»
3. Defect rate — доля багов в общем потоке задач.
«Не ломаем ли ничего по пути?»

От внедрения ИИ мы ожидали, что сократим время, увеличим количество релизов и сохраним стабильный уровень ошибок.

Но как измерять само внедрение?

Мы использовали две метрики:
— MAU: сколько людей открывали инструмент за месяц;
— MAU 10+: сколько людей работали с ИИ 50%+ рабочих дней.
Так мы смотрели не только общий охват, но и регулярность привычки.

Почему люди сопротивляются внедрению ИИ?

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

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

Сейчас мы идем в сторону end-to-end agentic engineering — модели, в которой агенты берут на себя максимум рутинной и подготовительной работы, а инженер оркестрирует процесс на каждом этапе.
Чтобы к этому прийти, недостаточно просто нарастить использование агентов, следует развить необходимые скиллы, выстроить агентов под разные этапы разработки и дать инженерам полное понимание процесса разработки.

Как повышать использование ИИ?

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

Особенно важно работать с руководителями. Если лидер сам показывает пример, команде проще пробовать новое без страха ошибиться.
По нашему опыту: если вовлечь техлида, до 40% его команды начинают пользоваться ИИ. Если настроить обмен опытом внутри команды — можно получить еще +10–15 п.п. активного использования.

Лучшие результаты получают те, кто выстраивает процессы вокруг ИИ, а не пытается адаптировать текущие. Поэтому делимся теми шагами, которые помогут вам начать внедрение.

Четыре шага:
1. Поймите, зачем вы это делаете.
2. Выберите первый набор метрик.
3. Экспериментируйте.
4. Валидируйте гипотезы.

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

@pplsense