Pull to refresh

Закон самоцентрализации команд: почему самоуправляемый коллектив распадается, если не централизуется

Reading time 9 min
Views 12K
Новый год на Хабре начался с совершенно феерической расстановки точек над боссами-кровососами, железно постановившей: руководители как явление — абсолютно бесполезны.

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



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

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

— А король-то голый, как говорилось в сказке.

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

О важности самоорганизации.
Есть простое правило, rule of thumb, которое я позаимствовал у эволюционных биологов: если генетически обусловленная характеристика продолжает воспроизводиться — у неё должна быть эволюционная значимость, даже если она неочевидна — наоборот, это только повод присмотреться. Конечно, это правило, а не закон: атавизмы, рудименты и экзаптацию (перепрофилирование органа) никто не отменял. Для каждого конкретного случая нужно отдельно включать голову и использовать её по назначению.

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

Обратная сторона монеты


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

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

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

Но это не отменяет того, что этот специфический bias — взгляд из-под капота:

  • встречается — разумеется, не у каждого, но у достаточно большого количества разработчиков, чтобы я мог утверждать, что мне не показалось;
  • причём, у кого её нет — у того её нет, а вот кто видит мир так — то, обычно, это очень хардкорная и ригидная позиция;
  • свойственен, в основном или исключительно, «айтишникам» в строгом понимании — не дизайнерам даже, не верстальщикам, обычно — а админам и девелоперам (впрочем, здесь уже может быть мой bias — я перечисляю, что сам встречал);
  • а пост «Кровососы» — хорошая зарисовка того, каким с этого ракурса видится мир.
.
А невысокий средний уровень российского менеджмента просто не делает ситуацию лучше — скажем, многие горе-начальники принимают мировоззрение таких сотрудников за вызов, брошенный в power games, и могут рассматривать это как проблему субординации (что только усугубляет неприятие «из-под капота»).

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

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

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

Но как с субъектом на самом деле коммуницировать физически? Нужен конкретный human being, который будет аватаром этой команды, её представителем. Необязательно руководитель — с доставкой воды может взаимодействовать офис-менеджер, например. Но в большинстве сценариев это должно быть постоянное лицо — особенно когда речь идёт о праве принятия решения. Команда, как субъект, постоянно должна принимать решения — и если у неё не будет руководителя (то есть, человека, наделённого правом и ответственностью принимать решения) — значит, решения принимает команда, а ответственность за каждое конкретное из них распределяется по отдельным членам. С первой же задачей, не относящейся непосредственно к разработке и продукту, вспомнится и бесполезный руководитель.

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

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

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

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

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

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

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

Но… как же модели?


— руководитель – это неопределенный компот из неясных обязанностей, который нужно просто разложить по полочкам ролей

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

Но что насчёт идеи разделить их по ролям? Я даже выписал: координатор, мотиватор, финишер, генератор (идей), аналитик.

Во-первых, это не полный список ролей. Но важнее даже не отсутствующие роли, а что имеющиеся предполагают.

— Все эти роли – не руководство. Это просто роли, работа такая.

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

  1. Координатор не сможет координировать, если у него будет только рекомендательная функция. Допустим, разработчики не сомневаются в личной ответственности — во-первых, это повод начать сомневаться, потому что людей без слабостей не бывает, во-вторых, в команде есть и другие люди, и какой-нибудь дизайнер-раздолбай может стать серьёзным камнем преткновения процессов. А значит, координатору, чтобы выполнять функции координатора, понадобятся полномочия, включая право приказывать и право наказывать. И вуаля — он уже немножко руководитель.
  2. То же самое и с мотиватором — что вообще такое мотиватор без полномочий, как он будет мотивировать — демотиваторы, что ли, рассылать по внутренней почте? Ему понадобятся финансовые полномочия. Итого у нас уже два человека с доступом к кассе: один может штрафовать, другой — поощрять.
  3. Нет, три — сразу считаем финишера, потому что как человек будет доводить проект до релиза, если у него никаких рычагов воздействия? Его указания будет так же ценны, как реплаи в твиттере.
  4. А ещё есть генератор и аналитик — роли, вроде бы, безобидные, пока не задаёшься вопросом: как именно вы их выделите в команде? А если вам не нравятся их идеи генератора? А если вам нравятся, а другим не нравятся? А если генератора два — с противоречивыми идеями? Будете голосовать? А кто разобьёт ничью?
    Либо команда будет существовать до первого серьёзного разногласия;
    либо надеяться на свою способность всегда находить общий язык (иными словами — существовать до первого серьёзного разногласия);
    либо кто-то должен принять решение в пользу одной стороны, принудив к его соблюдению вторую.
    Кто же это будет? Звучит ужасно похоже на руководителя.
  5. А аналитик бесполезен без трактовки его данных и принятого решения по результатам трактовки — кто это будет делать? И снова звучит ужасно похоже на руководителя.
  6. Это ведь ещё не все роли. Кто-то должен будет решать конфликты — внутренние и с внешним миром. Эта позиция тоже предполагает полномочия.
  7. И это мы ещё не дошли до финансово ответственного лица. Если план был — за уплату налогов отвечает бухгалтер — то кто будет отвечать за наполнение кассы? Продажники? Удачи в поисках продажников, которые разделят материальную ответственность за уплату налогов. А если R&D решит во имя лучшего качества продукта перенести релиз на квартал-другой, образуется кассовый разрыв — R&D будет отвечать перед налоговой? Или, скажем, кредиторами. Или даже арендодателем? Или за всё отвечает бухгалтер, не имеющий права на это никак повлиять? Или дать ему полномочия, объединив в одних руках и контроль за палкой, и контроль за финансами? Звучит очень ужасно похоже на руководителя.

Поднимите руки те, кто считает, что в таких условиях возможно было бы создать iPhone. Сможет внедрённая ERP заменить Джобса?

Нет, конечно, Джобсы не все. Но кто будет решать, кто Джобс, а кто не Джобс? Команда? Голосованием? Интересно, если бы у команды Apple была возможность голосованием решить судьбу Джобса… oh wait. Они ведь и решили однажды.

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

А если авария? А если по вине водителя? А если водитель украл у пассажира телефон? А если компанию засудили — и надо либо сокращать зарплаты, либо сотрудников?

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

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

Даже если это будут лучшие менеджеры на свете — будут, потому что 8 «частичных руководителей», эдаких хоркруксов ненавистного руководителя — это восемь полновесных точек зрения, и если хотя бы 2-3 из них столкнутся на конкретном участке работы конкретного разработчика — кто-то точно останется недоволен. И воспользуется палкой.

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

Иными словами, начальник вернётся. Не по чьей-то злой воле, а по объективным причинам.

Получается теорема:

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

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

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

Готовы на это? Если это так, то вы готовы стать руководителем. Нет? Значит, руководителем будет кто-то другой.

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

То есть, волшебный способ избавления от бесполезных руководителей уже существует — и доступен всем и сейчас.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+31
Comments 36
Comments Comments 36

Articles