Люди: менторинг, рост и конфликты - Деконструкция реальности

О чём этот модуль

Работа с людьми — не дополнительный слой «soft skills» поверх настоящей инженерной работы.

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

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

"мотивирован"
"немотивирован"
"сильный"
"слабый"
"токсичный"
"лояльный"
"командный"

Такая категория может обозначить впечатление наблюдателя, но ещё не объясняет причинность.

Менеджерская подмена:
"Будь добрее к людям".

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

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

Понимание причины не означает автоматического оправдания поведения.

Понять ≠ согласиться.
Объяснить ≠ оправдать.
Поддержать ≠ отменить стандарт.
Установить границу ≠ унизить.
Применить последствия ≠ отказаться от анализа.

Результаты обучения

После модуля участник должен уметь:

отличать наблюдаемое поведение от собственной интерпретации человека;
диагностировать, что именно ограничивает действие: знание, навык, ясность, capacity, полномочия, несогласие, страх, смысл или сознательное противодействие;
строить capability map вместо оценки человека одним словом junior / middle / senior;
выбирать разный режим менторинга для junior, middle и senior;
различать teaching, mentoring, coaching, sponsorship и delegation;
давать feedback через наблюдение, воздействие, стандарт и следующий шаг;
не превращать code review в публичную оценку интеллекта автора;
строить growth plan по наблюдаемому изменению способности;
различать task, process, role, relationship, resource и power conflicts;
отличать конфликт людей от конфликта ролей и границ ответственности;
отличать перегруз, непонимание и несогласие от устойчивого уклонения;
не называть саботажем то, для чего нет основания;
разговаривать с сильным, но разрушительным инженером без поклонения его локальной производительности;
предотвращать захват знаний, решений, коммуникации и доступа одним человеком;
защищать команду от внешнего давления, не скрывая от неё реальность;
защищать реальность от команды, когда коллективное мнение не выдерживает проверки;
фиксировать ожидания, поддержку, контрольные точки и последствия без карательного театра;
измерять развитие без подмены человека количеством commits, pull requests или story points.

1. Человек не равен роли

Backend Developer, Senior Engineer, QA, Team Lead — это организационные формы. Они обозначают ожидаемую функцию, но не исчерпывают человека.

Один Senior может:

глубоко понимать distributed systems;
плохо объяснять решения;
бояться публично признать неизвестность;
быстро действовать в incident;
теряться в мутных требованиях;
хорошо менторить junior;
разрушать peer discussion;
быть новичком в конкретном business domain.

Человек не "является Senior" целиком.

Он демонстрирует разный уровень самостоятельности
в разных видах деятельности и контекстах.

Почему это важно для лида

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

"Он Senior, должен сам разобраться"

может скрыть:

отсутствие domain context;
новую для человека технологию;
конфликт полномочий;
неизвестную внешнюю зависимость;
отсутствие решения, которое обязан принять Product;
перегруз несколькими критическими контурами.

И обратная подмена:

"Он Junior, поэтому ничего не может решить"

лишает человека возможности проявить уже существующую способность.

Лид использует уровень как модель текущей автономности, а не как онтологический приговор.

2. Наблюдение, интерпретация, гипотеза и решение

В работе с людьми особенно легко выдать реконструкцию внутреннего состояния за факт.

Наблюдение

"Три последние задачи были начаты,
но ни одна не дошла до review в согласованный срок".

Интерпретация

"Он безответственный".

Гипотезы

- задача была непонятна;
- человек не умеет декомпозировать;
- было слишком много параллельной работы;
- он избегает review;
- он не согласен с приоритетом;
- он сознательно не выполняет договорённость;
- существует неозвученное ограничение.

Решение

"Сначала восстановить фактический путь трёх задач,
проверить приоритеты, blockers и понимание Done.
После этого определить: обучение, изменение процесса,
прямая договорённость или performance intervention".

Главный принцип

Неизвестный мотив нельзя использовать как установленный факт.

Но отсутствие знания о мотиве
не отменяет наблюдаемого поведения и его последствий.

Лид может сказать:

"Я не знаю, почему ты трижды обошёл review.
Я знаю, что это произошло, что два изменения попали в production
без второго взгляда и что один случай создал incident.
Мне нужно понять причину и прекратить повторение".

3. Лид не психолог и не следователь внутренних сущностей

Лид работает с поведением, условиями, способностями, договорённостями и результатом.

Он не должен ставить человеку диагноз по рабочим проявлениям:

«у тебя депрессия»;
«ты нарцисс»;
«ты боишься успеха»;
«у тебя синдром самозванца»;
«ты пассивно-агрессивный».

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

Что лид может делать

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

"Последние две недели ты заметно реже отвечаешь,
а две задачи остановились без сообщения о blocker.
Есть ли рабочее ограничение, которое мне нужно учитывать?
Если ты не хочешь обсуждать личные причины, не надо.
Но нам нужно договориться, как blockers становятся видимыми".

Это одновременно сохраняет границу человека и не растворяет рабочую ответственность.

4. Диагностическая карта действия

Если человек не делает ожидаемое, лид проверяет несколько разных классов причин.

Причина	Диагностический вопрос	Возможное действие
Не знает, что требуется	Понимает ли человек outcome и Definition of Done?	Уточнить задачу, привести примеры, зафиксировать критерии
Не знает, как сделать	Есть ли нужная модель, техника или domain knowledge?	Teaching, pairing, документация, ограниченный пример
Не умеет устойчиво	Получалось ли только с помощью? Повторяется ли навык в другом контексте?	Практика с обратной связью, постепенное увеличение сложности
Не имеет доступа или полномочий	Может ли человек принять решение и выполнить действие?	Выдать доступ, определить decision rights, снять зависимость
Перегружен	Сколько незавершённой работы и переключений?	Сократить WIP, изменить приоритеты, убрать параллельные обязательства
Получает противоречивые сигналы	Кто ещё ставит задачи и что объявлено приоритетом?	Один порядок приоритетов, эскалация конфликта источников
Боится последствий	Что происходило раньше после ошибки или несогласия?	Изменить реакцию системы, безопасно разобрать ошибку, дать контролируемую автономность
Не согласен	Понимает ли он решение, но считает его неправильным?	Рассмотреть аргументы, определить владельца решения, зафиксировать disagree-and-commit или пересмотреть решение
Не видит смысла	Связана ли работа с результатом и понятна ли её необходимость?	Восстановить контекст либо признать, что работа действительно бессмысленна
Избегает неприятной части	Повторяется ли уход именно перед review, тестированием, коммуникацией?	Прямая граница, дробление, контрольная точка, последствия
Получает выгоду от бездействия	Стимулирует ли система задержку, незаменимость или героическое спасение?	Изменить incentives, ownership и прозрачность
Сознательно препятствует	Есть ли наблюдаемое намеренное действие против согласованного результата?	Containment, фактическое расследование, formal escalation
Упёрся в плохую систему	Может ли кто-либо стабильно выполнить работу при данных условиях?	Исправить процесс, архитектуру, tooling или границы

