Как научить сотрудников самостоятельности. Часть II + проверочный тест

О синхронизации целей, фидбэке и увольнениях.

В первой части этой статьи Алексей Кулаков, генеральный директор digital-продакшена JetStyle и эксперт курса «Искусство управления бизнесом», рассказал, как научить сотрудников самостоятельности, на какой ступени развития какие задачи давать и что делать руководителю, чтобы команда могла решать задачи высокой сложности. В этой части разбираемся с синхронизацией целей, фидбэком и увольнениями.

Цели компании, клиентов и специалистов нужно синхронизировать. Давайте на примере:

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

Если цели разные, будут проблемы. Допустим, компания поручит задачу менеджеру, который получает бонус от прибыли. Менеджер выберет такое решение, чтобы клиент остался доволен, но тогда появится кадровый риск, разработчик будет думать: «А зачем я тут сижу, где развитие? Что вообще происходит? До свидания». Если поручить задачу разработчику, он будет руководствоваться своей целью — решать интересные задачи. Сделает, выложит на Гитхаб, выступит на конференции, но компания потеряет клиента и не получит прибыли.

В мире розовых единорогов компания всё бы сделала правильно с самого начала, например:

• сказала бы разработчику: смотри, ты сейчас делаешь сайт на Вордпрессе, а на следующем этапе будешь решать такие-то интересные задачи — и показала, как эти этапы связаны;
• или сразу наняла бы разработчика, которому интересно работать с Вордпрессом;
  
• или глубже проанализировала бы цели клиента и поняла, например, что на самом деле цель клиента — увеличить продажи в конкретном сегменте, и конкуренция идет не на уровне красоты, а на уровне эффективности сервиса. Так задача стала бы интересной для разработчика.
  

Но если компания находится в менее прекрасной реальности, руководитель должен выбирать, чьими интересами придется пожертвовать, и делать это осознанно. Предположим, разработчик хочет делать интересные сайты, а нужно сделать сайт на Вордпрессе — это конфликт целей. Руководитель не предлагает выбор разработчику, а делает выбор сам, и выбирает одно из двух:

• дать разработчику потренироваться и рискнуть отношениями с клиентом;
• сохранить клиента, но создать кадровый риск.
  

Во втором варианте задачу разработчику нужно будет поставить на более низком уровне абстракции.

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

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

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

Допустим, у руководителя с разработчиком Серегой стартап, и у них есть общая цель — создать нейросеть, которая будет рекомендовать товары. Руководитель ставит задачу, Серега что-то делает и получает фидбэк.

Это пример плохого фидбэка. Чтобы сделать его еще хуже, руководитель не просто говорит это Сереге, а устраивает публичную выволочку в присутствии коллег. Даже если представить, что разработчик толстокожий человек и подумает: «Господи, ну он и дебил, вечно что-то такое говорит. Ладно, собака лает, караван идет» — и не уволится, проблема с фидбэком не исчезает: фидбэк из примера никак не поможет Сереге достичь его цели. Из этого фидбэка вообще непонятно, что теперь нужно делать.

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

Например, руководитель и Серега сформулировали гипотезу, запустили нейросеть, но средний чек не увеличился, а продажи еще и упали.

В этом случае Сереге придется поработать гораздо больше, чем в том, когда руководитель на него просто орал. Потому что он оказался в ситуации, когда несет ответственность за то, что произошло, он эту ответственность на себя брал.

Но руководитель показывает, что уважает его позицию и не отказывается от той части ответственности за задачу, что лежит на нем. Сереге остается согласиться и пойти решать проблему, например, он может сказать: «Я всё понял, давай решим эту задачу другим способом, не нейросетью». И найти в этом какую-то свою зону интереса.

Допустим, Серега говорит: «Знать не знаю, что делать» — это отказ от ответственности и просьба давать задачи попроще. Если такое происходит впервые, это нормально. Руководитель в этом случае замеряет его уровень ответственности: «Хорошо, понял. Я тебе дал задачу для сотого уровня, а ты пока на десятом, ничего страшного, сейчас откалибруемся».

Но если специалист показывает отрицательную динамику: не берет сложные задачи, отказывается от ответственности и справляется со всё менее сложными задачами с низкой степенью ответственности, хотя раньше мог решать любые, — значит, что-то в отношениях с этим человеком идет не так. Возможно, дело не в личных качествах, а в поломке системы «компания — человек», но, если ничего не делать, ситуация будет становиться хуже и хуже до тех пор, пока компания и человек не расстанутся.

Чтобы ситуация требовала увольнения, должно совпасть несколько факторов:

• человек не в первый раз отказывается от ответственности;
• раньше брал более сложные задачи и решал их, а теперь пасует;
  
• не только не знает, что делать, но и не хочет искать решение;
  
• находится в позиции «разгребайте свои проблемы сами»;
  
• отказывается работать над собой.
  

Если совпало, руководитель должен сказать:

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

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

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

Это была часть лекции Алексея Кулакова из модуля «Управление командой» для курса «Искусство управления бизнесом».

Еще у нас есть тест к теме о делегировании: