Почему подчиненные делают не то, что нужно

Я не буду оригинален, если скажу, что сотрудники работают так, как ими управляют. Есть множество причин, почему сотрудники не могут делать то, что хочет от них руководитель, но сегодня я хочу поговорить о самой банальной и распространенной причине: сотруднику дали задание, которое он не умеет делать.

Существует всего 4 типа заданий, которые руководитель может поставить подчиненному. У каждого сотрудника есть комфортный тип задания, который он готов выполнять. По моему опыту, большинство недопониманий между начальником и подчиненным происходит из-за несовпадения типа задания, которое ставит руководитель, и того, какое задание ждет подчиненный.

Эта классификация подходит для сотрудников в любых должностях: от уборщика до CEO, принцип один.

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

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

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

Примеры проблем: упали продажи в этом квартале, наш сайт стал медленно работать, к нам не приходят новые пользователи и так далее.

Может показаться, что решение задачи и устранение проблемы, это одно и то же, просто в первом случае мы формулируем желаемый результат, а во втором - нежелаемую исходную ситуацию. Русский язык вполне позволяет формально переформулировать проблему в задачу. Была проблема “Продажи упали” - стала задача “Поднять продажи”. Но все не так просто, задача от проблемы отличается уровнем анализа, который необходимо провести для выполнения задания. Если внимательно почитать, например, PMBOK, можно обратить внимание, что все процессы проектной работы предполагают, что что-то похожее мы уже делали и базовый сценарий наших действий уже есть. Если мы знаем бюджет, сроки и скоуп задач, то более-менее сразу понятно, что нужно делать дальше, чтобы у нас появился новый сайт. А вот что делать, если упали продажи: нужно ли сделать новый сайт или выложить новые товары на старом сайте, или вообще ничего не делать, а просто подождать?

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

Проблемная область всегда включает контекст. Звучать это может как-то так: у нас есть это, а вот этого больше нет, что можно сделать здесь? "Здесь" - это контекст. Предполагается, что тот, кому ставят такое задание, его понимает. "C ванной что-то надо делать" - проблемная область, "Капает кран в ванной" - это уже проблема, которая через анализ превратится в стопку задач.

Пример разговора CEO и CTO:

- Все наши клиенты в США, а наша инфраструктура в РФ, чего делать будем?

- Уже начали смотреть, как можно зазеркалить БД c контентом на Амазоне, все остальное не так критично, быстро развернуть сможем всегда.

В том, о чем говорит CEO, нет проблемы, но он видит некие риски, которые могут привести к проблемам, которые он хочет решить превентивно. СТО подтверждает, что как минимум одна проблема, видимо, существует и ее решением он уже занялся.

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

Пример разговора СTО и тимлида:

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

Прошло несколько дней.

- Ну что, как успехи с отчетами?

- Еще в процессе, изучаю планы запросов в БД.

- А что бухгалтеры говорят, что за отчет-то у них вообще?

- Я не спрашивал.

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

Задания более высокого уровня воспринимаются как непонятные, невнятные. Строго говоря, так оно и есть, эти четыре типа заданий отличаются уровнем неопределенности, с которым готов работать сотрудник. С повышением уровня задания растет объем работы, который нужно выполнить, увеличивается разнообразие экспертизы, которую нужно иметь, и соответственно растет количество людей, которые будут задействованы в работе над заданием так или иначе, что и приводит к росту неопределенности. Поэтому сотрудник, в должности которого есть слово “менеджер”, не может быть ниже уровня 2. Это уровень тимлидов и проектных менеджеров. Говорить о стратегировании можно только на уровне 4 - уровне, где происходит формулирование проблем, а не только их решение.

Коучи, проповедники аджайла аксиоматически предполагают, что все сотрудники компании имеют уровень 3 или 4 (ха!), умеют ставить себе цели, и собственно поэтому им не нужны линейные руководители (дважды ха!). Во-первых, чем выше уровень, тем меньше таких людей на рынке, придется долго искать и зачастую переплачивать. А во-вторых, захотят ли такие сотрудники делать задания первого уровня? В любой компании (не стартапе) есть скучная операционка (т.е. задания первого уровня), которую кому-то нужно делать.

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

Пример разговора проджект-менеджера и разработчика:

- Я просил тебя убрать всю анимацию со страницы, она тормозит, а демонстрация работы клиенту уже завтра. Готово?

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

- То есть вместо задач из бэклога, ты чинил анимацию, которую я просил просто выключить?

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

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

Каждый из 4 типов заданий предполагает, что подчиненный будет искать ответ на один из 4 вопросов: как сделать, что сделать, зачем делать или почему нужно что-то сделать. Если менеджер сам до конца не знает, что должно быть в итоге, он пытается пробелы забить советами как делать. Если менеджер расписывает алгоритм достижения цели, но знания деталей не хватает, он добавляет рассказы о том, что будет в итоге. В обоих случаях задача превращается в ребус.

Пример разговора CPO и продакт-менеджера:

- У нас увеличился отток пользователей, нам нужна геймификация.

- Ок, я изучу данные по поведению пользователей.

- Да, славно, когда ТЗ для разработки подготовишь?

CPO обозначил проблему и сразу же предложил ее решение (детали я опустил, чтобы не усложнять пример), т.е. поставил задачу. Продакт делает вид, что задачи нет, он хочет работать над решением проблемы. CPO этого не замечает. Получается, продакт должен решить проблему, но ответ уже известен - “делаем геймификацию”. Если “геймификация” не сможет решить проблему оттока, то у этих двух будет явный или скрытый конфликт, потому что непонятно, кто отвечал за выбор решения.

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

P.S. Кому-то могло показаться, что приведенные мной примеры неточны и то, что я назвал проблемой, на самом деле задача или проблемная область. Вполне возможно, в вашем случае это так и есть. Дело в том, что сложность задания можно считать абсолютной величиной только в рамках одной компании и на определенном этапе ее развития. Скажем, в одной компании “запуск A/B-тестов” - это четко расписанный алгоритм, в другой - это целый проект, который требует каждый раз координации работ нескольких отделов и ручного сопровождения. А в третьей компании - это вообще организационная проблема, которую можно решить только полностью пересмотрев методы целеполагания компании.

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

Мой телеграм-канал Токсичный манагер