Не выбирать удобную причину заранее

Лид может предпочитать объяснение, которое лучше соответствует его стилю.

Жёсткий лид всё объясняет ленью.
Мягкий лид всё объясняет перегрузом.
Технический лид всё объясняет недостатком навыка.
Процессный лид всё объясняет плохим workflow.

Все эти причины реальны. Ни одна не должна становиться универсальным ответом.

5. Пять слоёв проблемы

Одно и то же внешнее проявление может находиться на разных уровнях.

Слой человека

Навык, знание, состояние, выбор, поведение.

Слой задачи

Неясный outcome, слишком большой scope, скрытая неизвестность.

Слой роли

Неопределённые полномочия, пересекающаяся ответственность, конфликт ожиданий.

Слой команды

Нормы коммуникации, review bottleneck, захват решений, отсутствие доверия.

Слой системы

Архитектура, процесс, incentives, внешние зависимости, невозможный workload.

Симптом:
инженер постоянно ждёт подтверждения лида.

Возможный слой человека:
не умеет принимать решение при неопределённости.

Возможный слой роли:
не знает, какие решения имеет право принимать.

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

Возможный слой системы:
любое изменение требует формального approval лида.

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

6. Capability map вместо одного уровня seniority

Junior, Middle и Senior удобны как грубые организационные уровни. Но для развития нужна многомерная карта.

Измерение	Вопрос
Technical execution	Может ли человек корректно реализовать решение?
Problem framing	Может ли превратить мутный запрос в определённую задачу?
Decomposition	Умеет ли разрезать работу на проверяемые части?
Domain knowledge	Понимает ли бизнес-правила и последствия?
System thinking	Видит ли зависимости, данные, production и downstream effects?
Uncertainty handling	Делает ли неизвестность явной? Умеет ли ставить spike?
Quality judgment	Различает ли обязательное качество, риск и вкусовщину?
Delivery	Доводит ли работу до результата, а не только пишет код?
Communication	Передаёт ли факты, решения, риски и неизвестное точно?
Collaboration	Может ли действовать в общей системе, не захватывая и не исчезая?
Operational ownership	Понимает ли поведение кода после deployment?
Learning	Превращает ли feedback и ошибку в изменение способа действия?
Influence	Улучшает ли способность других и устройство команды?

Уровень всегда контекстен

Senior backend engineer
может быть novice в Kubernetes incident response.

Сильный domain expert
может быть beginner в системном дизайне.

Middle developer
может демонстрировать senior-level способность
в диагностике production problems.

Модель приобретения навыка Дрейфуса различает движение от опоры на явные правила к распознаванию ситуационного контекста и более целостному действию. Для лида важен не культ «экспертной интуиции», а практический вывод: новичку и опытному человеку нужна разная форма поддержки. (Dreyfus: Five-Stage Model of Adult Skill Acquisition)

Evidence levels

Способность можно описывать не впечатлением, а уровнем проявления:

1. Понимает с объяснением.
2. Выполняет с прямой поддержкой.
3. Выполняет самостоятельно в знакомом контексте.
4. Переносит навык в новый контекст.
5. Объясняет trade-offs и исправляет собственные ошибки.
6. Передаёт способность другим.
7. Изменяет систему так, чтобы способность стала свойством команды.

7. Менторинг Junior

Junior обычно не неразумен. У него недостаточно устойчивых моделей и опыта различать значимые детали.

Что ему нужно

определённый outcome;
ограниченный scope;
доступный пример;
частый feedback loop;
объяснение не только как, но и почему;
возможность задать вопрос без публичного приговора;
постепенное увеличение автономности;
защита от задачи, в которой неизвестны все границы одновременно.

Плохой менторинг

"Разберись сам — так ты вырастешь".

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

Другая крайность:

"Я сейчас сам быстро сделаю и покажу".

Лид получает код, junior получает доказательство собственной ненужности.

Scaffolding

Поддержка строится ступенями:

1. Показать один полный пример.
2. Выполнить следующую задачу вместе.
3. Дать похожую задачу с контрольной точкой.
4. Дать самостоятельную задачу и review результата.
5. Попросить объяснить решение другому человеку.

Вопросы Junior

Вместо:

"Ну что здесь непонятного?"

лучше:

"Как ты сейчас понимаешь результат?"
"Какие состояния видишь?"
"Где заканчивается известное?"
"Какой самый маленький шаг даст наблюдение?"
"Что произойдёт при повторном запросе?"

Лид не отдаёт готовое мышление. Он делает видимым способ построения мышления.

Ошибка Junior

Ошибка разбирается по причинности:

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

Не:
"Ты опять не подумал".

А:
"Ты проверил happy path, но не выделил повторную доставку
как отдельное состояние. Давай построим state table
до следующей реализации".

8. Менторинг Middle

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

Задачи развития

самостоятельно уточнять требования;
разрезать feature;
оценивать риск;
видеть интеграционные границы;
сообщать blocker до срыва;
предлагать варианты, а не только проблему;
принимать локальные решения;
доводить изменение до production;
понимать последствия для других ролей.

Главная ловушка

Middle может хорошо писать код, но продолжать ждать, пока лид соберёт весь смысл.

Лид:
ставит задачу, уточняет requirement, выбирает решение,
разрезает, напоминает, проверяет, эскалирует.

Middle:
реализует центральную часть.

Техническое выполнение есть, ownership ещё не сформирован.

Как расширять автономность

Не:
"Сделай интеграцию с провайдером".

А:
"Возьми ownership за первый рабочий slice интеграции.
Сам уточни обязательный сценарий, составь список неизвестного,
предложи contract и plan. До реализации проведём design checkpoint".

Лид меняет не только сложность задачи, но и уровень решения, которое передаёт человеку.

Feedback для Middle

Часто feedback должен касаться не качества кода, а формы ведения работы.

"Техническое решение корректно.
Проблема в том, что отсутствие sandbox стало известно в понедельник,
а в risk update попало в четверг. На следующей интеграции
мне нужен dependency map до начала implementation".

9. Менторинг Senior

Senior не перестаёт нуждаться в развитии. Меняется объект развития.

Возможные зоны роста

качество архитектурного выбора;
работа с неоднозначными constraints;
влияние без захвата;
передача контекста;
создание decision frameworks;
снижение cognitive load команды;
работа с production risk;
mentoring других уровней;
способность отказаться от любимого решения;
различение локального совершенства и результата системы.

Не учить Senior как Junior

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

Junior:
"Вот ограниченная задача и опорный пример".

