Как программисту стать тимлидом
Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»
Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого.
Работодатели
В принципе, любой работодатель заинтересован в продвижении проверенных сотрудников, а не в приглашении на руководящие посты людей со стороны. Притом, исходит он не из этических соображений, а из очень даже меркантильных: новый человек в команде — это отчасти «кот в мешке» — до конца не знаешь, что он собой представляет (в отличие от проверенного своего сотрудника) — вот почему и существует испытательный срок. Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых. Если же руководящие кадры приглашаются со стороны — это, скорее всего, означает, что руководство компании не видит достойных претендентов среди собственного персонала.
Что делать?
Итак, вы все-таки хотите стать тимлидом:
- Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
- Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
- Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
- Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д’Артаньян» вряд ли приблизит вас к поставленной цели.
- Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
- Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
- Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
- Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
- Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору…
- Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.
Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили.
Дерзайте!


Комментарии
Хорошая статья, согласен со всем. :) Сам пока что не спешу проситься в тимлиды - в данный момент интересно оставаться senior developer’ом.
Статья полезная, но думаю, что не хватает еще одного немаловажного пункта: - умение найти общий язык с руководством и добиться взаимопонимания. Без этого шансы могут свестись к нулю.
Руководотилю команды достается чаще всего вся бюрократия (тикеты, релизы, ревью кода, и т.д.), так что надо просто иметь интерес к таким задачам.
А наш народ больше тяготяет к самому статусу «бригадира», чем к реальным задачам… увы… (наверно совковый менталитет дает еще о себе знать)
О, плюс один! У нас люди стремятся больше командовать (просто, вот, командовать), а не решать какие-то специфические, далеко не технические проблемы.
Статья хорошая. Особенно про нетелепатство понравилось, это я на себе почувствовал. Как-то хотел порулить, но никто об этом не знал, кроме меня. Как только заявил о своем желании, мне сразу дали в руки руль :)
на масштабных долгостроях (типа глобальных систем BI) очень часто, самый эффективный способ - разобраться в какой-то определенной, относительно автономной, области (к примеру, подсистема бизнес анализа или генерации финансовой отчетности), проявлять в ее рамках инициативу, развивать направление - тогда есть шанс, что на такую отдельно взятую область со временем выделят команду, и тим-лидом поставят именно тебя..
Хороший пост! Понравилась фраза «все пидорасы — один я д’Артаньян» :]
плюсодин
“Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых.”
Имхо лукавите. Или сами не понимаете. Хороший кодер может себя на должности руководителя проявить совсем иначе. Особенно если вы как руководитель отдела или тех.директор, мало общались со своими подчиненными разработчиками, полагаясь на ПМ-ов и тим.лидов (что уже само по себе ошибка)… Потому повышая кодера до уровня тим-лида вы рискуете гораздо больше, чем беря беря опытного тим-лида с опытом. Кроме того! Тим-лид даже с опытом будет вынужден в течении хотя бы испытательного срока доказывать свою состоятельность. Да и вообще в новой обстановке люди более мобилизованы. Потому новый человек будет работать за двоих. И нового человека вы сами будете больше контролировать, чем того, кто в вашей компании уже давно… И наоборот, девелопер, которого повышают, может почувствовать расслабленность, полагая, что его ценят и раз его повысили, значит он очень важен для компании и ему простят какую нить лажу. опоздания и небольшие промашки и будет работать расхлябанно. Максимум чем он рискует, вернутся на должность кодера обратно :)… кем и был… Вот именно из этих соображений тех.директоры чаще всего не повышают девелоперов.. Главный и решающий фактор, по которому вас могут повысить, это ваше требование. Когда вы требуете повышения, вы как бы берете на себя обязательства… Тогда тех.директор охотнее идет на встречу, потому что вы были инициатором своего повышения, значит у вас есть желание… Еще лучше если вы возьмете на себя обязанности соглашаясь остаться по началу с той же зарплатой, что была раньше. И лишь доказав свою состоятельность, как тим-лида, начнете требовать повышения зп. Вот так бы я расширил совет с номером 5.
Господа, зачем же так мудрить? В наше время уже никто так не мучается. Я Вас научу как надо: приходите к директору и обещаете светлое будущее. Не получилось - ищете следующую фирму. Лично был свидетелем как человек за месяц, не умея программировать вообще, стал начальником программно-технического отдела. А человек не имеющий никаких лидерских способностей (даже задатков) стал ИТ-директором.
То есть главное - ораторское искусство.
Всем удачи :)
Во-первых важно не только тимлидом стать, а еще и удержаться. Во-вторых такие обещания светлого будущего, обычно ,работают исключительно в мелких низко-квалифицированных компаниях.
Comment form for «Как программисту стать тимлидом»