Comments 12
Вы не перепутали: ведущий разработчик, тимлид, получает меньше, чем синьор
Я правильно читаю график? В 90+ процентиле вакансий на хабр карьере у сеньоров зарплата больше $280k/yr? Есть ссылка с фильтром посмотреть вакансии? Кажется, что какие-то статистические выбросы попали в выборку. Может быть часть вакансий подразумевали как раз годовую оплату, но на количество месяцев в году не делили эту сумму и так вписали в помесячную.
О, император — это что-то новенькое, плюсик хотя бы за нескучную терминологию.
Вообще в российских компаниях процветает какое-то извращенное применение слова тимлид. Часто так называют чистого менеджера, руководителя целого направления или подразделения с десятками сотрудников. Наверно, потому что начальники боятся слова “руководитель” в штатном расписании. При этом, разработчиков, в обязанности которых входит менеджмент небольшой команды называют просто сениорами.
Статистика по зарплате эту странность иллюстрирует. На лида компании хотят просто менеджера, а на сениора менеджера и эксперта в одном лице. Вот и приходится ребятам, как вы говорите, дауншифтиться чтобы получить наилучшее соотношение затраченных сил к зарплате.
Тимлиды не могут нормально погрузиться в архитектуру и дизайн.
В хорошо организованной компании у тимлида команда не больше чем на 5 человек. В таких условиях он может и обязан погружаться в архитектуру и дизайн. Иначе зачем он вообще нужен?
Тимлид команды разработки это — бригадир, младший менеджер, которой понимает все нюансы работы своей команды, может перевести их на другой уровень управленческой абстракции, и обратно.
Можно, конечно, сказать, что есть тимлид тимлидов — сотрудник у которого в зоне ответственности руководство сразу несколькими командами(бригадами). Но зачем? Его можно просто назвать руководителем.
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Да, я как раз об этом говорю. Вы рисуете образ менеджера, который должен заниматься организацией всего рабочего процесса и только людьми. Но это не так. Даже если мы говорим про тимлида продуктовой, а не функциональной команды, тимлид — это в первую очередь исполнитель, технарь, а потом уже менеджер.
Рассуждения тут логические. Кто может убедится в адекватности принятых технических решений? Оперативно, а не стратегически. Тот, кто разбирается в этих технологиях в контексте текущей ситуации. Менеджер гуманитарий не может физически вам собрать компоненты для релиза, верифицировать оценки, или понять в кого перенаправлять техническую проблему. Только тимлид.
Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям. Из ваших примеров:
разобраться с грустью у Пети: PeopleOps
объяснить основы secure coding Жене: ментор
поговорить с суппортом про текущие проблемы: бизнес аналитики и PO
договориться о ресурсах инфраструктуры на тестирование: QA и DevOps инженеры
сделать статусную презентацию: PO, техпис, продуктовый дизайнер
Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Нет, такая ситуация у нас, потому что технический директор снеки покупает, тимлид презентацию рисует, а начальники придумывают всяких императоров, лишь бы не разбираться в вопросах организации, управления и руководства.
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Зачем дауншифтить понятно, а зачем идти в лиды? Из статьи вырисовывается что лучше идти в техлиды и архитекторы, чем в лиды.
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
Тимлид без команды, это то же самое как тимлид с командой, только без команды.
Привет! В статье спутаны роли с должностями и их обязанностями - есть некоторое количество фактических ошибок и додумок.
Для начала требуется осознать, что каждой должности соответствует свой уровень обязанностей (так и называется "должностные обязанности" - те задачи, ту работу и те решения, которые должен выполнять / принимать сотрудник на своем уровне в своей роли).. Соответственно, решение о повышении, по хорошему, должно приниматься при выполнении условий:
Сотрудник выполняет более 80% задач / работ самостоятельно (т.е. без привлечения "старших коллег". Количество задач - стандартное).
Сотрудник хочет развиваться дальше, обязанности уровнем выше - интересны ему.
Сотрудник приобретает новые знания, навыки и опыт согласно своему плану развития (к слову, наличие плана развития сотрудников - это важная часть обязанностей менеджера).
Второе, с чем стоит разобраться, это различии в ролях Тимлид и менеджер. Тимлид можно перевести как "ведущий X" или "Лидер команды X".
В случае "ведущий X", то это инженерная должность, означающая, что сотрудник очень хорошо выполняет повышенный объем задач, и хочется ему платить больше вознаграждения. В этом случае, действительно, ему не нужна команда, т.к. он не занимается ее управлением.
В случае же, если Тимлид - это ступень на пути к роли менеджера, то обязанности у такого сотрудника должны быть:
Постановка задач. Планирование выполнения необходимых работ.
Контроль выполнения задач. (Это операция комплиментарная планированию).
К слову у Менеджера концептуально обязанности следующие:
Планирование выполнения работ, необходимых для достижения результата (для команды. Постановка задач, понятных исполнителю).
Контроль выполнения поставленных задач. Исполнение планов.
Обеспечивать и организовывать работы (т.е. сотрудники должны иметь все необходимое для выполнения работы. В т.ч. у сотрудников должен быть план развития).
Мотивировать сотрудников (хороший Менеджер - это формальный и, желательно, неформальный лидер команды. Должен использовать различные методы мотивации сотрудников).
Как видно, Тимлид выполняет 2 пункта из 4х менеджерских пунктов.
Ключевые навыки менеджера это:
Хард-скиллс: навыки и опыт в планировании, постановки задач, методов контроля, развития, мотивации и тп. Задачи можно ставить по разному, можно каждый день проводить DailyScrum, мотивировать можно путем определения уровня потребностей сотрудника (по Маслоу, например) и т.д.
Софт-скиллс: это навыки межличностного общения, такие как эмпатия, эмоциональный интеллект, навыки фасилитации и тп. Хороший руководитель - это формальный и неформальный лидер команды.
Бизнес-скиллс: менеджер - это агент компании, которому делегировали частичку бизнеса. Т.е. менеджер понимает ценность и миссию компании и старается делать то, что нужно для развития команды.
В статье, кстати, указана классическая проблема для менеджеров. Ими (менеджерами) становятся по "воле случая", т.е. путем рукопожатия от руководства и поздравлением. что теперь ты менеджер. IMHO, помимо желания - нужно еще обучить будущего менеджера быть хорошим менеджером :)
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Тимлид без команды — всё ещё тимлид? Или уже нет?