Senior:
"Вот outcome, constraints, decision boundary
и последствия, которые надо удержать".

Senior должен увеличивать систему, а не только себя

Сильный индивидуальный результат недостаточен, если после человека остаются:

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

Senior-level leverage:
после действия сильнее становится не только код,
но и способность команды работать с этим классом задач.

Менторинг через challenge

"Решение технически сильное.
Теперь покажи, как команда будет его эксплуатировать без тебя:
какие contracts, observability, ADR, runbook и migration path нужны?"

10. Teaching, mentoring, coaching, sponsorship и delegation

Эти режимы решают разные задачи.

Исследование Google Project Oxygen одновременно выделяет coaching, empowerment без микроменеджмента, поддержку карьерного развития, ясную коммуникацию, ориентацию на результат и способность принимать сильные решения. Для этого модуля важно именно их соединение: развитие человека не противоположно требовательности к результату, а микроменеджмент не является единственным способом эту требовательность удержать. (Google re:Work: Research Behind Great Managers)

Режим	Что делает лид	Когда нужен
Teaching	Передаёт конкретную модель или технику	Человек не знает способ
Mentoring	Передаёт накопленные различения и помогает применить их в контексте	Нужна профессиональная ориентация
Coaching	Вопросами помогает человеку построить собственное решение	Способность уже есть, но мысль не собрана
Sponsorship	Даёт видимость, доступ к возможности и защищает право человека попробовать	Способность есть, но нет организационного входа
Delegation	Передаёт решение и ответственность в определённых границах	Человек готов действовать автономно

Антипаттерн: coaching вместо знания

Junior не знает, как работает транзакционная изоляция.
Лид час задаёт вопросы: "А как ты сам думаешь?"

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

Антипаттерн: teaching вместо решения

Senior понимает варианты, но должен принять trade-off.
Лид читает ему лекцию и фактически принимает решение сам.

Здесь нужна decision boundary и передача ответственности.

Sponsorship без фаворитизма

Дать человеку вести design review, представить результат стейкхолдерам или взять ownership за сервис — это не награда за симпатию. Основание должно быть связано с capability и developmental goal.

11. Цикл развития способности

Рост не создаётся формулировкой «тебе надо стать самостоятельнее».

Способность
→ задача подходящей сложности
→ действие
→ наблюдение
→ feedback
→ повторение в новом контексте
→ расширение автономности

Хорошая developmental task

Она находится выше текущей устойчивой способности, но не превращает человека в единственную точку отказа.

Содержит:

конкретную способность;
реальную работу, а не учебную имитацию;
bounded risk;
checkpoint;
доступ к помощи;
критерий успешности;
последующий разбор.

Слишком простая задача

Человек повторяет уже известное и получает больше стажа, но не обязательно больше способности.

Слишком большая задача

Человек тонет одновременно в domain, architecture, politics, delivery и communication. По результату невозможно понять, какая способность отсутствовала.

Рост требует права на наблюдаемую ошибку

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

Но риск должен быть ограничен:

feature flag;
review;
sandbox;
небольшой scope;
reversible decision;
checkpoint до необратимого действия.

12. Уровни delegation

Фраза «я делегировал» ничего не сообщает о границе решения.

Уровень 1. Выполни по инструкции

Я определил способ. Твоя задача — корректно выполнить.

Уровень 2. Исследуй и принеси факты

Решение остаётся у меня. Ты собираешь пространство данных.

Уровень 3. Предложи варианты

Подготовь варианты, trade-offs и рекомендацию.
Решение примем вместе или приму я.

Уровень 4. Прими решение после checkpoint

Ты владеешь решением, но перед выполнением мы проверяем основание.

Уровень 5. Реши и сообщи

Ты принимаешь решение в заданной границе и сообщаешь результат.

Уровень 6. Владей контуром

Ты отвечаешь за outcome, систему решений, риски и коммуникацию.
Эскалируешь только выход за границу.

Ошибка delegation

Лид думает:
"Я передал ownership".

Инженер думает:
"Мне разрешили собрать варианты,
но любое решение всё равно надо согласовать".

Неопределённая delegation создаёт либо микроменеджмент, либо неожиданное обвинение в том, что человек «не проявил ownership».

13. Growth plan: не список курсов, а изменение способности

Плохой план роста:

- изучить Kubernetes;
- улучшить коммуникацию;
- стать проактивнее;
- прочитать книгу по архитектуре.

Невозможно определить, что должно измениться в действии.

Структура growth plan

Capability:
какую способность развиваем.

Current evidence:
что человек уже делает и где граница.

Target behavior:
какое действие должно стать самостоятельным и устойчивым.

Practice:
на какой реальной работе способность будет проявлена.

Support:
какая помощь, контекст и доступ доступны.

Evidence:
по чему поймём, что изменение произошло.

Checkpoint:
когда разбираем наблюдение.

Пример

Capability:
управление интеграционной неизвестностью.

Current evidence:
реализует определённый contract,
но поздно сообщает о внешних blockers.

Target behavior:
до implementation строит dependency map,
выделяет неизвестное и предлагает spike.

Practice:
интеграция с новым notification provider.

Support:
один design checkpoint и доступ к architect.

Evidence:
risk register создан до начала coding;
изменение forecast сообщено в день появления факта.

Promotion не должна быть тайной

Человек должен понимать:

какие способности требуются;
какие evidence уже есть;
какой evidence отсутствует;
какие возможности организация реально может предоставить;
кто принимает решение.

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

14. One-on-one: не статус-митинг и не допрос души

1:1 нужен для тем, которые трудно удержать в общем delivery flow. (Для интервью: One-on-one: какую функцию он выполняет.)

Возможные контуры

workload и capacity;
блокирующие отношения и зависимости;
понимание роли;
feedback в обе стороны;
growth plan;
невидимая работа;
границы;
конфликт приоритетов;
организационные изменения;
смысл текущей работы для человека.

Что не надо делать

превращать всё время в пересказ Jira;
требовать эмоциональной открытости;
добывать личные подробности;
обещать то, на что лид не имеет полномочий;
сохранять чувствительные интерпретации как факты;
ждать 1:1, чтобы сообщить срочный feedback.

Структура

1. Что сейчас требует внимания?
2. Где твоя работа упирается не в код?
3. Есть ли противоречивые ожидания?
4. Какой feedback нужен от меня?
5. Что изменилось по growth goal?
6. О чём мы договорились и кто владелец действия?

Заметки

Фиксируются договорённости и рабочие факты, а не психологический портрет.

Хорошо:
"До пятницы лид уточняет ownership billing alerts.
Инженер готовит два варианта передачи компонента".

Плохо:
"Кажется тревожным, склонен к избеганию ответственности".

15. Feedback: передача причинности, а не оценка личности

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

