Карьера в IT: должность Team Lead

Данный материал открывает цикл «Карьера в IT», посвященный описанию разных профессий внутри сферы разработки ПО. В этот статье мы поговорим о первой пост-сеньоровской ступеньке IT-карьеры — позиции team lead.

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

По статистике ДОУ, средний возраст украинских тимлидов — 28 лет, средний опыт работы — 6,5 лет, средняя зарплата — $2800.

Обязанности

Тимлид — это нечто среднее между проектным менеджером и квалифицированным девелопером.

На проектах есть две lead роли: менеджерская — PM, и техническая — System Architect. Тимлид отчасти выполняет обе роли, но акцент его обязанностей направлен на менеджмент (акцент на техническую часть — это tech lead).

Под управленческую роль тимлида попадают такие обязанности, как собственно менеджмент, распределение и делегирование задач, всевозможные оценки и составление рабочего графика, контроль состояния проекта, а также митинги, коммуникации с заказчиком, руководством и всеми членами команды (разработчиками, архитекторами, тестировщиками, менеджерами).

Под техническую роль: участие в написании технической документации, выбор технологий для проекта, разработка архитектуры, R&D, code review, менторинг джуниоров, проведение технических собеседований, грамотное вовлечение новых членов команды в рабочий процесс, ответственность за техническую часть проекта.

Типичный рабочий день тимлида включает в себя:· рассмотрение новых задач и их распределение· стендап с командой· митинги· программирование· архитектурные вопросы· code review

Достоинства и недостатки

Достоинства должности в основном связывают с приобретением административных навыков. На позиции тимлида специалист учится эффективно общаться с людьми, управлять конфликтами, строить здоровую атмосферу внутри команды.

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

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

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

Как стать тимлидом и куда идти дальше?

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

Ключевые качества: трудолюбие, ответственность, проактивность, общительность, пунктуальность.

Перспективы карьерного развития тимлида имеют 2 направления: в архитекторы или в ПMы. Соответственно, на этом этапе специалист должен окончательно определиться, куда он хочет дальше — в углубление технической стороны или же в менеджмент.

Если говорить о конкретных цифрах, то среди 1822 бывших украинских тимлидов база данных LinkedIn находит 852 проектных менеджеров и 346 системных архитекторов.

P.S. Отдельное спасибо за помощь в написание статьи 8 украинским тимлидам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU

До обраного В обраному 4

Embedded-разработчик занимается разработкой встроенного ПО. По данным DOU, среднему украинскому Embedded-разработчику 30 лет, он получает $880 на уровне Junior, $1750 на уровне Middle и $3500 на уровне Senior. Зарплата тим- и техлидов — около $4200. 61

В этой статье рассмотрим, за что отвечает AdOps-инженер, какие есть преимущества и недостатки у этого направления и какой карьерный путь нужно пройти, чтобы занять эту должность. 2

Представляем новую статью из цикла «Карьера в IT». Она посвящена должности DevOps engineer — такие специалисты работают на стыке областей разработки и системного администрирования, обеспечивая эффективность процесса поставки ПО. 76

DOU News #12

Суть тим лида (отбрасывая «лидов», которые получили титул за выслугу лет или просто потому, что умненькие) — это то, что раньше ты отвечал за себя-хорошего, и всех интересовали ТВОИ личные знания и навыки. А тут резко речь начинает идти не о тебе, а о твоей команде. И судить о тебе будут по результатам команды, а не твоим собственным. Как твои люди работают, какой у них перформанс, какая квалификация и т.д. И что ты «торчишь» уже не за себя, а за других людей, которые тебе могут даже не нравится, но все равно ты за них отвечаешь. И процесс ты им должен ставить, и отношение к работе прививать, и за лажу бить по рукам. Быть просто «умненьким» тут недостаточно. Нужно быть лидером, иметь свое мнение и уметь это мнение доводить до других (а зачастую — навязывать). Уметь коммуницировать в команде и с заказчиком за всю команду. Уметь брать на себя ответственность. И при этом быть экспертом в технической области, авторитетом для членов команды.Это совсем не просто, если по-честному, а не «за выслугу лет». И именно поэтому тим-лиды получают лучше «чистых» менеджеров аналогичного ранга.

