Знаете, что самое изматывающее в жизни маленькой компании? То, что владельцу бизнеса в день надо принять тысячу решений — от маленьких до глобальных.
Этот процесс принятия решений убивает и выматывает почище тяжелой офисной работы. Какой монитор купить в офис? Как сделать так, чтобы компания завтра не ушла с рынка? Вопросы сыпятся со всех сторон. И так каждый день.
В итоге во вторник поймал себя на мысли, что сейчас 23:30, а мы с партнером до сих пор на телефоне и обсуждаем какие-то насущные операционные вопросы, которые как обычно сами по себе не решаются. Я высказал ему все, что думаю о нашей компании в целом и сотрудниках, в частности.
Тут можно сделать небольшое отступление. Компания у нас, действительно, маленькая: три учредителя (работают бесплатно), восемь сотрудников и несколько фрилансеров. Работа строго организационно поделена между несколькими отделами: операционный отдел (два человека), сервисный отдел (два человека), колл-центр (два человека), служба безопасности (в одном лице), разработка (два человека).
Естественно, отделы общаются между собой по мере необходимости, но забегая вперед скажу, что этого мало. Работа у нас распределенная, сотрудники не сидят в одном офисе, а решают свои задачи, находясь в разных местах.
В итоге, буднично занимаясь микроменджментом, совершенно не замечаешь, как он постепенно поглощает все твои силы и мысли. Кажется, что если сейчас немного отпустишь, весь бизнес разом рухнет. Это, конечно же, приводит к тому, что вся компания расположена прямо у тебя на плечах, примерно как земля покоится на трех слонах.
Однако во вторник в полдвенадцатого ночи вместе с оживленным, остро приправленным матом, телефонным разговором родилось и какое-то предчувствие решения. На этой радужной ноте мы разошлись спать.
Уже утром я не мог дождаться подходящего момента, чтобы поделиться свежими размышлениями с партнером. Несколько идей и понятий, на которых базируется новая идеология работы:
- когда мы по отдельности с партнером не можем принять решение, мы всегда звоним друг другу, чтобы посоветоваться, обсудить что-то и после этого принять взвешенное решение
- мы зачем-то сами загнали себя в угол, когда все, даже самые мелкие решения, зависят от нас
- сама система работы никогда не поощряла самостоятельность в сотрудниках: как будто они малые детки, а мы родители, и все повседневные решения они должны согласовывать с нами.
Мне кажется, это неправильная система работы, которая приводит к эмоциональному истощению. При этом попасть в ее ловушку очень просто: когда ты начинаешь работать, и вообще еще никаких сотрудников нет, ты делаешь все сам, и потом ты продолжаешь делать все сам, хотя сотрудники уже появились, но ты как бы не пропустил их появление.
Итак, манифест:
- По каждой задаче необходимо создавать микрорабочие группы, которые включают в себя сотрудников из разных отделов.
- Этой группе необходимо поручать автономное решение задачи. При этом они могут информировать всех интересующихся о ходе процесса решения, а лучше — сразу о результате (мы активно используем группы в WhatsApp по интересам для решения различных задач).
- Прямая аналогия такой кросс-функциональной рабочей группы — черный ящик, в который ты кладешь проблему, а на выходе получаешь решение. Не имеет значения, как сотрудники к нему пришли
- Внутри группы сотрудники должны активно общаться между собой. Условно называю это: следить друг за другом и подстраховывать друг друга. Если один из участников не тянет, другой вполне может ему напомнить, что он забыл что-то сделать.
- Ответственность за решение задачи лежит на всей группе — не сделал один, значит, не справилась вся команда.
- Первое время такие рабочие группы можно формировать насильно: «Вася, Петя, Коля, задача такая-то, решение сообщите». Иногда они формируются автоматически, если задача стандартизована и уже встречалась раньше. А со временем сотрудники и сами научатся формировать такие группы под задачу.
- Никогда не давать готовое решение группе, даже если ты уже придумал, как надо сделать лучше. Посмотреть, что у них самих получится.
При этом, конечно, никто не отменял регламенты. Очень часто недопонимание возникает из-за того, что кто-то из сотрудников плохо знает или не до конца понимает регламент, по которому надо действовать. В общем, создаешь базовые регламенты, формируешь микрогруппы под задач — и понеслась. Теперь пробуем работать так.
Скажите, мой бизнес рухнет, или новая идеология вдохнет в него новую жизнь?
Привет, Михаил!
Спасибо, что делитесь опытом и не стесняетесь говорить о проблемах. Советчиков с "не ваше это дело" смело шлите нахуй. Очевидно, что они не были на месте основателя компании и не знают, о чем говорят.
Я 10 лет руковожу собственным бизнесом без партнеров и до 35 сотрудников в разное время. Хорошо понимаю вашу боль. Сам сталкиваюсь с необходимостью принимать много очень разноплановых решений на всех уровнях: от выбора принтера в офис и собеседования уборщицы до плана продаж на год вперед и управления инфраструктурой на AWS.
Необходимость принятия решений — это симптом, и тут непосредственно его нечего обсуждать. Принимать решения, имея достаточно информации, легко. Проблема обычно в другом. Чтобы проработать задачу и получить эту информацию, нужно время, энергия и компетенция. Для этого мы и нанимаем людей.
Дальше попробую резюмировать свой опыт. Кстати, многие проблемы до сих пор не решены. Я не претендую на лавры бизнес-гуру и проповедника. Мои советы могут не работать в вашем случае. Просто надеюсь, что будут полезными.
С ростом бизнеса нанимать средний уровень менеджмента. В вашем случае это может быть руководитель операционного и сервисного отделов, так как в каждом из отделов пока всего по двое сотрудников.
Когда я год назад нанял руководителя клиент-центра (у меня интернет-магазин), это стало огромным облегчением. Значительная часть вопросов стала решаться уровнем ниже без моего участия. Правда, позже выяснилось что часть проблем решались очень криво и меня все-таки надо было привлечь. Но тогда я не смог бы заниматься другими сферами. Сейчас уволил человека с этой позиции, меня завалило запросами, но зато вижу много возможностей для улучшения процессов. Похоже, надо делать именно так: ставить человека на какую-то зону, и периодически работать за него или очень глубоко вместе с ним, чтобы растрясти то, о чём он молчит (не со зла, конечно).
Нанять операционного или исполнительного директора. Этого я не сделал до сих пор и очень жалею об этом. Так же, как и с предыдущей ролью, есть сильный страх, что всё пойдет по пизде, но есть и подозрение, что даже если неподходящий сотрудник будет справляться на 30% — это лучше, чем без него.
Учиться отказываться от чужих обезьян. Люди склонны переваливать ответственность на руководителя, если тот позволяет. Согласен с одним из комментаторов (или это были вы?), что надо включать в процесс найма оценку способности самостоятельно принимать решения, но сам такое не умею.
А вот что можно сделать уже сейчас, не надеясь поменять "плохих" сотрудников на "хороших". Каждый раз, когда вас просят решить что-то, спрашивать себя:
1) достаточно ли это важное решение, чтобы им занимался я?
2) могу ли я доверить этому сотруднику решить самому?
3) что будет, если он сделает не так, как сделал бы я?
В некоторых случаях вы сможете ответить себе: "Да похер, пусть разберется сам!". Знаю, это очень трудно. Особенно, если вы, как и я, PaEi по Адизесу.
Систематически поощряя принимать решения самостоятельно, вы сможете вырастить в людях уверенность и снимете с себя часть проблем. Но будьте аккуратны: если вам не понравится то, что сделал подчиненный, надо деликатно поправить его, чтобы не отбить желание принимать решения в будущем. Будьте готовы, что временами вам будет казаться, что они вообще всё делают через жопу. Я всё еще учусь отделять свой перфекционизм от действительно плохо сделанной работы.
Никогда не давать готовое решение группе, даже если ты уже придумал, как надо сделать лучше. Посмотреть, что у них самих получится.Полезно, если есть время и задача некритична. Можно сначала давать время разобраться и предложить свои варианты, потом в обсуждении, задавая вопросы, проверить хорошее ли решение предлагает сотрудник. Например, "а что будет, если у партнера изменится шаблон накладной? Как будет работать твой парсер?". Если в процессе выявили слабые места, можно предложить подумать в сторону вашего варианта, но не спешить называть его. В идеале подвести сотрудника к вашему решению так, чтобы он думал, что оно его.
Все советуют отстраивать бизнес-процессы. Тут важно понимать, когда это уместно в плане этапа жизненного цикла компании. На старте бизнес-процессы могут мешать. Их надо отлаживать, начиная с самых статичных, т.е. таких что скорее всего не будут скоро перекраиваться. Обычно советуют начинать с самого главного, например, процесса продаж или обработки заказов. В 2014 я поставил процесс создания товаров на сайте с контент-менеджером. Там уже четыре года ничего не меняется — я не заглядываю.
Иногда они формируются автоматически, если задача стандартизована и уже встречалась раньше.Если задача уже встречалась, ставьте процесс: напишите короткую инструкцию в ГуглДоках и выберите ответственного. В идеале, если ответственного назовете не "Коля", а, скажем, "Менеджер проектов". Потом при смене Коли на Алексея дадите Алексею все доки с инструкциями для менеджера проектов.
Спасибо разрабам Виси за ограничение в 5000 символов. Стимулируете обстоятельную дискуссию?
ПРОДОЛЖЕНИЕ
Теперь о ключевой идее манифеста. Она мне не нравится. Разделить ответственность на группу, мне кажется, гарантирует невыполнение задачи. В этом плане стоит учиться у жестких иерархических организаций, например, армии. Представьте, чтобы на поле боя тактические решения принимала группа вместо одного генерала.
Мне кажется, ответственный должен быть один, а остальные подключаться по необходимости. Я бы вам посоветовал завести задачник для команды, который позволяет организовать следующее. В любую задачу можно включить любого сотрудника, но отдельно обязательно указать одного ответственного исполнителя. Я пользуюсь Планфикс, но вам он может не подойти. Еще раз важные моменты:
1) У задачи обязательно есть один исполнитель
2) В задачу можно подключить любого сотрудника или даже контакт без аккаунта в задачнике.
Ни в коем случае не переводите работу из чатов в другие чаты или почту. Только в задачник и как можно скорее.
Далее вы пишете:
Если один из участников не тянет, другой вполне может ему напомнить, что он забыл что-то сделать.Это тоже в идеале должен помогать делать задачник — подсказывать, если задача давно не обновлялась. У меня пока не работает, но представляю как можно настроить. Фолбек — руководитель просматривает задачи, где его подчиненный ответственный и выписывает пиздюлины управленческие воздействия, если задача зависла.
Советую почитать в порядке убывания важности:
Жесткий менеджмент Кеннеди
Личную продуктивность Кеннеди
Курс Максима Дорофеева
Управление проектами Товеровского
для старта о том, как "сделывать" проекты в посте 'Что значит "Сделать"'
Весь Адизес
Хочется что-то по менеджменту, управлению проектами и мотивации персонала, но всё так разбросано, что и не выделишь кого-то одного. Разве что покопаться у Брайана Трейси или попробовать по гибкому управлению что-то взять — методики из разработки ПО вполне себе пригодны и в других сферах.
Ну и на конец. Ваш бизнес не рухнет, по крайней мере от этих экспериментов. Вы сталкиваетесь ровно с теми же проблемами, что и тысячи фаундеров. Читайте, пробуйте, переделывайте —всё по классике. Успехов!
По сути же никаких вопросов нет, впитываю, книжки постараюсь прочитать. С аналогией армии не соглашусь. Не люблю ни армии, ни жесткие структуры. Хочется какого-то невероятного agile. Но, конечно, я не знаю, получится или нет. Пробуем.
Попробуйте почитать Рикардо Семлера "Маверик")
Мне кажется, нам срочно надо 3 такие книжки!
Купил, читаю.
Армию, конечно, тоже не люблю. Но тут практика проверенная временем и жизнями. Конечно, мы не на войне и руководим не мясом. Но вот именно в плане ответственности, кажется, все согласны, что коллективная работает гораздо хуже индивидуальной.
Блин, это идет вразрез с моим экспериментом! Плохо. Импонирует, что вы "фанат" Бюро Горбунова, меня с ними многое связывало на заре карьеры.
Ребята из Бюро очень много полезного делают, как не быть фанатом)
По гибкости вам тогда зайдёт Management 3.0 Апелло. Название громкое, но по сути там просто идеи как можно применять гибкие методики разработки вне процессов создания ПО. А дальше уже знакомиться с самими методиками, например, Скрам и пробовать внедрять. Я тут профан, так что советов давать не буду.