Feedback, evaluation, instruction и consequence

Feedback:
"Когда произошло X, твоё действие Y создало эффект Z".

Evaluation:
"Сейчас способность проявляется на таком уровне".

Instruction:
"В следующем случае действуй так".

Consequence:
"Если граница снова будет нарушена,
ownership или роль изменятся".

Смешивание создаёт туман. Человек думает, что обсуждается один эпизод, а лид в голове уже принимает кадровое решение.

Основание feedback

Center for Creative Leadership предлагает модель SBI: Situation, Behavior, Impact — назвать конкретную ситуацию, описать наблюдаемое поведение и его воздействие, не подменяя факты оценкой мотива. Затем можно исследовать intent. (Center for Creative Leadership: SBI Feedback)

Для lead-level разговора полезно расширить модель:

Situation
→ Observation / Behavior
→ Impact
→ Expected standard
→ Inquiry
→ Next agreement

Пример

Situation:
на design review во вторник.

Behavior:
ты трижды перебил Анну до завершения аргумента
и назвал её вариант "детским".

Impact:
обсуждение перешло с trade-offs на защиту статуса;
Анна перестала представлять второй вариант,
а команда не проверила migration risk.

Expected standard:
критиковать решение через constraint и consequence,
не оценивать интеллект автора и не прерывать изложение.

Inquiry:
что ты пытался предотвратить в тот момент?

Next agreement:
на следующем review ты сначала фиксируешь риск,
затем задаёшь вопрос и ждёшь полный ответ.

Intent и impact

Хорошее намерение не отменяет воздействие.

"Я хотел ускорить обсуждение"

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

И обратное: плохое воздействие не доказывает злое намерение.

16. Как давать трудный feedback

Не откладывать до performance review

Чем дольше лид молчит, тем больше поведение выглядит разрешённым.

Давать на конкретном материале

Не:
"Ты плохо коммуницируешь".

А:
"В трёх последних risk updates не было указано,
какое решение требуется от Product и до какого момента".

Не создавать обвинительный архив внезапно

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

Не использовать sandwich как маскировку

"Ты отличный специалист, но...
зато вообще всё хорошо".

Человек вынужден угадывать, какая часть настоящая.

Прямота может быть спокойной:

"У меня есть трудный feedback по способу review.
Он не ставит под вопрос твою техническую силу.
Он ставит вопрос о конкретном поведении,
которое разрушает способность команды обсуждать решения".

Дать человеку ответить

Feedback — не судебный приговор. Факты могут быть неполными.

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

17. Положительный feedback без ритуальной похвалы

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

Слабо:
"Молодец, хорошая работа".

Сильно:
"На интеграции ты до начала coding выделил три неизвестных,
проверил sandbox отдельным spike и на второй день обновил forecast.
Из-за этого команда не потеряла неделю на неверный OAuth flow.
Это именно тот способ управления неизвестностью,
который нужно повторять в следующих интеграциях".

Такой feedback:

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

Не хвалить врождённую сущность

"Ты гений"

создаёт статус, который потом приходится защищать.

Полезнее фиксировать способ видеть, принимать решение и доводить результат.

18. Code review без унижения

Code review оценивает изменение, а не человеческую ценность автора.

Комментарий должен иметь тип

blocking:
без исправления изменение создаёт дефект или существенный риск.

suggestion:
есть более сильный вариант, но текущий допустим.

question:
нужен контекст или проверка понимания.

nit:
мелкая стилистика без влияния на решение.

Если всё написано одинаково повелительно, автор не может различить архитектурный риск и вкус reviewer.

Критиковать причинность

Плохо:
"Что за бред? Переделать".

Нормально:
"Blocking: retry выполняется после частичной записи,
но операция не имеет idempotency key.
Повторный запрос может создать две транзакции.
Предлагаю перенести ключ на boundary команды или обсудить другой способ".

Не устраивать pile-on

Когда пять reviewers повторяют одну и ту же претензию, дополнительная ценность почти нулевая, а публичное давление растёт.

Лид может собрать feedback в один контур и назначить одного primary reviewer.

Повторяющаяся проблема выносится из PR

Если человек систематически не понимает state management, тридцать комментариев в каждом pull request не являются менторингом.

Нужен отдельный разговор:

какая модель отсутствует;
какой пример разобрать;
какая practice task нужна;
когда способность проверяется снова.

Автор имеет право возразить

Review не является иерархическим голосованием. Автор может показать, что reviewer не учёл constraint.

После аргументов должен существовать decision owner, иначе PR превращается в бесконечный спор статусов.

19. Psychological safety без снижения стандартов

Psychological safety означает, что человек может:

задать вопрос;
признать ошибку;
сообщить риск;
не согласиться;
сказать «я не знаю»;
предложить непопулярную гипотезу;

не ожидая унижения или статусного уничтожения.

Она не означает:

отсутствие требований;
запрет жёсткого feedback;
гарантированное согласие;
свободу разрушать других;
отмену ответственности;
право не выполнять договорённость.

Исследования Google о team effectiveness выделяют psychological safety вместе с dependability, structure and clarity, meaning и impact. Это важно: безопасность не заменяет способность выполнять обещанное и ясность устройства работы. (Google re:Work: Team Effectiveness)

Эми Эдмондсон отдельно подчёркивает, что psychological safety не равна снижению стандартов или отказу от accountability. (Amy Edmondson: Psychological Safety Does Not Equal Anything Goes)

Сильная команда удерживает две оси

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

Высокий стандарт:
правда приводит к действию и ответственности.

Без безопасности ошибки скрываются.

Без стандарта ошибки обсуждаются бесконечно, но система не меняется.

20. Что такое конфликт

Конфликт — не обязательно взаимная неприязнь. Это несовместимость позиций, интересов, правил, ресурсов, ролей, решений или способов действия.

Типы конфликтов

Тип	Объект
Task conflict	Что является правильным решением или содержанием работы
Process conflict	Как работа должна быть выполнена и распределена
Role conflict	Кто отвечает и кто принимает решение
Priority/resource conflict	Какой outcome получает ограниченное время и capacity
Standard conflict	Какой уровень качества, риска или evidence достаточен
Relationship conflict	Взаимное отношение, недоверие, презрение, накопленная обида
Power conflict	Кто имеет право определять рамку и чьё слово считается окончательным
Boundary conflict	Где заканчивается ответственность одной стороны и начинается другая

Исследования внутригрупповых конфликтов различают как минимум task, relationship и process conflict. Это полезно не как окончательная классификация реальности, а как напоминание: спор о решении, спор о распределении работы и личная враждебность требуют разных вмешательств. (Jehn: Intragroup Conflict)

Конфликт не всегда надо «сгладить»

Если backend и security расходятся по допустимому риску, дружелюбная атмосфера не решает вопрос.

