Как хорошему разработчику не стать плохим менеджером - Константин Борисов

В столице нашей родины, Москве, в большом офисном центре работала небольшая разработческая команда. Это был филиал международной компании с главным офисом во Франции. И у этой компании настали тяжёлые времена, из-за чего ей пришлось увольнять разработчиков.

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

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

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

– Андрей, я работаю на тебя с самого дня открытия филиала. Ты должен мне пойти на встречу. Уволь меня, из меня ипотека все соки выжимает!

– Не могу я тебя уволить. Без тебя наш проект загнётся.

– Уволь, а? Я буду вечерами работать. Ты даже не заметишь, что я уволен!

…

– Андрей, уволь меня, а то я уволюсь сама!

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

– Тогда я не уволюсь, а ребёнка рожу! Будешь знать!

– Назови в мою честь. Всё-таки, получается, ребёнок родится из-за меня. Могу быть крёстным, если ты позволишь.

…

– Андрей, почему ты уволил этого рукожопа Олега?! На его месте должен был быть я!

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

– И теперь он счастливый бухает в баре, а я по-прежнему пашу! Где справедливость?!

– Справедливости в жизни нет. Не могу же я уволить всех ключевых сотрудников. Как мне проекты делать? Работай иди.

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

Одна из вещей, которые менеджер не должен никогда делать – это ругать своих подчинённых. Начинающему менеджеру как обычному человеку хочется поныть про свои беды: “Вот Петя такой косячник, такой косячник. У меня из-за него сплошные проблемы. Он вообще не понимает, что он делает”. Так вот каждый менеджер должен над собой работать, чтобы подобные желания у него даже не просыпались ни при каких условиях.

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

Гораздо сложнее менеджеру даётся понимание, что нельзя ругать свою команду своему начальству. Неопытный менеджер часто хочет оправдать проблемы на своём проекте ошибками подчинённых: “Мы релиз задержали из-за того, что Игорь пропал без объяснения причин и не сделал свои задачи!”

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

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

Так что не надо рассказывать своему начальству, подчинённым и знакомым, что вы завалили свои задачи из-за трудностей с командой. Лучше поругайте себя за то, что не справились со своей работой.

Часто нежелание человека делать свою работу представляют как “смертный грех”, который ставит крест на работнике как профессионале, и с которым менеджер ничего не может поделать. Говорят: “Ничего нельзя сделать, если человек просто не хочет работать”. Как и большинство прочих расхожих истин, эта "истина" ложная и часто заводит менеджеров не туда.

Первая причина порочности такого подхода выходит из самого понятия “мотивация”. Менеджеры обязаны мотивировать свою команду, в случае необходимости. А что такое мотивация? Это как раз стимуляция желания делать какие-то действия. То есть команда не хочет делать то, что надо менеджеру, а он её мотивирует, чтобы она таки это делала.

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

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

Легко вспомнить ежедневные ситуации, когда человек высказывает своё “не хочу, не буду”. Например, от заказчика приходит очередное изменение давно реализованных требований и надо переписывать код. Или менеджер хочет, чтобы оценка в часах была вписана во все тикеты Jira. Или кто-то сломал билд, а от непричастного к этому разработчика ждут, что он его починит. Или заказчик организовал ежедневные митинг в неудобное время. Или нужно задержаться для исправления мелкого, но неприятного бага.