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

Актуально для команды до 40 человек

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

Привет, это я – Макс Бонцевич Директор студии разработки Веб Секрет

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

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

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

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

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

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

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

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

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

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

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

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

Стало

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

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

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

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

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

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

0
8 комментариев
Написать комментарий...
chelique

Холакратия

Ответить
Развернуть ветку
Валентин Хирш

Может я тупой но при чём тут холократия? Это же просто иерархия в которой часть ответственности перенесли на менеджеров

Ответить
Развернуть ветку
Max Bantsevich
Автор

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

Вот к такому и идем мы

Ответить
Развернуть ветку
Валентин Хирш

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

Ответить
Развернуть ветку
Max Bantsevich
Автор

Я думаю наш опыт будет кому-то полезен. У нас не сразу так было и мы прошли через определённые проблемы, чтобы придти к этому.

Ответить
Развернуть ветку
Marina Ivanova

"По итогу"- кровь из глаз. Сорри за офф.

Ответить
Развернуть ветку
Эдуард Забоев

По итогу - что происходит, когда юнит загружен не полностью? Или юнит простаивает?
Один менеджер ведёт только проекты того типа, который делает его команда?

Ответить
Развернуть ветку
Max Bantsevich
Автор

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

Ответить
Развернуть ветку
5 комментариев
Раскрывать всегда