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

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод статьи Гранта Слаттона, инженера и основателя компании Row Zero, в прошлом старшего инженера в AWS S3.

Почему тема статьи именно такая

Меня всегда интересовало, как формируется, эволюционирует и сохраняется бюрократия.

Если бы я когда-нибудь решил заняться социологией (да ещё и сошёл с ума), то выбрал бы одну единственную тему — бюрократию. Я бы даже попытался основать отдельную дисциплину — науку о бюрократии, «бюрологию». Мне кажется, это вполне достойная и реальная область исследований — наравне с антропологией или психологией.

И вот какие вопросы я бы поставил в центр исследования:

• Почему бюрократия неизбежно возникает в любой организации, если дать ей достаточно времени?

• Какие общие элементы есть у всех бюрократий, и почему они так похожи?

• Почему бюрократия всегда приводит к упадку, а потом и к краху?

• Что можно сделать, чтобы замедлить этот процесс?

• И главное: можно ли повернуть его вспять?

В этой статье попробую хотя бы частично найти ответы на эти вопросы.

Как формируется бюрократия

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

Причина 1. Число Данбара

Число Данбара — это гипотетический предел того, сколько социальных связей может удерживать человек в голове одновременно. Обычно называют цифру около 150. Звучит как поп-психология, но на практике довольно близко к реальности.

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

А теперь пример, как это ломается.

Элис давно работает в компании, которая выросла до 300 человек. Боб — новичок, сидит вообще на другом конце этой структуры.

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

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

И всё. Вуаля — бюрократия создана. Причём с самыми благими намерениями.

Причина 2. Асимметрия вверх-вниз

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

Представьте ситуацию: у вас есть шанс с вероятностью 60% заработать $100, но с вероятностью 40% потерять $50. Если считать «в лоб», ожидаемый результат = +$40. Вроде бы рационально сыграть.

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

И вот тут начинается интересное. Потерять $1 по статусу может навредить ровно так же, как заработать $4 этот статус улучшает. В пересчёте — шанс на успех даёт +$40, но «с поправкой на статус» — уже минус $20. В такой системе лучше ничего не делать, чем рисковать.

Я много раз видел это своими глазами. И на практике всё даже хуже.

• Один проект провалился и потерял $1 млн.

• Другой оказался суперуcпешным и заработал $100 млн.

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

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

Причина 3. Импульс инклюзивности

Часто, чтобы принять решение, достаточно согласовать его с 1–3 ключевыми людьми. Этого вполне хватит, чтобы всё заработало.

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

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

Причина 4. Нерешительность в возложении ответственности

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

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

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

Причина 5. Командно-ориентированное владение

Эта история идёт рука об руку с нежеланием искать виноватых.

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

Цена такого подхода? Больше координации, больше коммуникационных издержек, больше согласований. А значит — ещё один кирпичик в фундамент бюрократии.

Причина 6. Повышение разборчивости

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

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

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

Что происходит дальше? Чтобы убрать «дисбаланс», вводят формальные критерии:
— чтобы перейти в SDE2, нужно поставить 10 галочек;
— внести 5 крупных изменений в продакшен;
— стать наставником стажёра;
— утвердить 3 проектных документа…

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

Причина 7. Эффекты выбора

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

И вот тут запускается интересный цикл:

• приходят люди, которым комфортно в бюрократии;

• эти люди поддерживают и укрепляют бюрократию;

• система становится ещё более забюрократизированной, чтобы соответствовать их взглядам и стилю работы.

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

Есть отличное эссе на эту тему — «Stimulii as Selection Effects» Себастьяна Бенсусана. Главная мысль простая и точная:

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

Примеры:

• создаёшь чеклисты для повышения → привлекаешь людей, которым нравится следовать чеклистам;

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

• выстраиваешь бюрократию → привлекаешь бюрофилов, которым комфортно в сложных процессах.

А дальше — всё по кругу.

Методы замедления бюрократического упадка

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

Метод 1. Минимизировать численность персонала

Если превышение числа Данбара запускает бюрократию, то держим размер команды как можно меньше. Примеры известны: у WhatsApp было 55 сотрудников при сотнях миллионов пользователей. У Instagram — 13 сотрудников в момент покупки Facebook. У Craigslist — 50 человек.

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

Пример: AWS S3. Фактически — отдельная компания внутри Amazon. Все общаются с ней через API, даже внутренние команды Amazon. Взаимодействие ровно такое же, как у внешних клиентов. Это позволяет держать фокус, границы ответственности и скорость, не превращая всё в монолитную бюрократическую махину.

