Проблемы есть во многих компаниях, часто люди допускают ошибки. Именно общение с ними сподвигло меня на написание статьи. В ближайшем времени, я постараюсь продолжить публикации. Надеюсь, они будут полезны TL, CTO, руководителям департаментов или тем, кто только собирается ими стать. А начну я с рассказа о том, что такое быть Team Leader, это будет взгляд изнутри.
Тут сразу стоит сделать отступление. Есть разные компании:
- крупные, где обычно IT — основной профиль деятельности. В иерархии есть CTO, Tech Leader, Team Leader, Architects, Project Manager, Analyst. В таких условиях TL возможно не выполняет некоторых функций, которые я буду описывать ниже;
- бизнесы, где лишь часть компании завязана на IT. Там структура в половину проще первого варианта;
- небольшие фирмы с маленьким IT-отделом из нескольких человек (в моём случае нас было трое). Там просто не на кого переложить все обязанности. Иногда стоит задача вырастить такую контору в компанию из первого пункта списка.
Таким образом, объём и спектр обязанностей TL во многом зависит от размера компании или IT-отдела. Чем крупнее компания и сложнее структура IT в ней, тем меньше обязанностей у TL.
Как становятся Team Leader
Есть два стандартных пути к позиции TL:
- Карьерное развитие программиста на текущем месте работы. Например, когда вы проявляете много инициативы, усердно работаете, вы ответственный, показываете, что у вас есть лидерские качества и т.д. Или вас переводят на освободившееся место, когда по каким-то причинам не хотят приглашать человека со стороны. В этом случае смотрят на заслуги и нередко просто выбирают самого сильного технического специалиста. То есть вас туда выносит течение, а не стремление.
- Вы меняете работу и приходите в новую компанию на место TL. Так бывает, когда у специалиста за плечами много лет опыта и желания развиваться дальше, но рост в существующей компании по каким-то причинам невозможен и сложен. В итоге вы находите компанию, в которой считают, что вы справитесь.
Какой бы путь вас ни привёл к новой должности, но теперь вы будете меньше кодить и управлять людьми.
Перемены в деятельности
Итак, что нового появится в вашей жизни с того момента, как вы превратились из разработчика в TL? Несомненно, вы будете больше участвовать в обсуждениях и присутствовать на совещаниях. Зато вы сможете не тратить время на рутинные задачи, а делегировать их коллегам. Также придётся больше заниматься code review. Возможно на вас упадут договора и выставления счетов в бухгалтерию. Вроде бы жизнь удалась, и вы добились цели.
Но эйфория проходит довольно быстро, и вы практически начинаете гореть. Происходит примерно следующее: поток задач нескончаем, их надо решать или делегировать, следить, что пишет команда. Надоедливые менеджеры всё время что-то хотят и постоянно зовут на совещания. «Им заняться что ли больше нечем?» — думаете вы. Начальство же жмёт со сроками, а из команды внезапно ушёл человек, и искать замену вам. Ещё и жена звонит. В общем, вы становитесь раздражительным и близки к перегоранию. В таком режиме реально прожить максимум год.
Как выжить в таком аду? Как остальные справляются? Основная проблема в выходе из зоны комфорта. Вы в новом мире, старые правила не действуют. Конечно, выход есть, но найти надо его надо самому, в каком-то смысле сломать себя и осознать кое-что новое.
Что надо понять
Есть несколько вещей, которые надо осознать. И чем раньше вы это сделаете, тем лучше и легче вам станет жить.
- Вам платят деньги не за то, что вы пишите код. Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше. Ваша основная задача — создать такие условия, чтобы команда была наиболее эффективна. Программист должен писать код, а всё остальное — ваши заботы.
- Теперь ваши коллеги пишут код лучше вас. Пройдёт полгода-год, и отсутствие практики скажется на ваших способностях. Ведь они это делают практически всё рабочее время, а вы от случая к случаю или дома по вечерам.
- Перестаньте людей равнять на себя. Человек так устроен, что думает, что лучше него решить задачу никто не сможет. Во-первых, это не всегда так, а во-вторых, если вы будете тратить время на решение всех задач, потому что думаете, что люди не справятся, это уже не TL. Доверяйте людям.
- Ваши главные показатели эффективности — качество всего проекта и время разработки. Здесь, пожалуй, главную роль играют ваши навыки коммуникабельности. Что-то надо делать качественно и долго, а иной раз целесообразнее быстрое решение. Сложность состоит в том, что вы должны донести это до программиста и убедить его сделать, как нужно в этот момент. А не через 2 дня обнаружить, что он только на середине, а готовое решение нужно сейчас.
- Мотивируйте людей. Придумайте систему мотиваций, чтобы всем хотелось лучше работать. Выдать премии, если не было аврала? Нет, это ерунда. Внедряйте метрики, собирайте статистику, оценивайте работу людей. Также следите за профессиональным ростом сотрудников, кто как развивается. Всегда держите руку на пульсе.
- Вам нужно нанимать людей. Хорошо, если у вас есть отдел кадров, который умеет нанимать IT-специалистов. Если нет — у вас появились дополнительные обязанности. Учитесь составлять вакансии, отбирать специалистов, проводить собеседования, увольнять. И если у вас не стартап с космическими инвестициями, готовьтесь находить людей в бюджете ниже рынка. Возможно даже придётся самому обзванивать кандидатов.
- Вы отвечаете за весь проект. Если ваш сервис вдруг упал надолго или его невозможно восстановить, потому что нет бэкапов, перед руководством всегда будете виноваты вы. Работоспособность проекта в техническом плане — ваша обязанность.
- Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.
- Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.
- Вы должны уметь подменять любого члена команды. Если кто-то заболел, ушёл в отпуск или уволился, и процесс разработки остановился, вся ответственность ложится на вас. Будьте готовы к этому всегда.
- Психологический аспект. Вам необходимо общаться с командой и понимать людей, знать, какие у них могут быть проблемы, и даже помогать решать их. Большая часть программистов — интроверты, вы должны пытаться выяснять, что их не устраивает или мешает на работе. Конечно, большинство и не скажет этого, вам надо научиться это понимать. Но главное не перегибать палку и не становиться психологом вместо начальника, а то это плохо кончается.
Одни минусы. Есть ли плюсы?
Да! И их намного больше минусов. Теперь у вас есть ресурсы, которыми вы управляете. А значит у вас больше средств для достижения результата, то есть решения задач бизнеса. Именно этого он от вас и ждёт.
Я бы сделал сравнение с футбольной командой. Вы как молодой тренер команды, у каждого игрока есть свои сильные и слабые стороны. Если вы будете управлять ими без учёта особенностей каждого, то вряд ли что-то сможете выиграть. Но став настоящим лидером команды, вы должны суметь превратить слабые стороны ваших коллег в сильные ради победы.
Вы можете нанимать не очень опытных людей, но за полгода превращать их в крутых специалистов, которые будут тянуть проект вверх. Помните, что у вас в арсенале есть крутые подходы, например, Scrum или Kanban, которые могут обратить мучительную разработку в хорошо отлаженный процесс для всех его участников.
Также вам открывается огромное поле для экспериментов. У вас появляются ресурсы для поиска и проб новых решений. Это надо делать обязательно, что-то сработает и принесёт успех. Ищите пути, которые будут полезны и команде, и бизнесу. Серебряной пули нет, вам придётся найти своё решение, которое будет работать в конкретных условиях.
Используйте опыт и стройте эффективные системы отбора сотрудников. Также мотивируйте и развивайте команду. И не забывайте о развитии себя: читайте книги, слушайте лекции, ходите на конференции. В конце концов просто общайтесь с людьми и делитесь опытом. В итоге вы построите сильнейшую dream team.
Если ещё не поняли, то со временем осознаете, что самый важный ресурс — это люди. Оставайтесь с ними коллегами, а не начальником и подчинёнными. Будьте единым механизмом, помогайте им, а они будут помогать вам.
Team Leader — это не суперпрограммист, это лидер, который может из любых ресурсов, несмотря ни на что, собрать крутую команду и принести прибыль компании. Вот чем эта работа по-настоящему классная.
Лично для меня высшая похвала, когда приходят люди и говорят: «Ни фига себе какой вы сервис запилили! Ещё и с такой маленькой командой!». После этого ты понимаешь, что всё было не зря. И это даёт сил делать проект ещё лучше. Так сказать, выиграть с ребятами свой чемпионат.
Для тех, кто уже завтра идёт на собеседование
Стоит рассказать и о вакансиях на позицию TL. Как я и писал выше, компании бывают разные, в них разные задачи. На собеседовании попытайтесь понять, кто всё-таки нужен работодателю, чтобы ваши ожидания совпали с реальностью. Особенно смешно, когда в компании нет чёткой иерархии, и всё должно висеть на одном человеке. Обычно в их вакансиях есть фраза: «Придётся программировать 70–80% времени. Я бы советовал избегать таких предложений. Либо на вас хотят сэкономить, либо руководство вообще не понимает зачем им нужен TL. Конечно, каждый случай индивидуален, но всё же есть грани разумного. В конечном итоге человек перегорит и уйдёт, так как жить в стрессе всё время нельзя.
Подходите к выбору места с пониманием того, что хотите получить. Помните, что собеседование проводят не только с вами, но и вы с компанией. Не стесняйтесь и задавайте вопросы, выясняйте всё. Лучше узнать всё заранее, чем потом оказаться в бездне. Можно даже попросить познакомиться с командой, послушать, что говорит ваш будущий коллектив. Цена ошибки высока: неправильное место может отбить всю охоту развиваться дальше и не даст попасть в этот удивительный мир.
Выводы
Выбор стать TL должен быть осознанным решением, а не просто, потому что вам надоело писать код или хотите зарплату повыше. TL — это первая ступенька в IT-менеджменте. На этом этапе можно понять, нравится вам это или нет. И если нет, то всегда можно вернуться в разработчики. Но учтите, если вы долго проработаете TL, то уйти назад может быть сложно. TL не так много пишет код, мир вместе с технологиями сильно меняется, опыт теряется. Может получиться, что вы вернётесь назад, и придётся долго навёрстывать упущенное.
Безусловно это очень интересная работа. Вам придётся сломать своё мышление и начать думать по-новому. И, конечно, покинуть зону комфорта. Но зато вы получите бесценный опыт управления, сможете строить команды и добиваться результатов для компании.
Всё описанное выше приходит с опытом. Учебники и курсы не научат вас быть TL. Но зато смогут помочь обойти немалое количество граблей.
P.S.: Спасибо, что уделили время! Прошу строго не судить, это моя первая статья на хабре. Надеюсь, она окажется кому-то полезной. Я постарался передать свой личный опыт. Буду признателен за любые мнения. Но это лишь начало, дальше я хочу углубится в детали процессов разработки и управления командой и рассказать, как я их выстраивал.
Комментарии (24)
mst_72
01.04.2019 14:28Опять статья про нетехнического проектного менеджера (PM) чьи недостатки компенсируются прокачанным лидром команды (Team Lead), по факту выполняющим функции технического менеджера проекта?
nicholas_k
01.04.2019 19:11Так ведь ситуация весьма частая, особенно для небольших компаний. Часто при хорошем тимлиде менеджера проектов вообще не привлекают, тем самым экономя деньги. Правда тимлид потом долго лечит нервы.
Поэтому надо сто раз подумать, прежде чем идти в небольшую компанию. Как минимум четко оговорить круг обязанностей и уточнить, кто будет исполнять функции ПМ.tyronead Автор
01.04.2019 21:08Я могу признаться, что так оно и есть. И когда я туда пришел, там по факту ничего не было и пришлось все разгребать самому. Был стартап-проект, и первое время не было денег. И фактически ты человек-оркестр. Но мне кажется, это бесценный опыт, главное чтобы такой опыт был не первый и ты понимал, что делаешь и зачем. А то может быть крах. Конечно, надо понимать, на что ты идешь.
rpiontik
01.04.2019 19:17+3Team Lead, как и любая роль — формальность. Функции, обязанности и ключевые факторы успеха определяются текущими потребностями бизнеса и уровня его развития.
Я за свою карьеру был и CTO и CIO, и CEO и т.д. и т.п. и вот, сейчас TL. Так вот, лично мое мнение, что TL это не функциональная должность, а скорее избирательная. В прямом смысле, эту роль нужно заслужить у своей команды. Как, почему, рассуждать можно долго.
Лично для меня наиболее комфортна роль TL. Потому, что только тут я могу говорить с командой не с позиции руководителя, а равного. Спорить о коде, об архитектуре. Развиваться в технологиях. Именно этого ты лишаешься с уходом в менеджмент.
kznalp
02.04.2019 11:19Зато вы сможете не тратить время на рутинные задачи, а делегировать их коллегам.
— или другими словами говоря — «перекладывать ответственность»
zzzmmtt
03.04.2019 11:37Делегировать задачи не всегда равно делегировать ответственность, но может совпадать, но тогда получается плохой тимлид, раз за свои решения он не несет ответственность в полной мере.
Exponent
03.04.2019 14:22"… собрать крутую команду и принести прибыль компании.." — а если компания жадная и прибылью делиться не хочет? Т.е. ни увеличения зарплаты, ни премий, ни каких либо других перспектив? На вопросы о повышении зарплаты тебе отвечают: ты и так берешь максимум?
akdes
03.04.2019 14:37можно сесть в углу и плакать.
Я не считаю, что прибыль компании имеет отношение к зарплате работника, если это не предусмотрено контрактом. Человек был нанят для исполнения определенного плана работ, которые должны привести к прибыли — иначе компания долго не протянет.
Другое дело, моменты прибыли для компании, благодаря работе сотрудника, можно попробовать монетизировать при следующем разговоре о повышении. И если вклад был высок, то компания скорее всего будет заинтересованна в мотивации сотрудника.
Представьте Вы берёте машину в аренду, а Вам через какое то время присылают счёт, с объяснением: за год машина ни разу не сломалась и проехала 1000 км. В связи с этим оплатите пожалуйста доп. x.000 рубExponent
03.04.2019 15:07Насчет контракта все понятно. Но вот ситуация, запуск нового проекта, предыдущая команда бросила важный подпроект и сбежала. Вы беретесь доделываете и запускате это подпроект. Т.е. вклад можно сказать был высок, т.к. иначе вся система бы не заработала. Затем работодатель нанимает другую фирму, которая переписывает сделанный вами подпроект один к одному, т.е. не добавляя никакого ноу-хау и берет за это в 100 раз больше денег. Как относиться к компании после такого?
akdes
03.04.2019 15:26Если всё именно так, как Вы расписали, ситуация не очень.
Однако ход Вашей компании к фирме с вложением «в 100 раз больше» должно иметь какое то объяснение. Возможно в Вас сомневаются? Тогда и нежелание платит Вам больше — понятно.
Какая бы причина ни была — недоверие к Вам или «рыба гниёт с головы» — выход тут только один: искать другое место. ИмхоExponent
03.04.2019 15:28Да, я уже ищу. Заодно подгоняю упущенные технологии. Причина скорее всего в коррупции, так легче украсть деньги если договориться с внешней фирмой.
akdes
03.04.2019 15:37Ну если причина в коррупции, возможно стоит побороться? Пойти в обход этого руководителя, выше и поставить это вложение под вопрос, официально.
Смена компании тоже не самый лёгкий этап… я бы взвесил.
tyronead Автор
03.04.2019 15:27Из моего личного опыта. Да, повышение ЗП сотрудников было не потому что они хотели, а за реальный вклад (заслуги) в проект. Переговоры с начальством о повышении зарплаты давались нелегко, порой затягивались до 4 месяцев. Но мое личное мнение, что это задача руководителя объяснить, почему сотрудник действительно стоит этого и что он делал для компании.
Понятно, что если денег нет, повысить ЗП никто не сможет. А если компания жадная, насколько она будет успешна, если от нее уходят ценные кадры?
Есть еще один аспект, я даже читал исследования hr-агетнств. Что многие компании иногда держат сотрудников и повышают им зарплаты, просто потому что найти нового будет в 5-6 раз дороже, чем сохранить старого. Но это был не мой случай =)akdes
03.04.2019 15:32Согласен с Вами, однако с повышением нужно быть очень аккуратным. Отсюда появляются люди, думающие что они стоят 100k, когда другие люди делающие туже работу и возможно делают её ещё лучше, получают 50к.
И потом, этот человек запросит 150к, и не получив их, он будет искать того, кто заплатит. Или просто будет лишён мотивации…
Один из сценариев развития…
Exponent
03.04.2019 15:44Самый лучший способ поднять зарплату, это поменять работу, не раз убеждался.
Durimar123
03.04.2019 17:02Автор описал желание менеджеров переложить ответственность с себя на единую персону ТЛ, и желательно без доступа этой персоны к финансам.
Мифический ТЛ все знает, все умеет и за все отвечает. Разве только чашки за всеми не моет, но думаю в некоторых конторах есть и такие опции.
kznalp
04.04.2019 21:33-1Кстати, из личного опыта.
Я за более чем 20-ти летний жизненный опыт встретил только одного Team Leader, который был именно лидер. Может быть, потому, что он был альпинистом.
Все остальные кого встречал и встречая — просто менеджеры, со всеми вытекающими последствиями.
И еще от лица, простого инженера: взаимоотношения инженер-менеджер это самая яркая иллюстрация одного из основных философских законов — единства и борьбы противоположностей.
musuk
А в чём разница между Team Lead'ом и Tech Lead'ом?
Ravager
тимлид отвечает за всю команду. чем ей заниматься, куда расти. делает так, чтобы команда выполняла свои задачи максимально эффективным образом без ущерба для самих разработчиков. к нему же приходят всякие внешние заказчики т.е. это интерфейс команды.
техлид отвечает за сервисы, их архитектуру и т.д.
часто тимлид и техлид это одно лицо.
musuk
А чем он от PM отличается?
Чем он от архитектора отличается?
tendium
Не претендую на истину в последней инстанции, однако предположу, что отличие роли Архитектора от роли Тех.Лида в том, что первый концентрируется на big picture, тогда как последний фокусируется только на своем проекте. По сути архитектор отвечает за взаимодействие проектов, тогда как тех.лид отвечает только за функционирование своего проекта. Плюс архитектор может определять стандарты и подходы, общие для разных команд, а тех.лид их может уточнять и дополнять в рамках специфики своего проекта.
Все это однако имеет смысл только если компания имеет несколько проектов и команд разработчиков. В противном случае роль архитектора вполне себе наполнима
тех.лидом.
На моем примере: в предыдущей компании у нас была небольшая команда разработчиков и один проект, поэтому роль архитектора отсутствовала. В компании, куда я перехожу, несколько проектов и команд разработчиков, и там не так давно завели роль архитектора.