Комментарии 21
Помните, что вы не выкидываете человека с обрыва, а расстаетесь, потому мэтча с командой или проектом не случилось.
мне довелось увольнять двух человек и это выглядело как кидание с обрыва, из-за которых меня до сих пор чтото грызет внутри, но их реально нельзя было оставлять конечно
Одного мы увольняли 20 декабря(у него истекал испытательный срок 22 декабря), т.е. работу он будет искать уже в конце января, а у человека ипотека, толпа детей и спорные хардскиллы, а он забил на риски вылетить...да конечно он прорвётся, но это было свинство с человеческой точки зрения ...тут какбы стрельнули его риски, но ощущение что человеку запороли новый год ошибками в процессах (тут не моя вина, в полной мере, меня поставили на проект за две недели до этого и тупо поставили перед фактом - а оцени Васяна, чёто у него плохо идет, а то у него послезавтра испытательный срок заканчивается) не покидает меня
А второго...эммм..человек работал в Киеве и расставались мы с ним весной 22 года...и откровенно не тянул, а ситуация на проектах была такая что никто его с нуля из этой локации брать на новый проект не будет...а я помню как в том проекте у нас проходили созвоны в те времена...капец...
так что по всякому бывает, а мантру HR-ов что "мы тебя не увольняем, мы просто предлагаем вам расти дальше но в другой компании" ненавижу..
Карьерные показатели и способ работы HRов - примерно, как у паутины. Минимумом длины нити поймать максимум насекомых по совокупной жирности, и передать пауку. То, что он дальше с ними делает (съедает и выплевывает, или держит в заложниках, и использует потихоньку) - их уже не волнует. Поэтому надеяться на искренность соболезнований в процессе - в большинстве случаев наивно.
По поводу тех, кто работает с людьми - важно выполнять роль озонового слоя, создавая под зонтиком более подходящие для жизни условия, чем над ним. Это довольно широкое понятие, включающее защиту команды от токсичности сверху, демпфирование неровных графиков работы из-за личных обстоятельств, рисков по срокам и по скоупу итд. То есть нужно прикрывать своих, как если бы это были ваши дети, а не проводить 1:1 и тем более не усиливать внешние управленческие сигналы. Условно - дома своего пацана можно выпороть за разбитое из рогатки стекло в школе, но на родительском собрании вы должны быть его адвокатом.
Я тоже не прошел испыт. срок под новый год, и причем была середина испыт. срока, а не конец. Могу сказать, что это было свинством со стороны директора. След работу нашел в конце февраля, благо кредитов не было.
Хорошая статья, но вот это я не понял
Тимлиды-менеджеры. Специалист заканчивает MBA или другое менеджерское направление, получает высшее образование или повышение квалификации и становится менеджером над разработчиками. Раньше я не верил в такой подход, потому что казалось: если ты не понимаешь проблему на низком уровне, то не сможешь решить ее, будучи лидом. Но сейчас вижу, что такой подход работает.
Как так то? Поясню
Как чего чем управлять не имея устойчивых скилов разраба я представляю отлично, так как сам это делаю каждый день. Но я архитектор. Т.е. я еще меньше беру в руки инструмент, чем лид.
Но лид для меня - как минимум очень сильный разраб, иначе - а на кой он вообще?
К примеру:
Надо выработать совместное техническое решение. Если тим. лид менеджер - ну да, можно постоять "над дискуссией" и все такое - но кто-то должен генерить идеи, оценивать их на основании опыта (а не так, чтобы команда его получила по ходу дела)
Надо делать код ревью. Опять же, я, особенно на последнем проекте, где мы переписываем легаси - хожу туда каждый день. И вижу разные косяки. Но видеть косяки в старом коде (да и в новом иногда) - это не то, что делать ревью, где надо обеспечить его качество (а не найти 2 из 5 косяков)
Остальное - да, у лида много менеджерских функций, но ...
Я встречал людей, которые могли без знания программирования лидировать команду разработчиков. Это были управленцы, и у них был очень хорошо развит скилл проектирования, как у системного аналитика. А проблема с ревью решалась через кроссревью разработчиков но, конечно, эффективнее развивать лидерские качества у сильного программиста.
Так это банальные ПМы. Их в каждой организации до фига :) Другое дело, кто-то на себя должен взять техническую часть
Еще один пример - технический дизайн. Кто?
Я работал аналитиком в одной команде. Там начальник отдела не был аналитиком. Он выполнял менеджерскую роль - ставил и отслеживал KPI, отчитывался перед руководством и так далее. Никаких ревью он не проводил. В команде были ведущие аналитики, они поддерживали, если возникали проблемы. И знаете, это очень сильно помогает развиваться. Когда ты знаешь, что нет никого сверху, кто проверит твое домашнее задание и укажет на ошибки.
И знаете, это очень сильно помогает развиваться. Когда ты знаешь, что
нет никого сверху, кто проверит твое домашнее задание и укажет на
ошибки.
и да и нет одновременно
мне тут досталось четыре проекта которые несколько лет делал человек с таким подходом....я конечно преклоняюсь перед такими людьми он реально сделал титаническую работу, с нуля писал и поддерживал четые проекта такого масштаба что там нужно было как минимум двое на каждый.... но там блин такое....иногда гляжу в этот код и одна мысль "зощто!!?? почемуу?? зачем так??" там блин такая дичь попадается что уши в трубочку заворачиваются...человек видимо в рамках саморазвития умудрился наваять собственный оркестратор докера в рамках проекта по моделированию производства....тысячи строк кода управления контейнерами, пререзапуска, ha, управлению сетями....*опа какаято...сотни человекочасов в помойку...
Большой вопрос, а есть ли в этом выгода. Количество головной боли растёт ощутимо, но доход, как ни посмотрю в вакансиях, не видел, чтобы сильно отличался от сеньерского. Сколько в норме за это должны доплачивать?
Я считаю, это оправдано. Тем более, если ты сам не специалист, а именно менеджер. За что тебе платить больше синьора ? Если ты не принимаешь каких-то весомых решений, которые влияют на ключевые метрики. Time to market, ФОТ, прибыль и многие другие.
Как раз таки тимлид-менеджер один из тех кто влияет на ттм фот и метрики, а вот сеньор это обычный линейный разработчик хоть и высокой квалификацией, он тупо пилит таски ... а тимлид это уже менеджмент хоть и самого первого уровня, без него сеньор и остальные погромисты ничего не сделают, просто напишут кучу кода и свалят в кучку
вообще это опять чтоли вечная история что начальство не нужно и рядовые работяги сами все сделают?
Могу сказать по себе что на тимлида попасть сильно проще чем на сеньора топового грейда, а зарплата такаяже или выше
По мне - тимлид, это самая тяжёлая ступенька в карьерном росте. Прошёл это дважды, и больше не хочу!
Управление рисками один из ключевых аспектов проджект-менеджмента. Не очень понимаю почему оно отдельно внизу пирамиды, а проджект-менеджмент вверху.
Спасибо за статью! Приятно, что человек с таким опытом разработки понимает, что это тимлидство - оно не прилагается автоматом к опыту, его нужно ещё и развивать. Сталкиваюсь с молодыми разрабами, у которых даже некий план в голове - пару лет покодить (успех не важен, качество или разнообразие опыта не важно), получить формально минимальный опыт и прорываться в тимлиды.
Компоненты пирамиды могут быть разными, зависимости от команды. Хард-скильные команды требуют минимум менеджмента. И наоборот - для управления толпой джунов более важны хард-скилы тимлида.
Я бы был лучшим увольняющим тимлидом. Вообще не понимаю в чем проблема подобрать слова типа давай останемся друзьями до свидания.
Повезло вам, что мне вообще не интересно управлять командами. А променять монотонную писанину уютную с чашкой чая/кофе/водой на делегирование и распределение задач... Я пришел интровертить в IT, а не управлять там кем-то.
Ну и просто напомню, что начальство часто радо разраба в менеджеры "повысить". Просто помните, что вам оно может вообще не надо и отказывайте либо вовсе увольняйтесь.
Путь евангелиста или архитектора - наше всё.
Быть или не быть тимлидом: разбираем на пальцах