Нужно определить:

какой constraint обязателен;
кто владелец риска;
какое evidence принимается;
кто принимает решение;
как фиксируются последствия.

21. Конфликт людей или конфликт ролей

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

Tech Lead считает себя владельцем архитектурных решений.
Architect считает себя владельцем архитектурных решений.
Engineering Manager обещает сроки без обоих.

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

Диагностический counterfactual

Если заменить обоих людей другими,
останется ли та же структурная коллизия?

Если да, вероятен конфликт ролей.

Признаки role conflict

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

Решение

Нужно определить:

Outcome owner
Decision owner
Required contributors
Who must be consulted
Who must be informed
Escalation path
Replacement boundary

Разговор «давайте больше уважать друг друга» не устранит пересечение decision rights.

22. Conflict map

Перед вмешательством лид строит карту.

Объект конфликта:
что именно несовместимо.

Наблюдаемые факты:
что произошло.

Позиция стороны A:
какое решение она требует.

Позиция стороны B:
какое решение требует другая сторона.

Основания:
какие constraints, риски и интересы находятся под позициями.

Неизвестное:
каких данных не хватает.

Decision owner:
кто имеет право завершить неопределённость.

Resolution criterion:
по чему будет принято решение.

Позиция и основание

Позиция QA:
"Не выпускаем".

Основание:
не проверена миграция 12 миллионов записей,
rollback отсутствует.

Позиция Product:
"Выпускаем сегодня".

Основание:
завтра внешний deadline,
а обязательный сценарий нужен одному сегменту.

Возможное решение появляется не через среднее между «да» и «нет», а через новую форму:

rollout только для сегмента;
feature flag;
миграция части данных;
manual fallback;
перенос необязательного scope.

23. Разговор между конфликтующими сторонами

Перед общей встречей

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

Правила

1. Обсуждаем наблюдаемое действие и решение.
2. Не приписываем мотив как факт.
3. Не перебиваем изложение основания.
4. Отделяем обязательный constraint от предпочтения.
5. Фиксируем неизвестное.
6. Определяем decision owner и срок решения.

Структура

Лид:
"Общий объект — безопасный release к внешней дате.
Сейчас конфликт находится между отсутствием rollback
и стоимостью переноса. Сначала фиксируем факты каждой стороны,
затем варианты. Личные оценки друг друга в решение не входят".

Не требовать немедленной эмоциональной гармонии

Люди могут не начать нравиться друг другу. Для работы достаточно:

прекратить разрушительное поведение;
определить границы;
восстановить предсказуемую коммуникацию;
принять решение;
выполнять договорённость.

Когда медиация не подходит

Если есть угроза, злоупотребление доступом, преследование, сознательное повреждение или другое серьёзное нарушение, нельзя симметрично оформлять это как «две стороны не поняли друг друга».

Сначала требуется containment и применение соответствующего организационного процесса. Диалог не должен становиться способом заставить затронутую сторону договариваться с продолжающимся нарушением.

24. Как отличать лень от непонимания

Слово «лень» часто сжимает разные причины в моральную сущность.

Возможные основания низкого продвижения

человек не понял outcome;
задача превышает текущую способность;
нет доступа;
приоритеты конфликтуют;
работа слишком крупная и не имеет feedback loop;
человек боится показать промежуточный результат;
он истощён;
не согласен и выражает это бездействием;
избегает неприятной ответственности;
действительно выбирает не выполнять согласованную работу при наличии способности и условий.

Последний вариант существует. Но его надо установить, а не предположить первым.

Диагностическая последовательность

1. Попросить человека сформулировать outcome своими словами.
2. Попросить показать текущий state работы.
3. Восстановить timeline действий и ожиданий.
4. Проверить WIP и конкурирующие обязательства.
5. Проверить доступы и dependencies.
6. Проверить, где именно работа останавливается.
7. Зафиксировать следующий малый результат и срок.
8. Посмотреть, меняется ли поведение после устранения неясности.

Наблюдаемое устойчивое уклонение

О нём можно говорить, если:

результат и границы ясны;
способность подтверждена;
capacity существует;
blockers сняты;
человек согласился с обязательством;
он повторно не выполняет действие;
не сообщает об изменении;
после прямого feedback pattern сохраняется.

Тогда проблема уже не обязана называться «непониманием». Нужны явные ожидания и последствия.

25. Как отличать саботаж от перегруза

Саботаж — сильное утверждение о сознательном противодействии. Для него нужен высокий уровень evidence.

Перегруз может выглядеть как

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

Несогласие может выглядеть как

повторная критика решения;
отказ изображать согласие;
эскалация риска;
просьба зафиксировать decision owner;
нежелание брать ответственность за чужое решение.

Это ещё не саботаж.

Возможные признаки сознательного препятствования

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

Даже здесь нужно расследовать факты и альтернативные объяснения.

Действие лида

Если существует реальный риск намеренного вреда:

ограничить blast radius и доступ, если это необходимо;
сохранить факты;
не устраивать публичное обвинение;
подключить уполномоченный организационный контур;
отделить protection системы от окончательного вывода о мотиве.

Containment может быть необходим до полного знания.

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

26. Сильный, но разрушительный инженер

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

Инженер:
- быстро пишет критический код;
- знает legacy;
- тушит incidents;
- принимает сильные решения.

Одновременно:
- унижает reviewers;
- блокирует передачу знаний;
- обходит process;
- делает команду зависимой;
- заставляет людей молчать;
- создаёт incidents, которые потом героически исправляет.

Реальный вклад

Net contribution =
локальный результат
− coordination cost
− created risk
− dependency cost
− suppressed capacity of others

Это не математическая KPI-формула. Это способ не считать видимый output единственной реальностью.

Не использовать ярлык «токсичный» вместо фактов

Нужно назвать поведения:

перебивает;
высмеивает;
меняет решения без фиксации;
не передаёт доступ;
блокирует review без основания;
делает production changes в обход договорённости;
переводит технический спор в оценку интеллекта.

Разговор

"Твоя техническая сила не является предметом спора.
Предмет — способ, которым она действует в команде.

За последний месяц были три случая:
[конкретные наблюдения].

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

Стандарт:
ты можешь жёстко критиковать решение через evidence и risk.
Ты не можешь оценивать интеллект автора,
перебивать и обходить обязательный review.

Мы проверяем изменение поведения на следующих трёх design reviews.
Если pattern сохраняется, ownership критического компонента изменится".

Не покупать поведение результатом

Фраза:

"Да, с ним трудно, зато он тащит"

означает, что остальные люди оплачивают его output собственной подавленной способностью.

27. Как один человек захватывает команду

Захват не всегда происходит через формальную власть.

Захват знания

Только один человек понимает компонент, deployment или клиента.

