Одна голова хорошо, а две — иногда хуже

Из серии «Скрытые издержки роста»

Как вы думаете, когда в компании появляется первый настоящий налог роста? Ответ вас удивит. Это происходит не тогда, когда появляется десятая команда. И не тогда, когда приходит бюрократия. И уж точно не тогда, когда C‑level внезапно обнаруживает календарь, забитый встречами. Это происходит значительно раньше — в тот момент, когда у одной задачи появляется два мозга. Говоря простым языком без метафор:

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

Любой грамотный менеджер знает, что в командной работе 1+1 равно не 2, а скорее 1.8 или 1.7. Однако, если управленцам заявить, что неправильно подобранный напарник может не просто «не помочь» — а ослабить ценного специалиста (т.е. 1+1 может скатиться к 0.5, или 0.1, или вообще 0), то многие из них просто покрутят пальцем у виска.

Но такое случается, и, как ни странно, мы все часто с этим сталкиваемся. Просто не обращаем на это внимание.

Причина расхождения проста. Пока задача живёт в одной голове, решение ограничено компетенцией и временем одного человека. Как только голов становится две, узким местом становится уже не мышление, а согласование мышления. Именно из этого и взялось название — «налог на синхронизацию».

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

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

Проблема в том, что люди не складываются как процессорные ядра. И даже процессорные ядра далеко не всегда складываются: для многих задач добавление третьего‑четвёртого ядра почти не даёт прироста. Что уж говорить про людей, у которых помимо вычислений есть ещё эмоции, амбиции и разный контекст. Ещё в 70‑х Фредерик Брукс в «The Mythical Man‑Month» заметил, что добавление людей в проект почти всегда увеличивает коммуникационные издержки быстрее, чем полезную мощность команды.

Поэтому в реальности второй человек часто не ускоряет решение напрямую, а сначала создаёт новую работу: договориться, что именно они вообще решают. И это та часть работы, которую почти никто не планирует. В оценке задачи нет отдельной строки «8 часов на реализацию и ещё день на выравнивание двух моделей происходящего». Но именно туда очень часто и утекает время.

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

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

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

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

Следующие три дня Лев и Ника честно искали техническую проблему. Они перепроверяли настройки, пересобирали раза три или четыре цепочку, гоняли тесты в разных режимах и даже пробовали запускать их по ночам, смотрели, не ломается ли что-то в самом модуле. Всё выглядело так, будто система ведёт себя нелогично: руками действия проходят, а те же задачи, но запущенные гнездом — нет.

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

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

1+1 в этом примере дало примерно 0.3. Не потому, что Лев или Ника слабые специалисты, а потому, что их модели задачи не совпали — и никто не сделал это явным.

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

Обсуждение — это не передача информации. Это попытка натянуть одну картину реальности на другую. И здесь есть тонкость, которую легко пропустить: говорящий не осознаёт свою модель как «модель». Он искренне думает, что транслирует факты. Собеседник делает то же самое. В итоге два человека спорят не о задаче — они спорят о том, чья картина реальности правильнее. Но поскольку ни один не видит своей модели как субъективной, спор выглядит не как «у нас разные картины», а как «ты не понимаешь очевидного».

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

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

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

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

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

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

А мы продолжаем.

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

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

Бывает это ощущение даже честное. Если один участник понимает задачу на 90%, а второй на 30%, обсуждаться будет чуть больше 30%, потому что для обсуждения нужно понимание всеми участниками. Сильные люди начинают упрощать мысль, срезать нюансы — сложные, но точные решения просто не проходят через такую синхронизацию. Система начинает оптимизироваться под обсуждаемость, а не под точность. И в итоге в обсуждении побеждает не лучшее решение, а самое понятное. А понятное ≠ правильное.

Одной из причин превращения 1+1 в 0.5 является то, что основная работа происходит уже не в решении задачи, а в попытке совместить два разных понимания этой задачи. А если моделей много, доверия мало и контекст разъехался, сумма может стать и нулевой: люди заняты отстаиванием своих точек зрения, но не движением вперёд. Получается классическое «а воз и ныне там» из басни Крылова.

