Как научить сотрудников самостоятельности. Часть II + проверочный тест
О синхронизации целей, фидбэке и увольнениях.
В первой части этой статьи Алексей Кулаков, генеральный директор digital-продакшена JetStyle и эксперт курса «Искусство управления бизнесом», рассказал, как научить сотрудников самостоятельности, на какой ступени развития какие задачи давать и что делать руководителю, чтобы команда могла решать задачи высокой сложности. В этой части разбираемся с синхронизацией целей, фидбэком и увольнениями.
На любом уровне нужно синхронизировать цели
Цели компании, клиентов и специалистов нужно синхронизировать. Давайте на примере:
Некая студия делает корпоративные сайты на Вордпрессе. Ее цель — долговременные отношения с клиентами. Цель клиентов — чтобы сайт выглядел хорошо, решал маркетинговые задачи и обошелся недорого. А разработчик хочет решать интересные задачи, учиться у лучших, пробовать новые технологии и, например, сделать сайт не на Вордпрессе, а в каком-нибудь современном фреймворке с модными программерскими методами, чтобы было о чём рассказать на технологической конференции.
Здесь есть конфликт целей как минимум у разработчика и клиента. Потому что если взять вместо Вордпресса другой фреймворк, поднять докер-контейнеры, написать все как набор микросервисов, то на ближнем горизонте клиент получит сайт, который обойдется дороже, но, возможно, будет работать хуже, чем вордпрессовский. Например, может оказаться, что сайт на Вордпрессе отлично справлялся с задачей и имел гору написанных раньше удобных мелочей, которые для сайта в модном фреймворке не дописали, потому что было не до этого.
Цель компании: Долговременные отношения с клиентами.
Цель специалиста: Решать интересные задачи.
Цель клиента: Красивый сайт недорого и быстро (это пример плохой цели, которая дальше приведет к рассинхронизации).
Если цели разные, будут проблемы. Допустим, компания поручит задачу менеджеру, который получает бонус от прибыли. Менеджер выберет такое решение, чтобы клиент остался доволен, но тогда появится кадровый риск, разработчик будет думать: «А зачем я тут сижу, где развитие? Что вообще происходит? До свидания». Если поручить задачу разработчику, он будет руководствоваться своей целью — решать интересные задачи. Сделает, выложит на Гитхаб, выступит на конференции, но компания потеряет клиента и не получит прибыли.
«А зачем я тут сижу, где развитие? Что вообще происходит? До свидания»
В мире розовых единорогов компания всё бы сделала правильно с самого начала, например:
- сказала бы разработчику: смотри, ты сейчас делаешь сайт на Вордпрессе, а на следующем этапе будешь решать такие-то интересные задачи — и показала, как эти этапы связаны;
- или сразу наняла бы разработчика, которому интересно работать с Вордпрессом;
- или глубже проанализировала бы цели клиента и поняла, например, что на самом деле цель клиента — увеличить продажи в конкретном сегменте, и конкуренция идет не на уровне красоты, а на уровне эффективности сервиса. Так задача стала бы интересной для разработчика.
Но если компания находится в менее прекрасной реальности, руководитель должен выбирать, чьими интересами придется пожертвовать, и делать это осознанно. Предположим, разработчик хочет делать интересные сайты, а нужно сделать сайт на Вордпрессе — это конфликт целей. Руководитель не предлагает выбор разработчику, а делает выбор сам, и выбирает одно из двух:
- дать разработчику потренироваться и рискнуть отношениями с клиентом;
- сохранить клиента, но создать кадровый риск.
Во втором варианте задачу разработчику нужно будет поставить на более низком уровне абстракции.
Задача на более высоком уровне абстракции: Серега, пойди, разберись с клиентом, сделай всё в лучшем виде.
Задача на более низком уровне: Серега, мы делаем сайт на Вордпрессе, подключи вот эти два модуля и натяни вот этот шаблон.
Так руководитель выполняет мыслительную часть задачи сам, а разработчику делегирует гораздо меньший кусок ответственности. Он поступает с ним как с менее самостоятельным специалистом и снижает этим вероятность кратковременных рисков, например испорченных отношений с клиентом, но делает жизнь разработчика менее интересной и самостоятельной.
Чтобы выращивать самостоятельных людей, нужно создавать обширные области, в которых цели будут совпадать. Когда цели совпадают, появляется доверие и можно делегировать задачи с более высоким уровнем ответственности.
Хороший фидбэк помогает достигать целей
Возвращаемся к теме фидбэка — это обратная связь. В нашей системе есть критерий хорошего фидбэка, и он простой: человек, которому дают обратную связь, считает, что она продвинула его к достижению цели.
Каждая система, в том числе человек, формируется под то, что определяет развитие — это обратная связь: где берем, умеем ли переваривать, на что из обратной связи реагируем. Если компания становится источником самой ценной обратной связи для своих специалистов, это позволяет формировать их под задачи системы.
Если же специалист получает самую ценную обратную связь не от компании, а например на отраслевых конференциях, на форуме или в чатике других специалистов, компанию можно поздравить: она выпустила его на свободный кадровый рынок.
Это не значит, что людей нужно держать в бункере и не пускать во внешний мир — нет, это невозможно. Задача в том, чтобы давать самый качественный и ценный фидбэк.
Допустим, у руководителя с разработчиком Серегой стартап, и у них есть общая цель — создать нейросеть, которая будет рекомендовать товары. Руководитель ставит задачу, Серега что-то делает и получает фидбэк.
Задача:
Серега, у нас есть интернет-магазин, он торгует памперсами, прикрути, пожалуйста, нейросеть, чтобы она рекомендовала товары и увеличивала средний чек.
Фидбэк:
Серега, что ты работу сделал как дурачок! Это что вообще такое? Я же тебе говорил, что главное — показывать дорогие товары сверху (а он не говорил, и это вообще глупая идея). А ты этого не сделал! Почему ты вообще потратил так много времени?
Это пример плохого фидбэка. Чтобы сделать его еще хуже, руководитель не просто говорит это Сереге, а устраивает публичную выволочку в присутствии коллег. Даже если представить, что разработчик толстокожий человек и подумает: «Господи, ну он и дебил, вечно что-то такое говорит. Ладно, собака лает, караван идет» — и не уволится, проблема с фидбэком не исчезает: фидбэк из примера никак не поможет Сереге достичь его цели. Из этого фидбэка вообще непонятно, что теперь нужно делать.
Если руководитель хочет, чтобы фидбэк был хорошим, он должен дать его так, чтобы помочь человеку достичь цели. Для этого руководителю нужно заранее позаботиться о передаче ответственности: и руководитель, и специалист должны понимать, что они делают, зачем и вместе сформулировать гипотезу, как взрослые равные люди.
Например, руководитель и Серега сформулировали гипотезу, запустили нейросеть, но средний чек не увеличился, а продажи еще и упали.
Задача:
Серега, предложи, пожалуйста, решение, которое нам увеличит LTV. Давай договоримся, как будем проверять, допустим, сделаем A/B-тест — трафика у нас хватает. Возможно, мы с первого раза не попадем.
Фидбэк:
Серега, у нас проблема. В смысле у тебя и у меня (руководитель не перекладывает ответственность, а показывает, что решение принимали вместе и ответственность общая).
Мы уронили продажи. Теперь давай, во-первых, как можно быстрее откатимся назад. А во-вторых, проанализируем и поймем, что мы сделали неправильно и как мы сюда попали? Где мы сделали ошибку? И что мы из этого вынесем полезного?
В этом случае Сереге придется поработать гораздо больше, чем в том, когда руководитель на него просто орал. Потому что он оказался в ситуации, когда несет ответственность за то, что произошло, он эту ответственность на себя брал.
Но руководитель показывает, что уважает его позицию и не отказывается от той части ответственности за задачу, что лежит на нем. Сереге остается согласиться и пойти решать проблему, например, он может сказать: «Я всё понял, давай решим эту задачу другим способом, не нейросетью». И найти в этом какую-то свою зону интереса.
А если он говорит: «Босс, но я не знаю, что делать!»
Допустим, Серега говорит: «Знать не знаю, что делать» — это отказ от ответственности и просьба давать задачи попроще. Если такое происходит впервые, это нормально. Руководитель в этом случае замеряет его уровень ответственности: «Хорошо, понял. Я тебе дал задачу для сотого уровня, а ты пока на десятом, ничего страшного, сейчас откалибруемся».
Хорошо, понял. Я тебе дал задачу для сотого уровня, а ты пока на десятом, ничего страшного, сейчас откалибруемся.
Но если специалист показывает отрицательную динамику: не берет сложные задачи, отказывается от ответственности и справляется со всё менее сложными задачами с низкой степенью ответственности, хотя раньше мог решать любые, — значит, что-то в отношениях с этим человеком идет не так. Возможно, дело не в личных качествах, а в поломке системы «компания — человек», но, если ничего не делать, ситуация будет становиться хуже и хуже до тех пор, пока компания и человек не расстанутся.
Чтобы ситуация требовала увольнения, должно совпасть несколько факторов:
- человек не в первый раз отказывается от ответственности;
- раньше брал более сложные задачи и решал их, а теперь пасует;
- не только не знает, что делать, но и не хочет искать решение;
- находится в позиции «разгребайте свои проблемы сами»;
- отказывается работать над собой.
Если совпало, руководитель должен сказать:
«Серега, ты тут работаешь, чтобы достигать своих целей, а мы — своих. Мы хотим, чтобы рады были обе стороны, и всегда готовы поговорить о том, что тебе интересно. Нам интересно, чтобы ты всё более эффективно решал задачи компании, а мы тратили на это меньше усилий. У нас это называется профессиональным ростом и повышением уровня ответственности. А самый страшный симптом — когда нам приходится снижать твой уровень ответственности.
Раньше мы могли доверять тебе более ответственные задачи — просто просили разобраться с проблемой, и ты разбирался. А сейчас не справляешься, и нам нужно спускаться на уровень ниже и принимать решения за тебя. Мы сами решаем, за какой срок и какими методами тебе решать задачу. И это тревожный сигнал, Серега».
Чтобы не доводить до увольнения, еще при найме нужно проговорить, чего компания ждет от человека, а человек — от компании. Руководитель должен четко обозначить, при каких условиях компания расстается с людьми. Например, рассказать, как компания оценивает рост специалиста и что будет, если через три года роста не произойдет.
В норме хороший специалист всегда стремится к расширению своей зоны ответственности. Это необязательно должен быть карьерный рост, например, это может быть погружение в более сложные технические задачи. Но в здоровой ситуации человек хочет развития — в бизнесе это значит, что он решает всё более сложные и ответственные задачи.
Нельзя сказать, что развитие — универсальная человеческая ценность, не всем людям это нужно, но для компаний, которые хотят расти, — да, ценность универсальная.
Это была часть лекции Алексея Кулакова из модуля «Управление командой» для курса «Искусство управления бизнесом».
Еще у нас есть тест к теме о делегировании:
Хорошая статья
Статья хорошая, а по ссылкам 404:(
Потрясающий материал. Что первая часть, что вторая. И чем дольше работаешь, тем лучше понимаешь