У кого-то был опыт ухода с пути менеджера на тех путь обратно, например с Engineering manager, VP, CTO, Head, Director назад в Tech Lead, Staff, Principal, Architect?Очень было бы интересно узнать подробности.

Я бы сюда добавил еще ведение хронологии проекта, учет времени, и различных аспектов, таких как почта, документы, изменения требований, для своевременного донесения информации о возможных изменениях сроков поставки пректа, либо улики, аргументы и защиту в случаях когда сьеден бюджет и пошла охота на ведьм. Чтобы суметь защитить и себя и свою команду в случаях когда сроки сорваны(перенесены) не по причине разработчиков.

Суть тим лида (отбрасывая «лидов», которые получили титул за выслугу лет или просто потому, что умненькие) — это то, что раньше ты отвечал за себя-хорошего, и всех интересовали ТВОИ личные знания и навыки. А тут резко речь начинает идти не о тебе, а о твоей команде. И судить о тебе будут по результатам команды, а не твоим собственным. Как твои люди работают, какой у них перформанс, какая квалификация и т.д. И что ты «торчишь» уже не за себя, а за других людей, которые тебе могут даже не нравится, но все равно ты за них отвечаешь. И процесс ты им должен ставить, и отношение к работе прививать, и за лажу бить по рукам. Быть просто «умненьким» тут недостаточно. Нужно быть лидером, иметь свое мнение и уметь это мнение доводить до других (а зачастую — навязывать). Уметь коммуницировать в команде и с заказчиком за всю команду. Уметь брать на себя ответственность. И при этом быть экспертом в технической области, авторитетом для членов команды.Это совсем не просто, если по-честному, а не «за выслугу лет». И именно поэтому тим-лиды получают лучше «чистых» менеджеров аналогичного ранга.

А кто сказал, что лид — это просто и весело?Он и есть насяльника, мы же не в песочке играем и не в квест бегаем. Ему за это как бы деньги платят ;-),

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

Есть два типа (здесь: утрируем) амбициозных джунов. Первый — нереально крутые и умные и хотят что-то делать. Вторые — нереально крутые и умные и хотят делать только то, что хотят. Вторые очень быстро учаться «именно навязыванию прессингу потому как сраки и планы» — что выливается в умение лизать зад кому надо когда надо и как надо. И плевать на архитектуру и цели — главная цель именно зад и продвижение собственного. Первые — быстро учатся понимать что к чему, когда им говоришь что к чему. Они сразу же начинают это применять и разбираются сами как было и как надо сделать чтобы стало как надо. По этому признаку их очень легко различать — причем на любой стадии развития и любом уровне карьерной лестницы: первые ищут возможность, как решить задачу — свою, компании, другого джуна, соседа с неработающим ноутом — не важно. И еще они ищут задачи, которые нужно решать. И находят. Вторые — ищут любую причину, чтобы задачи не решать. Тут руководство не одобрило, тут человека нет, тут «а нужно это вам?» — тысячи умелых отговорок. И тянучка. И еще они придумывают задачи. Которые, якобы, надо решать. Причем на вопрос «А зачем?» ответ один: «Надо! Я так решил! Они так решили! Кто-то так решил, а нам теперь надо.» Они никогда не ищут «Почему так надо?» Или «Почему так работает?» Это именно те самые «прогнутые на лесенке к мидлу джуны». Это два очень характерных и очень легко определимых типа людей — в любой организации, за пределами ИТ то же самое.

Важно понимать: есть люди, которым можно передать понимание. Этим — достаточно просто дать именно понимание, их не надо гнуть и ломать. Если не умеете дать понимание — вы не на своем месте. Эти люди хорошо видны. А есть люди, которые не понимают. Эти точно так же хорошо видны. И нам с ними не по пути — от таких лучше избавляться на всех этапах от джуна до архитектора. Другой вопрос, что при встрече таких людей уже на ролях «я — насяльника!» — а на этих ролях они также обязательно встречаются. Здесь уже надо решать, вести с ними дело или нет. Но это уже совсем другая история.

А «вдохновлять и мотивировать» всех надо. Просто мотивация — у всех разная. Точнее, здесь рассмотрены две самые основные группы. Каждому своё. (к)

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

Результат нужен везде. И везде же любая компания изнутри — люди, а не роботы.