Захват решений

Без его approval команда не решается действовать, даже если формально approval не нужен.

Захват коммуникации

Он один разговаривает со стейкхолдерами и фильтрует контекст.

Захват доступа

Критические credentials, dashboards или production actions доступны фактически одному человеку.

Захват эмоционального пространства

Команда заранее моделирует его реакцию и не предлагает то, что может вызвать презрение.

Почему это проблема системы

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

не требует документацию;
поощряет героизм;
не распределяет ownership;
терпит обход правил;
не создаёт replacement path;
делает одного эксперта единственным источником истины.

Размыкание захвата

shared ownership;
rotation обязанностей;
pairing;
обязательные ADR и runbooks;
второй человек на critical operations;
открытые design reviews;
явные decision rights;
передача stakeholder context;
ограничение bypass;
проверяемый succession plan.

Цель — не уменьшить сильного человека.

Цель — перестать строить систему,
в которой сила одного требует слабости остальных.

28. Усталость, перегруз и cognitive load

Усталость не всегда видна как сообщение «я устал».

Она может проявляться как:

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

Лид не обязан определять личную медицинскую причину. Он обязан видеть рабочую систему нагрузки.

Проверка нагрузки

Сколько active work?
Сколько on-call interruptions?
Сколько незапланированной работы?
Сколько разных domains надо удерживать?
Сколько meetings разрывают focus?
Сколько ответственности существует без права решения?
Есть ли recovery после incidents?

Team Topologies использует cognitive load как одно из оснований проектирования границ команды: ясные ownership и режимы взаимодействия уменьшают объём чужой сложности, который команда вынуждена удерживать. (Team Topologies: Key Concepts)

Перегруз нельзя чинить мотивационной речью

"Надо собраться"

не уменьшает WIP, не снимает on-call и не определяет приоритет.

Но усталость не отменяет коммуникацию

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

29. Как защищать команду от внешнего давления

Защита команды — не создание информационного пузыря.

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

Внешняя форма

"Нам всё равно как, к пятнице должно быть всё.
Пусть команда поднажмёт".

Работа лида

"К пятнице нужен обязательный пользовательский сценарий A.
Текущий полный scope A+B+C не помещается.
Варианты:
1. к пятнице A с feature flag;
2. A+B к следующей среде;
3. полный scope при снятии зависимости X.

Quality gates и rollback не убираются,
потому что это превращает дату в production risk".

Что лид фильтрует

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

Что лид не должен скрывать

реальную цену задержки;
изменение стратегии;
недовольство результатом;
необходимость сократить scope;
угрозу проекту;
обязательный deadline;
обоснованный feedback команды.

Защита не означает инфантилизацию. Команда имеет право видеть реальность, если от неё требуется принимать инженерные решения.

Защита через приоритет

"Это задача номер один"

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

30. Как защищать реальность от команды

Команда может ошибаться.

Коллективное согласие не превращает модель в реальность.

Возможные ошибки команды

техническая мода принимается за необходимость;
локальная красота ставится выше delivery;
сложность недооценивается;
риск отрицается;
legacy объявляется недостойным понимания;
rewrite романтизируется;
Product concern отвергается как «не технический»;
удобство команды ставится выше пользовательского результата;
цинизм становится коллективной нормой;
сильный статус подавляет альтернативу.

Psychological safety не делает consensus истиной

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

Действие лида

1. Дать команде полностью сформулировать основание.
2. Отделить факты, assumptions и preferences.
3. Показать constraint, который команда не удерживает.
4. Запросить варианты.
5. Определить decision owner.
6. Принять решение и владеть последствием.

Прямая формулировка

"Я услышал аргумент за rewrite: текущая структура замедляет изменения.
Но у нас нет evidence, что полный rewrite окупится,
и нет migration path для работающих клиентов.

Решение: не переписываем систему целиком.
Выделяем pricing module и измеряем изменение lead time.
Я беру ответственность за это решение".

Лид не обязан изображать, что решение «создала сама команда», если он принял его против большинства.

31. Несогласие и disagree-and-commit

Несогласие не является нелояльностью.

Сильная команда должна иметь пространство, где решение можно атаковать до его принятия.

До решения

аргументы раскрываются;
assumptions проверяются;
риски фиксируются;
status не даёт привилегии;
decision owner слушает.

После решения

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

Commit не означает:
"Я теперь обязан считать решение правильным".

Commit означает:
"Я не буду скрыто разрушать принятое решение
и выполню свою часть общей работы".

Когда commit невозможен

решение нарушает обязательную policy;
человек не имеет права принять соответствующий риск;
обнаружен новый критический факт;
требуется профессиональная или security escalation;
условия решения существенно изменились.

Disagree-and-commit нельзя использовать как способ закрыть рот до рассмотрения фактов.

32. Underperformance: от тумана к явной границе

Underperformance нельзя месяцами обсуждать намёками.

Последовательность

1. Наблюдение:
какой результат или стандарт не достигнут.

2. Диагностика:
какая причина подтверждается.

3. Явное ожидание:
что должно измениться.

4. Поддержка:
какой context, обучение, доступ или изменение workload предоставлены.

5. Checkpoint:
когда и по каким evidence проверяется изменение.

6. Последствие:
что изменится, если требуемая способность или поведение не появятся.

Пример

"Роль Middle требует самостоятельно доводить bounded feature
до review и сообщать blocker в день его обнаружения.

В четырёх из пяти последних задач progress исчезал на 3–5 дней,
а blocker становился известен после моего вопроса.

Мы проверили требования, workload и доступы.
На следующие четыре недели:
- одновременно одна feature;
- risk update дважды в неделю;
- blocker сообщается в день обнаружения;
- один decomposition checkpoint в начале.

Проверяем четыре задачи.
Если pattern не меняется, мы пересматриваем соответствие текущей роли".

Документация

Фиксируются:

конкретные ожидания;
наблюдения;
предоставленная поддержка;
договорённости;
результаты checkpoints.

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

Не обещать бесконечную поддержку

Если после ясности, обучения, доступов и времени pattern устойчиво сохраняется, лид не обязан бесконечно переименовывать проблему в «ещё не нашли правильный подход».

Развитие требует действия самого человека.

33. Справедливость и различие

Справедливость не всегда означает одинаковое обращение.

Junior может получать больше review. Senior — больше свободы и больший scope ответственности. Человек после on-call incident может иметь другой workload. Это различие имеет основание.

Несправедливость возникает, когда

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

Последовательный стандарт

Одинаковым должно быть не количество помощи.

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

34. Как не измерять людей

Software development — коллективная причинная система. Индивидуальный вклад трудно отделить от контекста, архитектуры, tooling, review, domain knowledge и работы других.

Опасные индивидуальные метрики

