45 дней сериалов
и фильмов по промокоду:
VC45 Активировать 18+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стало

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

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

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

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

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

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

{ "author_name": "Max Bantsevich", "author_type": "self", "tags": [], "comments": 8, "likes": 8, "favorites": 21, "is_advertisement": false, "subsite_label": "life", "id": 179130, "is_wide": false, "is_ugc": true, "date": "Fri, 20 Nov 2020 17:09:25 +0300", "is_special": false }
45 дней сериалов и фильмов по промокоду VC45
Активировать
Условия подписки Яндекс.Плюс: clck.ru/FMQND. 45 дней подписки Яндекс.Плюс — бесплатно, далее автопродление — 199 руб./мес. с указанием данных банковской карты. Предложение до 31.12.2020г. Только для новых пользователей, ранее не оформлявших подписку Яндекс.Плюс. Условия просмотра на КиноПоиск: ya.cc/4y4UX
18+
0
8 комментариев
Популярные
По порядку
Написать комментарий...
2

Холакратия

Ответить
0

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

Ответить
1

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

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить

Комментарии

null