От разработчика до руководителя

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

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

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

Другие менеджеры не заинтересованы в ваших советах. Более того, некоторые считают, что вы им мешаете, и даже становятся агрессивными, когда находят, что вы вмешиваетесь в их дела. Ваш руководитель не соглашается с тем, что вы можете руководить большим коллективом. Вы даже не можете себе объяснить, почему он так считает. По вашему-то мнению, его собственные способности как руководителя оставляют желать лучшего. Может быть, он боится, что потеряется на вашем фоне? Он очень неодобрительно относится к вашим выступлениям с лекциями и докладами — вообще раздражается, когда вы слишком надолго покидаете кабинет. И это несмотря на определенную пользу для команды от ваших лекций. Искусство руководить без того, чтобы не обидеть и не принизить ни ваших подчиненных и коллег, ни вашего руководителя, оказалось гораздо сложнее, чем вы ожидали. Но если вам дадут более многочисленную команду, то, как вы полагаете, вы получите повышение. Так что, по крайней мере, карьерный путь для вас ясен. Но когда вы узнаёте, что штатный инженер-программист получает больше, чем вы, вас это обескураживает. Так что теперь вам нужно быстренько соображать, как все-таки быстрее получить более многочисленную группу. Иначе какой смысл во всех этих стрессах?

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

Хороший менеджер, плохой менеджер: «царь организационного процесса»

«Царь организационного процесса» уверен, что существует один-единственный организационный процесс и при правильной эксплуатации он поможет решить все проблемы команды. Такие «цари» могут быть одержимы agile-, kanban-, scrum-процессами, «методами бережливого производства» или даже «каскадной методикой». Они точно знают, как эффективно организовать работу системы on call (получение сигналов о сбоях в работе программного обеспечения в режиме реального времени), как нужно организовывать проверку (инспекцию) кода, как и весь процесс релиза готового продукта. Обычно такие люди очень организованны и любят детали. Как правило, они хорошо знают все производственные нормы и правила и неукоснительно следуют им.