lines of code;
commits;
pull requests;
story points;
количество review comments;
часы online;
закрытые tickets без учёта класса работы;
velocity человека.

Они легко создают производство числа вместо результата.

SPACE framework рассматривает developer productivity как многомерную систему: satisfaction and well-being, performance, activity, communication and collaboration, efficiency and flow. Авторы отдельно подчёркивают, что productivity нельзя свести к одной метрике. (The SPACE of Developer Productivity)

Что использовать для развития

capability map;
наблюдаемые решения;
качество завершённых outcomes;
работа с неизвестностью;
повторяемость способности;
влияние на других;
operational ownership;
способность исправлять собственную модель;
feedback от взаимодействующих ролей с конкретными примерами.

Activity может быть сигналом, но не приговором

Резкое изменение review activity может показать, что стоит задать вопрос. Оно не доказывает лень, выгорание или падение ценности человека.

Метрика может открыть расследование.
Она не должна автоматически завершать его.

35. Полный пример: сильный Senior захватил billing

Исходное состояние

Сергей пять лет работает с billing platform.

Он:

быстрее всех находит production defects;
знает исключения клиентов;
принимает архитектурные решения;
отвечает на вопросы руководства;
проводит большую часть critical reviews.

Команда считает его незаменимым.

Одновременно:

pull requests ждут его по три дня;
он публично высмеивает слабые решения;
два инженера не берут billing tasks без его разрешения;
ADR не ведутся;
runbooks находятся в его личных заметках;
в отпуске он продолжает отвечать на incidents;
Product обсуждает scope только с ним.

Ошибочная модель лида

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

Эта модель сохраняет захват и назначает адаптацию всем остальным.

Разбор причинности

Локальная сила:
глубокое domain knowledge и высокая скорость диагностики.

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

Системные условия:
- единоличный approval;
- закрытый stakeholder context;
- нет rotation;
- героизм вознаграждается;
- documentation не входит в Done.

Риск:
bus factor = 1,
suppressed growth команды,
review bottleneck,
непроверяемые решения.

Разговор с Сергеем

"Я не собираюсь обесценивать твоё знание billing.
Именно потому, что оно критично, оно не может оставаться
только твоей личной способностью.

Отдельная проблема — способ review.
Вот четыре конкретных случая и их воздействие.
Техническое несогласие разрешено и необходимо.
Унижение автора и единоличный bypass — нет.

На следующие шесть недель:
- у каждого critical review есть второй reviewer;
- два компонента получают co-owner;
- решения фиксируются ADR;
- runbooks переносятся в общий контур;
- Product sync проходит с участием ещё одного инженера;
- на design review действует конкретный communication standard.

Если destructive pattern сохранится,
мы изменим твою роль и decision rights,
несмотря на техническую производительность".

Работа с командой

Нельзя просто сказать остальным «теперь будьте смелее».

Нужно изменить систему:

назначить co-ownership;
дать реальный доступ;
защищать alternative proposals на review;
не возвращать последнее слово Сергею неформально;
дать другим вести incidents под контролируемым риском;
признавать передачу знания как результат.

Контрольные evidence

review time уменьшается;
решения могут быть приняты без Сергея в определённых границах;
два инженера самостоятельно проводят billing changes;
runbook проходит game day;
на design reviews отсутствуют повторные нарушения;
production outcomes не ухудшились.

Цель не наказать сильного. Цель — перестать покупать его силу ценой несамостоятельности всей системы.

36. Полный пример: «ленивый» Middle

Исходное наблюдение

Марина трижды переносит задачу экспорта отчётов. На daily говорит, что «разбирается». Лид начинает считать, что она не проявляет ownership.

Восстановление timeline

Выясняется:

Product добавил два формата после начала работы;
security требует отдельную проверку персональных данных;
дизайнер передал макет только для одного отчёта;
Марина одновременно исправляет production bug;
она не знает, имеет ли право сократить scope;
предыдущая попытка эскалации закончилась фразой «не приноси проблемы без решения».

Реальная причинность

Проблема состоит из нескольких частей:

scope не зафиксирован;
приоритеты конфликтуют;
decision right неизвестен;
поведение Марины тоже недостаточно: она скрывает blocker за словом «разбираюсь».

Действие

Лид:

фиксирует обязательный PDF для одного отчёта;
снимает production bug с Марины;
определяет security owner;
даёт Марине право вынести остальные форматы в следующий slice;
устанавливает стандарт risk update.

Feedback:

"Система действительно поставила тебе противоречивые условия,
и я их сейчас меняю.

Твоя часть ответственности:
ты пять дней знала, что scope и security не определены,
но сообщала только 'разбираюсь'.

В следующий раз update должен звучать:
'Implementation остановлена. Нужны решения X и Y.
До их получения могу поставить только slice A'."

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

37. Язык лида

Когда причина неизвестна

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

Когда человек не умеет

"Сейчас проблема не в усилии.
Тебе не хватает модели разбиения асинхронного сценария.
Разберём один пример вместе, затем ты построишь второй самостоятельно".

Когда человек перегружен

"У тебя одновременно две features, on-call и mentoring junior.
Это не capacity plan. Снимаем feature B и возвращаемся к ней
после завершения A".

Когда человек не согласен

"Я не требую изображать согласие.
Мне нужны твои constraints и evidence до решения.
После решения — выполнение общего плана либо явная эскалация
по обязательной границе, но не скрытое сопротивление".

Когда поведение разрушительно

"Твоя оценка решения может быть жёсткой.
Оценка интеллекта человека и публичное унижение не входят
в допустимый способ инженерного спора".

Когда команда ошибается

"Большинство за rewrite. Это важный сигнал,
но не достаточное основание.
Нет migration path и расчёта стоимости.
Решение сейчас — incremental extraction.
Я беру ответственность за него".

Когда support не помог

"Мы уточнили scope, сократили WIP, провели pairing
и зафиксировали checkpoints. Требуемое изменение поведения
не произошло. Теперь это вопрос соответствия текущей роли,
а не поиска ещё одного объяснения".

38. Практика модуля

Упражнение 1. Наблюдение или интерпретация

Разделить утверждения:

1. "Он не заинтересован".
2. "За три встречи он не задал ни одного вопроса".
3. "Она боится ответственности".
4. "Она дважды попросила письменное подтверждение решения".
5. "Он саботирует release".
6. "После решения он отменил approved change без сообщения".

Затем для каждой интерпретации построить несколько альтернативных гипотез.

Упражнение 2. Capability map

Для реального инженера описать evidence по измерениям:

execution;
framing;
decomposition;
uncertainty;
delivery;
communication;
operations;
influence.

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

Упражнение 3. Менторинг по уровням

Одна задача: интеграция с внешним API.

Нужно подготовить три формы передачи:

Junior;
Middle;
Senior.

