Computerworld, США

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

Обращали ли вы когда-нибудь внимание на то, что вам не всегда удается должным образом распределить обязанности среди своих подчиненных? Стоит вам поручить кому-нибудь из них задачу, как спустя несколько дней она снова появляется в вашем же списке дел? Я называю такую ситуацию «эффектом бумеранга делегирования».
Когда такое случается, большинство ИТ-менеджеров предпочитают считать себя жертвами. Я часто слышу что-то подобное: «Мои сотрудники не готовы делать то или другое, так что мне приходится ‘тащить’ всю работу на себе. Как мне тяжело».
Но это глупость. Как правило, дело не в том, что сотрудники не могут выполнить какую-то работу, а в том, что менеджер не хочет, чтобы они ее выполняли. Менеджер стремится сделать ее сам, как бы он ни утверждал обратное.
Эффект бумеранга проявляется потому, что менеджеры сами загоняют себя в тупик, так как им не хочется передавать другим ответственность и полномочия. Иногда ИТ-специалисты по собственной инициативе отказываются от такой работы, потому что не стремятся выполнять предлагаемые задания или идти на риск и брать на себя ответственность. Но очень часто так происходит потому, что подчиненные иначе, чем менеджеры, представляют себе, как именно распределены обязанности, каковы предоставляемые полномочия и какой личной инициативы от них ждут.
Так каким образом это происходит? С моей точки зрения, можно выделить три ситуации.
1. Предоставление отчета о положении дел отделяется от принятия связанных с этим отчетом решений. Чаще всего подчиненный начинает с того, что предоставляет отчет о положении дел. Но вскоре становится очевидно, что решение по этому отчету в любом случае будет принимать руководитель, тем самым беря на себя ответственность. Так происходит либо потому, что подчиненный об этом просит, либо потому, что руководитель чувствует себя обязанным, получив информацию, предпринять какие-то действия. Но когда такое случается, руководитель фактически дает подчиненному понять, что тот не должен проявлять инициативу.
2. Полномочия превращаются в рекомендации. Когда вы передаете полномочия на принятие решений, иногда подчиненные приходят к вам с рекомендациями и анализом, а не с готовыми решениями. В этом случае подчиненный просит снять с него бремя ответственности.
3. Контроль по мелочам отбивает желание проявлять инициативу. Руководитель настолько жестко контролирует выполнение работ, что подчиненный с готовностью возвращает ему ответственность, поскольку подозревает, что тот на самом деле вообще не стремится возлагать на него какие бы то ни было обязанности.
Так каким образом добиться эффективного распределения обязанностей?
1. Познайте себя. Попытайтесь разобраться, как вы на самом деле относитесь к передаче обязанностей. Если вы воспринимаете это спокойно, подумайте, кому именно вы можете их передать и почему.
2. Не ловите бумеранг. Когда кто-нибудь предлагает вам отчет о положении дел, вместо того чтобы указывать, что тому следует делать, спросите его, что он сам планирует делать. Когда подчиненный предлагает рекомендации, поблагодарите его за информацию и спросите, что планирует делать именно он. И не поддавайтесь искушению во все вмешиваться.
3. Дайте ясно понять, инициативы какого уровня вы ждете от подчиненного, когда ставите перед ним задачу. Объясните, передаете ли вы ему полномочия на принятие решений или нет. Выясните, готов ли человек принять на себя предлагаемую ответственность. Убедитесь, что ваши ожидания совпадают с возможностями подчиненного.
4. Скажите об этом снова. Когда кто-то пытается вернуть вам задачу, еще раз, как в самом начале, повторите, на какой уровень инициативы вы рассчитываете. Напомните человеку ваше первоначальное соглашение.
Разобравшись в своих ощущениях и не тратя лишних усилий на контроль за своими действиями, вы сможете корректно распределять обязанности. Вы не должны становиться жертвой эффекта бумеранга делегирования.

Пол Глен — автор популярной книги Leading Geeks: How to Manage and Lead People Who Deliver Technology (Jossey-Bass, 2003).