Метод 2. Агрессивное сокращение

Писать об этом немного неловко, но факт остаётся фактом: это работает (по крайней мере, у Илона Маска).

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

Первое — контроль численности. Если у вас миллиард пользователей, это не значит, что вам нужно 10 000 сотрудников. Может хватить и 100.

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

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

Да, это самая болезненная стратегия (для большинства людей не-социопатов), но эмпирически — единственная, которая реально тормозит бюрократический склероз в долгосрочной перспективе.

Метод 3. Назначение ответственного лица

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

Что значит «владеет»? Что человек может объяснить:
— что именно делает его штука;
— почему её нельзя (или можно) упростить или удалить;
— если можно упростить/удалить — какой план действий;
— как она связана с другими частями системы;
— кто владеет этими другими частями;
— над чем они вместе думают;
— что его больше всего беспокоит — «что тут может пойти не так».

Зачем это всё? Антибюрократических плюсов много:

• Если владелец делает свою работу плохо, его легко заменить. При командном владении — сложнее, никто не хочет брать ответственность.

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

• Если нужно что-то изменить, достаточно договориться один на один с владельцем смежной части — вместо переговоров между целыми командами.

• Если вещь надо убрать или заменить, проще перевести владельца на другую задачу, чем разбирать, кто за что отвечает в команде (особенно если команда начнёт «отстаивать территорию» — а это почти неизбежно).

Метод 4. Интуитивные повышения

Есть два способа, как выстроить процесс повышения:

1. Интуитивно, «по вибрациям» — всё решается цепочкой руководителей, иногда капризно, иногда по делу.

2. Формально, через чеклисты — есть чёткие пункты, галочки, критерии, чтобы перейти на следующий уровень.

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

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

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

Пример (гипотетический, но узнаваемый): старшие инженеры пишут много кода → добавляем в чеклист пункт: «чтобы стать старшим, нужно написать 100 000 строк кода».
И всё. Начинается раздувание кода ради галочки, а не ради пользы.

Единственный реально работающий критерий —«создаёт ценность для бизнеса». Но как её измерить? Сколько стоит в долларах хорошая документация? А дополнительные тесты? Ответ — «это вопрос суждения».

И тут главная проблема: любой чеклист можно обойти, натянуть, выполнить «для галочки». А ещё — вы начинаете привлекать людей, которые любят и умеют работать по чеклистам.

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

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

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

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

В дополнение: заметка об Илоне Маске

Рискую показаться фанатом Илона, но скажу прямо: лучше него никто не борется с бюрократией. Tesla и SpaceX — редкие примеры крупных компаний (10 000+ сотрудников), которые по-прежнему развиваются с бешеной скоростью. Как им это удаётся?

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

«Тема: Коммуникации внутри Tesla

Есть два подхода к тому, как должна передаваться информация в компании.

Первый (самый распространённый) — через цепочку команд: всё идёт через менеджера → его менеджера → менеджера другого отдела → сотрудника в другой команде.

Проблема в том, что этот процесс усиливает власть менеджеров, но не служит интересам компании.

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

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

Хотите поговорить с менеджером менеджера? Не нужно разрешение. Нужно обсудить что-то с вице-президентом другого отдела? Пожалуйста. Со мной? Без проблем.

Более того, вы обязаны так делать — пока задача не решена.

Это не про «болтовню ради болтовни». Это про то, чтобы делать работу быстро и качественно.

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

И наконец: менеджеры должны бороться с внутренними барьерами и менталитетом «мы против них». Все работают не на отдел, а на компанию. Мы в одной лодке.»

Что здесь особенно важно:

• в письме несколько раз подчёркивается: главная цель — ценность для бизнеса, а не формальные цепочки;

• напрямую говорится о санкциях для менеджеров, которые тормозят коммуникацию;

• чётко признаётся, что тенденция к бюрократии — естественна, и с ней нужно сознательно бороться.

Этот пример показывает: борьба с бюрократией — это не «ничего не делать», а, наоборот, активное действие и защита скорости через организационные принципы.

Заключение

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

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

По сути, вам нужно стать учеником бюрократических тёмных искусств. Чтобы знать, как она появляется, понимать, как размножается и вовремя сказать ей: «стоп».

Придётся учиться бюрократии, чтобы победить бюрократию.

Больше интересного контента об управлении командами и процессами — в моём телеграм-канале Teamlead Good Reads. Подписывайтесь!