Как я построил в офисе свою собственную холакратию

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

Шло время. Количество проектов росло, количество сотрудников – тоже. А мое свободное время критически близилось к нулю. И мне пришлось часть задач передать другим людям. Это было тяжело. Крайне тяжело. Ведь никто другой не сможет вести проекты также, как я...

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

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

Потом начало появляться больше параллелей в компании, и я перестал отвечать за всё и вся. Но решил прописывать какие-то базовые задачи и зоны ответственности по всем сотрудникам. Например, кто высылает акт, кто деплоит проект и т.д. Так появился перечень обязанностей.

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

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

Изначально делали 2 раза в неделю синк, но я все равно продолжал держать руку на пульсе. Рано или поздно стали возникать споры: “Чьи проекты важнее?”, “Почему сотрудник уходит в отпуск без ведома второго менеджера?”, “Как спланировать загрузку?”.

Сделали ресурс-планинг: ось икс – сотрудники, ось игрек – даты. По этому графику планировали, кто из менеджеров в какой день какого сотрудника берет. Схема работала худо-бедно. Но все равно не устраивала.

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

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

Получается, директор контролирует менеджеров и составляет критерии, по которым они работают. А техлид контролит тимлидов и то, как они у себя в команде принимают решения.

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

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

Теперь раз в месяц проходит встреча с менеджерами, на которой мы обсуждаем финансовые планы, ставим новые цели. Дальше они самостоятельно контролируют и загрузку, и оплаты внутри своих команд. Мне, как руководителю, остается только мониторить. У нас, кстати, для этого есть собственный софт. Там каждый менеджер видит свои платежи, контролит выплаты и понимает конверсию. А я вижу рентабельность проектов и выполнение kpi.

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

Вторая сложность, к которой надо быть готовому – вопросы, которые посыплются от менеджеров. Почему ему достался проект лучше? А можно мне другой проект? Пока у нас 2 менеджера, а продажами я занимаюсь самостоятельно, я интуитивно распределяю задачи, зная сильные и слабые стороны каждого. В других компания, где менеджеров гораздо больше, есть свои внутренние тендеры на проекты.

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

Так или иначе, очень важно доверять своим менеджерам. Фактически, вы перекладываете на их плечи финансовое благополучие компании и моральное состояние коллектива. Но в делегировании всегда приходится идти на риск и доверять человеку. Или продолжать тащить все самому. Но это совсем не моя история.