Как научиться делегировать

Бывшая вице-президент Goldman Sachs по технологиям Камиль Фурнье систематизировала свой опыт управления в IT-отрасли и написала руководство о том, как из инженера-программиста стать руководителем высшего звена. Книга вышла на русском языке в издательстве «Манн, Иванов и Фербер» в апреле 2018 года. Мы публикуем отрывок из неё.

Хороший менеджер, плохой менеджер: один лезет во все мелочи, а другой делится полномочиями

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

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

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

Лучший из членов команды Джейн превратился в слабого работника буквально за день. Что случилось? Вас охватило стремление к мелочной опеке сотрудников. Сложный проект нельзя затянуть, а он под угрозой, и вы вступаете, чтобы всё исправить. Вы делегируете некоторые полномочия и обязанности сотрудникам, но потом вдруг обнаруживаете, что вам не нравятся предложенные ими программные решения. Поэтому вы приказываете, чтобы они их переписали. Вы заставляете каждого приходить и советоваться с вами до решения, потому что не доверяете им и не верите, что они всё сделают правильно. Или потому, что ранее они уже делали многочисленные ошибки, расплачиваться за которые пришлось вам.

А теперь давайте посмотрим на коллегу Джейн по имени Шерилл. Шерилл поручила Бет руководство первым проектом. Шерилл знает, что этот проект должен быть завершён точно в срок, но не посещает все совещания. Вместо этого они с Бет решают, на каком именно из них ей нужно присутствовать. Она помогает Бет понять, какие детали ей следует знать. С такой поддержкой Бет чувствует себя уверенно, но также понимает: Шерилл ей всегда поможет. И когда к моменту завершения проекта возникает стрессовая ситуация, Бет просит Шеррил о помощи в небольшом сокращении проекта, чтобы закончить вовремя.

Опыт работы на этом проекте прибавляет Бет уверенности и готовности взяться за более крупные начинания и работать на Шерилл ещё старательнее. Подходы Джейн и Шерилл высвечивают тонкую грань, отличающую микроменеджера и эффективного руководителя, делегирующего подчинённым свои полномочия. И Джейн, и Шерилл стараются поручить некоторые обязанности по управлению приоритетным проектом членам команды, чтобы вырастить из них лидеров. Однако Джейн в конечном счёте никогда не выпускает контроль из рук и этим мешает Санджаю, тогда как Шерилл ставит перед Бет ясные цели и чётко определяет её обязанности и права, помогая в достижении успеха.

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

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

Доверие и контроль — два важнейших вопроса, связанных с микроменеджментом. Если вы по мелочам опекаете всякого, то, скорее всего, не верите в возможность правильно выполнить задания или хотите жёстко контролировать результаты работы, чтобы они точно соответствовали вашим стандартам. Это часто случается, когда талантливые инженеры-программисты становятся менеджерами, особенно когда они гордятся своими техническими знаниями и опытом. Если ваша ценность для команды сместилась с того, что вы хорошо умеете делать (писать код), на то, что хорошо делать вы ещё не умеете (управлять людьми), то может возникнуть соблазн относиться к подчинённым как к слабым подобиям самого себя.

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

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

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

Практические советы по правильному делегированию

ИСПОЛЬЗУЙТЕ ЦЕЛИ КОМАНДЫ, ЧТОБЫ ОПРЕДЕЛИТЬ, В КАКИЕ ДЕТАЛИ СЛЕДУЕТ ВЛЕЗАТЬ

Когда вы как менеджер чувствуете желание покопаться в мелочах, спросите свою команду, как она измеряет успех, и попросите её сделать продвижение вперёд видимым для вас. У вас чешутся руки? Посидите на руках недельку-другую и посмотрите, что представит вам команда. Если им нечем с вами поделиться, это может означать, что необходимо скорректировать направление работы, что, в свою очередь, подразумевает: вам нужно влезть в детали.

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

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

ПОЛУЧАЙТЕ ИНФОРМАЦИЮ ОТ СИСТЕМ, ПРЕЖДЕ ЧЕМ ОБРАЩАТЬСЯ К СОТРУДНИКАМИ

Самые плохие микроменеджеры — те, кто постоянно запрашивает информацию, которую могут получить сами. Можно запрашивать у вашей команды обобщённую информацию по состоянию проекта или использовать группу для сбора важной информации из других источников. Но то, что доступно вам, вы должны делать сами. Команде не доставит никакой радости потратить половину продуктивного времени на вашу работу. Посмотрите на систему управления версиями* и тикет-систему, отражающую возникновение у программы проблем. Получите информацию по сбоям, посмотрите учёты, а также сообщения о проблемах, приходящие в режиме on call. И помните, что такая информация — только часть контекста, а не вся картина, и без сопоставления с только что упомянутыми целями команды она ничего не значит.

КОРРЕКТИРУЙТЕ ФОКУС ВНИМАНИЯ В ЗАВИСИМОСТИ ОТ ФАЗ ПРОЕКТА

Если вы непосредственно руководите одной или двумя командами, то должны знать все детали продвижения проекта, как и при обычной работе команды (например, проведение утренних летучек). Но на разных этапах проекта детали приобретают бóльшую или меньшую важность. В начале разработки проекта следует уделять ему больше внимания, чтобы сформулировать ясные цели и создать хорошую идею системы. Когда вы близки к сдаче результата, более важными становятся детали продвижения проекта, потому что на этом этапе принимается больше решений, содержащих информацию по конкретным действиям. Однако в нормальном рабочем процессе вам обычно достаточно знать, что продвигается вперёд, а что отстаёт от намеченного. Особенно если вы можете использовать информацию для корректировки работы или помощи испытывающему сложности сотруднику.

УСТАНОВИТЕ СТАНДАРТЫ ДЛЯ КОДА И СИСТЕМ

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

НЕЙТРАЛЬНО, А ЛУЧШЕ ПОЗИТИВНО ОТНОСИТЕСЬ К ХОРОШИМ И ПЛОХИМ НОВОСТЯМ ВНУТРИ КОМАНДЫ

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

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

Даже если ваша команда не разбежится, вы потонете в бесчисленных переработках, а ваша нагрузка будет только возрастать. Если с вами это уже произошло, попытайтесь уменьшить еженедельное количество рабочих часов. Позволив себе в данную конкретную неделю поработать 45 часов, на что именно вы их потратите? Используете ли вы пять дополнительных часов, чтобы внести поправки в код, написанный младшим разработчиком? Или углубитесь в детали проекта, в целом идущего гладко, чтобы найти в нём небольшие ошибки? Или сосредоточитесь на более крупных проблемах? Удастся ли вам потратить дополнительные часы на размышления о будущем, а не на пережёвывание деталей настоящего? Ваше время как тимлидера слишком ценно, чтобы терять его попусту. А ваша команда заслуживает менеджера, доверяющего ей многое делать самостоятельно.