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

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

Что делать компании в такой ситуации? Если просто сказать человеку: “Ты вряд ли станешь у нас менеджером,” то тимлид начнёт подыскивать новое место работы. Поэтому формулируется гораздо более обтекаемо: “Пока возможности нет, но мы работаем над этим. Как только появится вариант, мы тебя сделаем менеджером”. Тимлиду может казаться, что вся компания в дружном порыве работает над его карьерой. Но вряд ли всё так радужно. Вполне возможен вариант, что об этом желании тимлида помнят и просто ждут (и то не особо), когда ситуация поменяется.

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

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

В общем, начинающему менеджеру пора как-то брать ситуацию в свои руки и действовать активно. Потому что это именно то, чего от него ждут на менеджерской позиции.

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

Как-то беседовал со знакомым, недавним студентом. Его зовут Андрей, он очень умный парень, делает карьеру в IT и ему нужны были мои советы по разным вопросам. В частности он рассказывал, что его девушка хочет переехать в Москву, и он, конечно, переедет с ней, хотя и сомневается в том, что оно того стоит, но девушка очень хочет переехать, и её не переубедить. Так что они переезжают, это 100%. Мы обсудили особенности IT в столице. И тут он попросил карьерного совета:

– Константин, мне хотелось бы из разработчиков стать менеджером в ближайшее время. Что вы мне посоветуете?

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

– Но ведь это  не моё решение! Это моя девушка хочет, а я не уверен.

– Но ведь ты точно переезжаешь?

– Да, уже билеты куплены.

– Значит, ты принял решение.

– Ну… я бы так не сказал…

А я вспомнил про одного своего друга, Михаила, который, когда его уговаривали пойти пива попить или задержаться в гостях дольше запланированного, отвечал: “Друзья, зачем вы меня уговариваете? Я же подкаблучник. Я давно принял решение делать всё так, как жена сказала. Она сказала мне вернуться к десяти и я вернусь. Да, я могу сейчас задержаться, но это сиюминутная выгода. В более долгой перспективе мой подход самый правильный”. Так вот, хотя все решения как бы не его, а его жены, но Михаил – это человек-кремень. Если он сказал, что придёт, то он придёт. Если сказал, что его не будет, то всё, дело решённое. Даже то, что жена решает все вопросы, он формулировал как своё собственное решение. Да это и были его решения, раз он им следовал.

Возможно, вы слышали оправдания разработчика, когда ему указывали на его кривые коммиты на его старом проекте: “Да это не я такой! Там все так писали, хотя я был против! Тимлид коммиты откатывал, если в них хотя бы пары багов сразу не было! Заказчик требовал, чтобы билд всегда сломан был! Я хотел нормально писать, но мне не давали! Да я даже лучше код делал, чем он был, только это незаметно на общем уровне”. Все эти оправдания разной степени правдоподобности не имеют никакого значения. Разработчик отвечает за код, с которым он работает.