Комментарии 40
Вопрос к иллюстрации: когда вы успели перейти с медведей на колобков? :)
Самая распространенная причина отказа в повышении — если тимлид в заявке не смог объяснить ценность конкретных выполненных кандидатом задач с точки зрения бизнеса.
А кто у вас задачи то выбирает? Сам разработчик что-ли придумывает? Или всё таки бизнес? А если бизнес, то почему этот бизнес не знает какую ценность эти задачи несут?
психологи называют это умным словом моральное стимулирование.
"А может, лучше деньгами?".
PS Эта фраза - из моей комсомольской юности. Конечно, к выводам всяких буржуазных наук тогда не прислушивались, но моральное стимулирование было хорошо изввестно и использовлось широко. Отношение людей - а мы были студентами, людьми умными - было к этому адекватное. И когда однажды у нас на местном собрании комсомольский босс начал втирать нам в уши очередную туфту про то, что мы там должны что-то сделать (не помню уже), а за это то ли грамоту дадут, то ли на Доску Почета поместят, один мой знакомый, там присутствующий сказал окржавшим его студентам эту самую фразу. Сказал он тихо, но босс услышал. Кароче, были тому студенту проблемы, но не фатальные - в деканате он был на хорошем счету, так что долг перед Родиной (а в те времена его запросто можно было отдать в Афгане, вместе с жизнью) ему отдавать не пришлось. Но фраза запомнилась.
Совка давно уж нет но его дух - как развести работников на работу забесплатно - гляжу, жив.
Обычно грейды взаимосвязаны с повышением зарплаты, и как раз вводятся для того, чтобы сотрудникам было прозрачно и понятно, как повысить уровень оплаты своего труда. Так что, думаю, такого нет, что просто вешается лычка senior-грейда без изменения уровня зарплаты. Иначе это было бы совсем уж странно.
"Моральное стимулирование" было про экспертов, которые оценивают потенциального сеньора.
Ну, я понимаю, что повышение грейда - это вполне честный процесс отбора тех работников, которые могут принести больше пользы предприятию, с целью навешивания на них дополнительных обязанностей, компенисруемы однако повышенной(обычно) зарплатой.
Но моральное стимулирование автор зачем-то упомянул.
В Лаборатории Касперского своя атмосфера, достаточно почитать более раннее творчество.
Не увидел в статье пункту про "в первую очередь тимлид должен знать есть ли у конторы бюджет на повышение ЗП ещё одному работнику". Иначе, если контора не готова платить больше, все эти танцы вокруг повышения бессмысленная трата времени.
В остальном, тимлид должен пытаться тянуть каждого своего разраба в сеньоры, вне зависимости от того, хочет разраб этого или нет. Во-первых и люди не заскучают, т.к. будет цель, а во вторых будут объективные причины ЗП повышать.
Разумеется, если при таких попытках встречается сильно сопротивление со стороны сотрудника, темп этого продвижения нужно снизить, чтоб не душить человека. Но развитие в этом направлении должно быть по умолчанию. Кто не развивается - тот деградирует.
И ещё одна проблема в том, что большинство тим лидов не умеют правильно расставлять приоритеты и делегировать, отсюда возникает нехватка времени на действительно важную часть работы лида - наблюдение за командой, понимание ее слабых мест и сильных мест, и выстраивание стратегии развития исходя из этого. В общем, на бумаге все красиво, а по уму все это реализовать смогут единицы.
Опять вода водой. Вот вы пишите, что нужно иметь прозрачный и понятный план, что нужно сделать, чтобы вырасти в грейде. А дальше пишите воду про понимание ценности для бизнеса, мотивацию и софт-скиллы. Что это значит? Даже джун может быть супер-мотивированным, иметь идеальные софт скиллы и даже понимать ценности бизнеса и зачем в конце концов он двигает такси в джире. Он уже может на этом основании стать сеньором?
Ладно, дальше получше - тимлид собирает список задач и проектов, которые сделал разработчик. А кто давал ему эти задачи и назначал на эти проекты? Наверное, не сам разработчик, особенно на уровне миддла. То есть если разработчик оказался на поддержке какого-то легаси, которое ещё никому и не нужно особо, то он не увидит повышение примерно никогда, потому что бизнесу он не принёс достаточно ценности.
А кто давал ему эти задачи и назначал на эти проекты? Наверное, не сам разработчик, особенно на уровне миддла.
Во, тоже хотел это спросить.
Привет.
В тексте есть важное упоминание, что разработчик должен успешно решать задачи, но просто решать задачи недостаточно чтобы стать старшим разработчиком.
Если мы смотрели бы на опыт MAANG-компаний, то разработчик на проектах, которые менее важны для бизнеса, не получил бы продвижения - факт. В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании. We live in society) Но и да мы активно промоутим людей с самых различных проектов.
В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании.
Что это значит?
По каким параметрам вы определите, есть понимание у кандидата или нет. Вот я условный разработчик, пишу какой-то внутренний сервис или продукт, он продается или помогает продавать другие продукты, чтобы принести деньги бизнесу. Я вам это сказал, вы сразу перевели меня в сеньоры? А если тоже самое скажет джун с 1 годом опыта, то он тоже пойдет в сеньоры?
Я могу понять оценку в количестве выполненных сторипоинтов или закрытых задач, в количестве МРов, которые проревьювил разработчик, в количестве разработчиков, которых он менторит. Я даже могу понять оценки в виде высокоуровневых и абстрактных задачах - мы слишком много денег тратим на поддержку клиентов; стоимость инфрастуктуры слишком большая; хотим, чтобы сейчас наш антивирус гнал трафик не по гигабайту в час от клиента, а в два раза меньше.
Тогда я могу прийти через полгода-год и сказать, вот, смотрите, тратили столько, стали на 30% меньше, я (наша команда) молодец. Или вот, раньше отвечали в поддержке в среднем в течении двух дней, а теперь в течении двух часов. Или даунтайм серверов обновления был 5% в год, стал 0.5%
А вот как мне доказать, что у меня за последний год стало больше какого-то мифического понимания, я не знаю.
Понимание смотрим на этапе ревью анкет, которая заполняется лидом и кандидатом на промоушн.
Если человек напишет, что вот мои артефакты, которыми я горжусь и в рамках их он опишет их output+outcome, то это и есть понимание.
Разработчик уровня миддла это не вольный охотник, который возвращается раз в год с докладом, что он придумал поделать, вы же сами давали ему конкретные задачи, если вы не выдали задач, которыми можно было бы гордиться или которые не были сильно полезны бизнесу, то получается разработчик вместо повышения будет сосать лапу?
И опять отмечу, что никаких конкретных критериев вы не озвучили (понимаю, что их нет и вы их сами не знаете и вам просто поручили написать статую в корпоративный блог) - например, мы ожидали, что разработчик сделает 30 сторипоинтов, а он сделал 20. Или наоборот, он сделал 50, поэтому он молодец и мы его повышаем
А кто тогда соглашается работать на проектах с которых не возможно продвижение? Зачем это делать? Опыта там никакого а боль и страдание как от задач так и от отсутствия какого либо роста гарантирована. Если у вас в касперском тоже так и нет возможности выбраться из этого то бедные ребята. Я сам работал в болоте в другой компании долгое время и не кому не пожелаю.
И как всегда самый простой и быстрый способ апнуться в сеньёры - это перейти в другую компанию, а не проходить смотрины в каком-то блат-комитете.
Согласен. Job hopping - один из самых понятных и быстрых способов в начале карьеры быстро забраться на синьера с отличной зарплатой.
Проблемы начинаются дальше. Например, у нас после синьера есть позиции ведущего разработчика, эксперта, старшего эксперта, ведущего эксперта и principal эксперта. Плюс есть возможность на этой карьерной лестнице сделать переход в менеджерскую ветку. Тут job hopping не помогает.
Мой личный опыт - 10 лет в компании. 5 лет от стажера до синьера и 5 лет на менеджерском треке. В целом очень рад, что не выбрал job hopping как карьерную стратегию
Давайте я из своего управленческого опыта скажу - все эти грейд-комитеты, ассесменты, промоушн-кампании и прочее - сделаны с одной целью: ЗАТОРМОЗИТЬ рост грейдов и зарплат в компании и сделать его более предсказуемым. Особенно - в сочетании с практикой: сначала покажите что вы уже достигли уровня, а потом мы вам его повысим.
Все эти комитеты и процедуры - суть воротца, которые руководство может открывать и прикрывать в зависимости от финансового положения, текущего состояния пирамиды сеньорити, состояния рынка труда, желания своей левой пятки и тому подобного. Побочным эффектом такой системы повышений является невозможность в явном виде продвижения "своих людей" и уменьшения скорости образования клик в компании. Спойлер: они все-равно появятся, и повышения через комитеты нужных людей будут происходить через неофициальную торговлю "ты-мне, я-тебе", но несколько позже и несколько менее интенсивно, чем если бы решение о повышении просто принимал непосредственный руководитель.
Что об этом надо знать разработчику ? Эта система - не для вас, она - против вас. Есть только одно справедливое число, оценивающее вашу ценность для цивилизации: сколько за вас готовы заплатить на рынке труда. Поэтому, ради всего святого - ходите периодически на собеседования, и знайте свою цену. Если вы имеете оффер хотя бы на 20-30 процентов выше текущего места работы - идите к начальнику, и не размахивая шашкой (оффером) прямо спрашивайте, что надо сделать чтобы через три месяца получать вот столько (называете сумму из оффера). Если вам говорят "нет" или начинают съезжать с темы (а все эти промоушн-комитеты - это идеальный вариант как съехать с темы для начальника: он же хороший, написал заявку - а какие-то злые эксперты зарубили - ну ничего, пока поработай мидлом а через полгода попробуем еще раз...) - ваш моральный долг - перейти на другое место работы.
Ибо есть только одна причина для повышения зарплаты с точки зрения руководства крупной организации - и это дефицит кадров. Не производство ценности, не личные качества и даже не производительность. Есть кадры для текущих проектов - сосите лапу: то что вы воспринимаете как повышение после промоушена - скорее всего индексация на инфляцию (но сделанная хитро - миддлам не прошедшим промоушн индексируют чуть меньше чем на инфляцию, а прошедшим - чуть выше). Есть проблема со стаффингом проектов - пойдет повышение внутри компании, а на освободившиеся позиции начнется набор миддлов и джунов.
Написанное верно для больших (этак человек от 50-100) компаний. В малых компаниях можно достукиваться до первых лиц, вести переговоры (и даже успешно при - условии, конечно, что у компании есть деньги). Но тут ирония рынка: у крупных компаний есть деньги на повышение зарплат, но хрен они будут договариваться с рядовым разработчиком; у малых компаний договориться о повышении намного легче - но у них зачастую банально нет на это денег...
Хотел написать что-то подобное, но вы уже изложили мои мысли на 100%.
Отрадно видеть что в комментариях люди не готовы уплетать за обе щёки сервированное им на совковой лопате с дымком.
Да, мир сложный. Реальное продвижение по карьере зависит от сотен параметров: от уровня твоего руководителя до финансовых показателей компании. Любой процесс в крупной компании нужен, чтобы была управляемость, предсказуемость и общие понятные правила.
С позицией, что все построено против разработчиков, не соглашусь. Суть работы - это взаимный обмен. Ты нам x ютилей полезности, а мы тебе y рублей. Построить справедливую систему сложно, мы пытаемся.
Вот только компания заинтересована получить максимум полезности за минимум рублей, и рычагов давления у неё в общем случае — больше.
Всё остальное — это рассказы на тему того, «как мы покрасили мясорубку в розовый, чтобы уменьшить стресс для будущего фарша»
Суть работы - это взаимный обмен.
Только обмен этот неэквивалентный.
Мир очень сильно упрощается когда у тебя есть оффер от другой компании. Сразу становится пофиг, что компания сама себе написала в руководящих документах. Если менеджмент написал, что месяц перед повышением надо ходить в желтых штанах - теперь это проблема самого же менджмента. Точнее, нет никакой проблемы - составят бумагу (протокол, акт) что месяц ходили в желтых штанах, и вопрос закрыт. Бюрократия не оперирует фактами - она оперирует надлежаще составленными документами. Если же компания не хочет составить желаемые ею же документы - принимаем оффер и ага!
К компании в которой вы работаете надо относиться порядочно, но при этом предельно цинично: они вам не друзья. Какие бы ни были у вас хорошие отношения с коллегами, или даже с непосредственным начальником - как только изменятся экономические условия и/или поменяется ветер в голове высокого начальства - с вами сделают все, что сотчтут нужным: не повысят зарплату, не дадут обещанную должность, уволят, и т.д. И никто из руководства не будет страдать по этому поводу: "Бизнес, и ничего личного!". Нет у нас традиций пожизненной занятости как в Японии, восходящих в традиции к взаимным самурайским обязанностям вассала-господина...
P.S. Это не значит что надо становиться Вовочкой из анекдота: "...оденусь во все коричневое и вам все испорчу!". Надо сохранять нормальные рабочие отношения с максимальным количестком коллег - хотя бы для того чтобы работать было легче. Но вместе с тем, понимайте - имеют силу только те договоренности, которые вы письменно зафиксировали в трудовом договоре. Вы выполняете определенные обязанности - вам платят определенную зарплату. Все "договренности о будущем" - что вас повысят при определенных условиях, или увеличат грейд, или дадут премию - это тлен и пыль. И морковка, висящая перед носом чтобы тащить телегу было не так грустно... Что делать ? Развиваться и ходить на собеседования... Ходить на собеседования, и развиваться...
Для начала неплохо было бы определиться, кто такой тимлид, за что он отвечает и какие задачи решает - это технический эксперт или менеджер? А то по этой статье возникает ощущение, что от тимлидов слишком многого хотят и ожидают. Ну и неплохо было бы авторам знать, что могут быть орг структуры вообще без тимлидов в таком понимании, как у авторов, функции распределяются по более подходящим должностям - за бизнес интересы отвечают менеджеры, а за технологии - технические эксперты.
Игорь, согласен, что в терминологии мы забыли синхронизироваться. Спасибо, что подсветил. Я исходил из того, что тимлид - это роль, ответственная за профессиональный и карьерный рост сотрудников. Где-то это руководитель разработки, где-то прожект менеджер, где-то тех лид.
И конечно же подходов к топологии команд, ролям внутри жутко много. И все пытаются адаптировать их под себя.
Выглядит так, что ново-нанимаемому сеньору проще доказать что он сеньор, чем уже работающему сотруднику.
Интересно, осознанно ли сделана ситуация, в которой сотруднику проще найти новое место работы, чем поднять грейд внутри компании?
Я что-то пропустил или нам в трудовую уже пишут грейд? Недавно три оффера получил, и везде "разраб с зарплатой xyz".
Где у нас "черные пояса" раздают?
По опыту задумываться о повышениях начинают тогда, когда команды начинают расходиться, не один-два человека, а прямо один за другим уходят. А в целом повышение до рынка идёт, когда темп разработки уже значительно замедлился. Пока есть возможность как-то напрячь оставшихся без повышения и более менее сохранить темп разработки, будут напрягать. Поэтому стоит смотреть на то, комфортно ли лично вам с той зарплатой и нагрузкой, которая есть. Не комфортно - просим комфортные суммы и условия, не дают или может быть когда-нибудь при определенных условиях - идём туда, где дают. Как-то так.
У вас какое то неправильное понимание синьора. Задумываться о ценности для бизнеса это вообще-то задача менеджера а не сеньора. Если вы с мидла делаете промоушен человеку в лиды то да необходимо чтобы он это понимал. Ну а понять что человек дорос до сеньера очень просто что менеджменту что работнику. Открываем статистику в git lab и смотрим количество решенных задач с тегом 'high' и 'critical' если их сумма привалирует над 'low' и примерно эквивалентна 'medium' поздравляю у вас созрел сеньер-помидор и пора повышать. И созрел он не по абстрактным знаниям фреймворков и технологий а по общей пользе для вашего продукта. Найти ему замену будет уже очень дорого.
Интересный подход. Опираться только на количественные данные по решенным задачам точно недостаточно, но сигнал для будущих решений сильный.
В моей картине мира любой сотрудник получает зарплату за решаемые бизнес задачи. И пониманием зачем он это делает критично. Даже если ему задачу делегирует лид, то это не повод не разобраться в чем ценность и что на самом деле хотят.
А на что тогда опираться? Все остальное уже сильно субъективно и у собственника и разработчика может быть разный взгляд на бизнес модель компании и понимание того что приносит деньги(как уже писали и не раз любой разработчик на балансе компании это убыток, а продажник это прибыль). А метрика приведённая мной это не интересный подход а аварийная лампочка о том что давно пора. Дальше я рассматриваю ситуацию что человека выдвинули и комитет по промоушену отказал. Если не повысили человека по каким то субъективны причинам (луна не в той фазе, нет бюджета, ещё что то) то считаем последствия: от 2 недель до месяца человек крайне демотивирован и производительность снижена очень сильно, в это же время начинается на волне эмоций попытка оценить себя со стороны и походы по собесам. Если поход успешен контр офер этому человеку уже не нужен, уйдёт на эмоциях чисто из принципа. Что теряем в этоге: месяц производительности хорошего разработчика если останется то переодически как волк будет смотреть на сторону и общий перфоманс будет все равно снижен, или полностью разработчика в случае успешного прохождения им собеса в другой компании. Если отказывают в продвижении на грейд то хотя бы дают повышение зарплаты на текущей позиции за пользу и старания. Но все равно это мало кого мотивирует и чаще всего после неудавшегося промоушена люди уходят.
Позвольте крамольный вопрос: а зачем все эти грейды и лычки? Может было бы проще оценивать человека по вкладу в прибыль компании?
Встречал я как людей без священной приставки «синьор» или «тимлид», к столам которых выстраивались очереди жаждущих получить ответы на все вопросы, так и «синьоров» не знавших основ программирования (паттерны же основы программирования, не так ли?).
Может было бы проще оценивать человека по вкладу в прибыль компании?
Если бы можно было этот вклад взять и посчитать, но как?
Может просто посмотреть, что человек сделал за год: пофиксил столько-то ошибок, из которых столько-то критичных, закоммитил столько-то фич, отрефакторил столько-то классов, создал столько-то Unit тестов, сколько страниц документации написал, сколько рацпредложений сделал, сколько новых (и успешных) сотрудников собеседовал и принял. Всё же видно из репозитория, частично из переписки с начальством, ничего высасывать из пальца не надо. И выдавать премию/повышение зарплаты соответственно.
Гриды это тоже не измеряемая ни чем условность. В каких-то командах я буду едва джуном, а в каких-то просто гением (нет, я не гений, это была гипербола).
Так эти метрики не влияют на прибыль компании.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Это все хорошо, но оценить вклад в прибыль компании это не может. Отрефакторил разраб 10 классов, а как это на прибыль повлияло? Делал фичи в проект, который не выстрелил, прибыли нет, это разве разработчик плохой? Все вами перечисленное это технические вещи.
Безусловно, можно и с технической стороны завалить дело, но разработчик это исполнитель. А исполнитель отвечать за организаторов не может. У него банально нет ни полномочий, ни полноты информации. В своей зоне ответственности, да, должен качественно работать. Но это техническая часть, которая на прибыль влияет опосредственно. Можно прибыль получать и с технически убогими решениями, а можно ничего не получить с прекрасно написанным кодом.
Очевидно есть более простой, быстрый, понятный и прибыльный путь. Идёшь на собеседование, собеседуешься, получаешь оффер с ЗП сеньора. Готово, никаких ожиданий по пол года
Добрый день, а данная схема промоушена актуальна для разработчиков?
А с остальными направлениями как, что с аналитиками, тестировщиками, архитекторами?
Как понять, что твой мидл готов стать сеньором? Гайд для тимлида (и не только)