Дальше механизм только масштабируется. Два человека на одной задаче создают одну связь. Пять человек в обсуждении создают уже целую сетку ожиданий, интерпретаций и микродинамик. Каждая пара в коллективе вырабатывает свою модель. Некоторые тройки делают то же самое. И сложность сведения этой картины в единую систему растёт очень быстро. В какой-то момент синхронизация перестаёт быть эпизодом — она становится основной работой.

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

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

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

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

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

Это не метафора и не мотивационный плакат. Именно здесь и вырастает то, о чём говорит Патрик Ленсиони в «Пяти пороках команды». Два из пяти бьют по синхронизации особенно прямо: отсутствие доверия и страх конфликта. Без доверия люди тратят время на защиту своих моделей вместо того, чтобы их выравнивать. Без готовности конфликтовать по сути неудобные вопросы не задаются — и противоречия, как у Льва и Ники, всплывают через три дня, а не в первые пятнадцать минут.

Если всё это выстроено — налог на синхронизацию падает. А иногда, как побочный эффект, появляется то, что принято называть синергией. Люди перестают компенсировать расхождение моделей и начинают умножать сильные стороны друг друга. Результат оказывается в разы больше, чем дали бы те же два человека, работающие независимо — и 1+1 становится не просто 2, а 3 или даже 5.

Звучит идеально? Компания из 10 человек может работать за 30 или 40. Вот только создать это реально на команде из 6–8 человек. Дальше — это уже мастерство руководителя, сравнимое с искусством ниндзя или чёрной магией.

Проблема в масштабе. Когда у вас десять тысяч сотрудников, мотивировать каждого на такое — почти нереально. Люди экономят энергию, полагаются на «и так понятно». И налог возвращается. Более того: большинство людей находится на пике самоуверенности именно в вопросе коммуникации — они искренне считают, что умеют общаться, и поэтому даже не начинают в это инвестировать. Это классический эффект Даннинга‑Крюгера, только применительно не к профессии, а к навыку взаимодействия. Налог платят все. Независимо от самооценки.

Компании давно пытаются с этим справляться интуитивно — конвейерное производство (спасибо Генри Форду), матричные структуры, Agile с небольшими командами. Логика везде одна: разрезать часть связей. Не надо синхронизировать 100 человек — надо синхронизировать 10 групп по 10. Но тут всё начинает зависеть от лидеров этих групп: они могут как усилить систему, так и превратиться в новое узкое место и новый налог.

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

Во‑первых, не стоит увеличивать число участников там, где это не обязательно. Каждое добавление человека — это не просто плюс одна пара рук, а ещё одна модель мира, которую придётся выравнивать. Если задачу можно отдать одному сильному владельцу, это нередко быстрее и качественнее, чем собирать мини‑комитет.

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

В‑третьих, полезно отдельно ценить людей, которые умеют быть третьим мозгом. Не просто экспертов, а интерпретаторов между мирами: тех, кто умеет увидеть обе модели сразу и назвать конфликт простыми словами. В кейсе с Nestworks именно Марк, а не Лев и Ника, разблокировал три дня работы — и в растущих компаниях это одна из самых недооценённых управленческих компетенций.

Если вы дочитали до этого момента и не уснули, то вот вам краткое содержание этой серии:

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

Если посмотреть под этим углом, почти весь управленческий инструментарий про одно и то же. Стендапы, OKR, RFC, архитектурные ревью, роадмапы, RACI‑матрицы — на первый взгляд разные инструменты для разных проблем, но по сути каждый отвечает на один вопрос: как перенести модель из одной головы в другую с минимальными потерями. От древних военных структур до современных agile‑подходов — всё это решения одной и той же проблемы. Словарь меняется. Задача остаётся.

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

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

Простая диагностика

Возьмите свою ключевую команду. И спросите честно: чему у вас равно 1+1?

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