Для каждой определить:

scope;
autonomy;
support;
checkpoint;
evidence роста.

Упражнение 4. Feedback

Переписать:

"Ты токсично ведёшь себя на review
и вообще не умеешь работать в команде".

в структуру:

situation;
behavior;
impact;
standard;
inquiry;
next agreement.

Упражнение 5. Conflict map

Дано:

QA блокирует release.
Product требует выпустить.
Backend говорит, что риск минимален.
Security не дал окончательного решения.

Нужно отделить:

task conflict;
role conflict;
risk ownership;
факты;
неизвестное;
decision owner;
возможные новые формы решения.

Упражнение 6. Сильный разрушительный инженер

Участник должен:

выписать конкретные behaviors;
оценить system cost;
подготовить прямой разговор;
изменить ownership system;
определить evidence изменения;
назвать последствия повторения.

Упражнение 7. Защитить реальность от команды

Команда единогласно требует переписать monolith.

Участник должен:

полностью представить аргумент команды;
найти assumptions;
запросить evidence;
выделить реальные ограничения monolith;
предложить проверяемый промежуточный шаг;
принять решение без фиктивного consensus.

39. Итоговый артефакт: Lead People Operating System

39.1. Capability Map

# Capability Map: [роль / человек]

| Capability | Current evidence | Current boundary | Target behavior | Practice |
| --- | --- | --- | --- | --- |
| | | | | |

## Support

- ...

## Checkpoints

- ...

39.2. Growth Plan

# Growth Plan

## Capability

## Why it matters

## Current evidence

## Target behavior

## Developmental task

## Delegation level

## Support

## Evidence of change

## Checkpoint

39.3. Feedback Card

# Feedback

## Situation

## Observed behavior

## Impact

## Expected standard

## Person's context / intent

## Agreement

## Checkpoint

39.4. Conflict Map

# Conflict Map

## Object

## Type

## Observed facts

## Side A

- Position:
- Constraints:
- Interests:

## Side B

- Position:
- Constraints:
- Interests:

## Unknowns

## Decision owner

## Resolution criterion

## Decision

## Follow-up

39.5. Behavior Intervention Plan

# Behavior Intervention

## Repeated behavior

## Evidence

## System impact

## Expected standard

## Support / structural changes

## Observation window

## Success evidence

## Consequence if unchanged

39.6. Team Capture Map

# Team Capture Map

| Area | Current single point | Risk | Transfer action | New owner | Validation |
| --- | --- | --- | --- | --- | --- |
| Knowledge | | | | | |
| Decisions | | | | | |
| Access | | | | | |
| Stakeholder context | | | | | |
| Operations | | | | | |

40. Чек-лист лида

[ ] Я отделил наблюдение от интерпретации мотива.
[ ] Я проверил человека, задачу, роль, команду и систему.
[ ] Я не использую seniority как описание всей личности.
[ ] Capability сформулирована через наблюдаемое действие.
[ ] Режим teaching / mentoring / coaching выбран по реальной причине.
[ ] Delegation boundary понятна обеим сторонам.
[ ] Growth plan содержит practice и evidence, а не только обучение.
[ ] Feedback дан вовремя и на конкретном материале.
[ ] Я назвал impact и expected standard.
[ ] Intent рассмотрен, но не использован для отмены impact.
[ ] Code review критикует решение, а не интеллект автора.
[ ] Psychological safety не подменяет accountability.
[ ] Я определил тип конфликта и его объект.
[ ] Проверен role conflict и decision ownership.
[ ] Я не назвал перегруз ленью без проверки.
[ ] Я не назвал несогласие саботажем.
[ ] Разрушительное поведение сильного инженера не куплено его output.
[ ] Critical knowledge и access не принадлежат одному человеку.
[ ] Внешнее давление преобразовано в constraints и варианты.
[ ] Команда видит реальность, а не защищена от смысла.
[ ] Consensus не используется как доказательство правильности.
[ ] Underperformance имеет явное ожидание, поддержку и checkpoint.
[ ] Метрика открывает вопрос, а не выносит приговор человеку.

41. Главные антипаттерны

Будь эмпатичнее

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

Я знаю, что он чувствует

Реконструкция внутреннего состояния выдаётся за наблюдение.

Он Senior, пусть разбирается

Титул скрывает контекстную границу способности.

Я сам быстрее сделаю

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

Стань проактивнее

Человеку предъявляется категория без ожидаемого поведения и decision rights.

Feedback раз в полгода

Человек узнаёт о накопленном недовольстве, когда изменить прошлое уже нельзя.

Review как экзамен

Pull request превращается в публичную проверку человеческой ценности.

Psychological safety как отсутствие границ

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

Конфликт надо сгладить

Несовместимые constraints остаются, меняется только тон речи.

Он ленивый

Категория закрывает исследование знания, роли, capacity и выбора.

Он саботирует

Сильный вывод о намерении строится на задержке или несогласии.

Он токсичный, но незаменимый

Система продолжает субсидировать output одного человека способностью остальных.

Команда решила

Consensus заменяет evidence и decision ownership.

Мы его поддерживаем бесконечно

Отсутствие изменения никогда не приводит к пересмотру роли или последствиям.

Коммиты показывают вклад

Видимая activity принимается за всю систему ценности.

42. Основные формулы модуля

человек ≠ роль
seniority ≠ единый уровень всех способностей
наблюдение ≠ интерпретация
impact ≠ intent
понимание ≠ оправдание

feedback ≠ оценка личности
менторинг ≠ выполнение работы за человека
coaching ≠ отказ передать отсутствующее знание
delegation ≠ сброс задачи без границ

psychological safety ≠ отсутствие стандартов
конфликт ≠ личная вражда
несогласие ≠ саботаж
перегруз ≠ лень
объяснение системы ≠ отмена личной ответственности

сильный индивидуальный output ≠ положительный системный вклад
consensus ≠ истина
защита команды ≠ сокрытие реальности
жёсткая граница ≠ унижение

Главная формула:

Лид не управляет "человеческими ресурсами".

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

43. Финальное различение

Слабая работа с людьми движется между двумя примитивными режимами.

Первый:

"Людей надо сильнее контролировать.
Не сделал — ленивый.
Спорит — нелояльный.
Ошибся — слабый".

Второй:

"Надо быть добрее.
У каждого свои обстоятельства.
Нельзя давить.
Главное — чтобы всем было комфортно".

Оба режима отказываются от различения.

Первый превращает любую проблему в дефект человека.

Второй растворяет действие, стандарт и ответственность в общем сочувствии.

Lead-level работа выглядит иначе:

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

Лид не нормирует человека под усреднённую форму «хорошего сотрудника». Он видит конкретного человека в конкретной системе и добивается точного изменения там, где находится реальная причина.

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