Важным звеном в процессе повышения разраба зачастую оказывается тимлид — он как наставник должен навести «молодого джедая на путь истинный», помочь своему мидлу наконец-то стать сеньором-помидором (да простят меня хабровчане за космический пафос).
В «Лаборатории Касперского» существует устоявшийся и прозрачный пайплайн повышения мидлов — промоушен-комитет. В этой статье я подробно расскажу об этом процессе с точки зрения руководителя: от подготовки и сбора кейсов до получения кандидатом заветного грейда.
Почему я написал эту статью — потому, что я считаю процесс промоушена очень важным для тимлида. Первое: промоушен — это удобный инструмент повышения мотивации спецов. Такие прозрачные и понятные процессы позволяют планировать свой карьерный трек на годы вперед и, исходя из него, формулировать свои рабочие цели.
Второе — сам тимлид в этом алгоритме промоушена по сути становится ключевым элементом: именно он должен принять решение о подаче заявки на конкретного спеца и помочь эту заявку подготовить.
Так, у нас в «Лаборатории Касперского» процесс промоушена senior-разработчика проходит два раза в год и представляет собой заочное оценивание спеца несколькими senior-экспертами. Тимлид должен подать заявку, в которой будут зафиксированы все основные успехи мидла. После этого группа «жюри» изучит эту анкету «вслепую» и даст кандидату обратную связь.
А судьи кто?
Комиссия промоушена состоит из двух экспертов, которых выбирают с помощью руководителей крупных департаментов. Каждый из них после изучения самой заявки делает вывод о соответствии кейсов определенного кандидата статусу сеньора.
Если оба эксперта расходятся в своих мнениях, к промоушену привлекается третий, от выбора которого и зависит общий вердикт.
Как понять, что твой мидл уже готов стать сеньором?
Есть несколько пунктов, которые показывают, что конкретный спец готов к промоушену:
- Человек работает с важными задачами и понимает их ценность для бизнеса. Спец должен самостоятельно разрабатывать решения для конкретных кейсов и смотреть на проблему с точки зрения заказчика и его «болей».
- Спец обладает софт-скиллами и хорошо коммуницирует в команде. Сеньор — это уже не просто статус разработчика, это еще и статус наставника. Значит, такой специалист не может решать задачи вне коммуникации с командой — и сама команда должна этого сеньора понимать и принимать. Этот пункт особенно важный, потому что сам процесс промоушена проходит заочно и эксперты оценить такие навыки у кандидата физически не могут — это уже сугубо на совести тимлида.
- Кандидат мотивирован. И даже если все звезды сошлись и разраб буквально идеален для повышения — ключевую роль тут играет степень его мотивации и вовлеченности. Подготовка к промоушену — сложный процесс, который требует вовлечения с обеих сторон, а это значит, что тимлид должен видеть как минимум заинтересованность у самого спеца.
Если же инициативу проявляет кандидат, который пока что с точки зрения скиллов не готов к промоушену, тимлид может проговорить с ним, какие конкретно навыки нужно докрутить, какой опыт получить. Это и мотивацию не отнимет, и «на путь истинный» наставит :)
Что конкретно должно быть в анкете и как здесь может помочь тимлид?
Ты выбрал кандидата — и теперь нужно собрать саму заявку. Поскольку оценивание спеца проходит заочно, анкета — это лицо сотрудника. Тимлид должен отнестись к этому этапу с особым вниманием, так как, по сути, именно от него зависит успех промоушена.
Заявка должна включать в себя основные успехи кандидата:
- Примеры решенных задач и реализованных проектов: эксперты будут оценивать их корректность и понятность.
- Примеры разработанной документации и вспомогательных средств (например, созданная либо отредактированная кандидатом документация).
- long distance game. По анкете должно быть понятно, что ты вкладываешься в долгосрочные результаты. Помогаешь коллегам, объясняешь. Пишешь поддерживаемый, тестируемый код. Соблюдаешь сроки.
- Публичность (опционально). Чем больше спец делится с коллегами своим опытом и кейсами, тем более подходящим кандидатом на сеньорство он становится. Речь может идти как об участиях в полноценных конференциях, так и о статьях на Хабре :) Но стоит помнить, что публичность — это дополнительный, не решающий при повышении фактор.
Но ключевое на таком этапе — указать ценность конкретного кандидата именно с точки зрения бизнеса. И именно тут важно влияние тимлида — он видит рабочий процесс и внутри, и снаружи и поэтому способен емко описать бизнес-профиты от конкретного разраба. У меня был пример с действительно хорошим кандидатом, c интересными кейсами и большой экспертизой на стыке математики и программирования, но при составлении анкеты ему просто не удалось продать свои скиллы, показать, как он своими решениями работал с конкретными коммерческими запросами, — и я ему помог исправить это :)
Но что делать, если у кандидата не получилось?
Сразу скажу, что такие ситуации происходят довольно редко — подавляющее большинство мидлов с первого раза проходят промоушен и получают заветный сеньорский грейд. Например, в этом году грейданулись более 93 процентов кандидатов! Однако бывают и обратные ситуации.
На самом деле, пример про одного провалившегося кандидата, который я указал ранее, можно назвать хрестоматийным. Самая распространенная причина отказа в повышении — если тимлид в заявке не смог объяснить ценность конкретных выполненных кандидатом задач с точки зрения бизнеса. Поэтому я так сильно это подчеркиваю: это может быть сколь угодно эффективный и опытный спец, но если вам не удалось ввести в анкету кейсы, подтверждающие коммерческий профит, — шансов немного.
Но это все лирика, человек уже получил отказ, что делать сейчас?
Тимлиду в этот момент очень важно пересмотреть все задачи и кейсы конкретного спеца и пересобрать индивидуальный план для сотрудника на будущие полгода — до следующего промоушена.
Важно: после отказа кандидату и тимлиду приходит анонимный фидбэк со стороны экспертов — и это настоящий кладезь для анализа, который надо использовать на сто процентов! Рекомендую сконцентрировать внимание мидла на повышении конкретных компетенций, упомянутых в обратной связи, — и исходя из них, строить дальнейший план работы. Проще говоря, подготовка к «пересдаче» промоушена требует большой перестройки рабочих задач.
Что делать, если ты тимлид не в бигтехе и централизованных способов повышения сотрудников у тебя нет?
Если у тебя нет полезного инструмента — всегда можно его создать :) Для этого я рекомендую изучить инструкцию GitLab о том, как этот процесс устроен у них.
Вот основные тезисы, которые я могу порекомендовать:
Процесс должен быть прозрачным и понятным. Разраб должен понимать, с какими конкретными требованиями ему надо работать и к чему надо готовиться.
Процесс должен быть коллективным Принятие решения о повышении должно быть согласовано хотя бы с еще одним экспертом — плюрализм мнений превыше всего!
Кроме того, тимлид может в некоторых случаях самостоятельно формировать критерии перевода спеца на старший грейд. Я бы рекомендовал перед принятием решения обязательно проконсультироваться с «независимым экспертом». Им может быть специалист senior+ из другого отдела, который уже взаимодействовал с твоим кандидатом. Так ты получишь более широкую картину перспектив конкретного спеца и сможешь быть более уверен в его готовности (или неготовности) к повышению.
Как продать промоушен бизнесу?
А сейчас наш дорогой читатель-тимлид может задуматься: метод-то хороший, для обеих сторон удобный, но как конкретно внедрить его в компанию?
В первую очередь надо понять, нужен ли промоушен твоей компании. Речь идет о двух важных критериях:
- Численность команды и размер самой компании. Если команда разработки небольшая и руководитель самостоятельно может определять грейд сотрудников, такая система, может, и будет лишней. Но если число разработчиков переваливает за хотя бы 50 человек — самое время задуматься о централизованном промоушене, потому что в таком случае равномерно фокусироваться на всех кандидатах будет непросто.
- Тип компании. Если речь идет о non-tech-компании или пока что разрастающемся стартапе — внедрение промоушена может превратиться в тормозящий работу карго-культ. То же самое относится и к агентствам по заказной разработке.
Для тех, чьи коллективы все-таки подходят под эти критерии, я пообщался с нашими HR BP Мариной Сергиец и Анастасией Филиппи — они поделились со мной шагами, которые предстоит пройти при внедрении промоушен-процесса (не благодарите)).
1) Работай с HR
Внедрение промоушена в бизнес практичнее всего начинать с коммуникации с HR-отделом — у них может быть полезная фактура, исходя из которой можно выдвигать конкретные гипотезы о необходимости «реформы». Возможно, в некоторых командах происходит текучка мидл-специалистов? Или сеньоры отмечают сложность повышения своих спецов? Рассматриваем все возможные ситуации — и используем доступные метрики для фиксации потенциальных «болей» лидов и сеньоров.
2) Узнавай проблемы «напрямую»
Не менее полезным будет и общение с самими представителями разных команд. Важно: тут стоит обращать внимание на разные иерархии спецов. Одинаково стоит прислушиваться к позиции и лида, и перспективного мидла. Так ты и узнаешь болевые точки, и избежишь участи слона в посудной лавке — «спущенная сверху» мера без «зондирования» вряд ли будет эффективной и лишь оттолкнет команды от каких-либо перемен.
3) Борись со скепсисом технарей — и ищи соратников
Ну вот вы почти на финишной прямой — презентация концепта финальному боссу CTO (а вместе с ним, возможно, и CEO). На этом этапе вам точно придется отвечать на вопросы о том, стоит ли игра свеч? Стоит ли организация такого процесса ценного времени экспертов, которые в своем и так забитом рабочем графике будут ревьюить анкеты мидлов?
Тут для вас особенно важно зафиксировать выгоду «реформы»: промоушен повышает мотивацию мидлов и уменьшает их текучку. С таким подходом спец может точно просчитать свой карьерный трек и не будет задумываться об уходе из команды из-за туманных перспектив повышения. Здесь вам поможет фактура «болей», которые вы ранее собирали от HR и спецов из других команд.
Еще одна взаимная выгода — стимул к развитию. Промоушен мотивирует и разработчиков, которые активнее работают со сложными задачами для улучшения своей заявки, и экспертов, которые могут увидеть нетипичные для своего проекта кейсы и обогатить свой опыт.
4) Мотивируй экспертов
Один из главных вызовов, c которым придется столкнуться при внедрении промоушена, — поиск экспертов. Разработчиков иногда сложно убедить выделить время на дополнительную активность в виде участия в промо. И на самом деле их можно понять: и так по уши занятым сеньорам надо отбросить свои дела и ревьюить заявки мидлов.
Если коротко, то для повышения мотивации мы стараемся «выделять» наших экспертов и демонстрировать их пользу для команды и компании — психологи называют это умным словом моральное стимулирование. И надо сказать, это работает: на минувший промоушен нам удалось привлечь 62 экспертов.
Однако это может работать только при наличии развитой корпоративной культуры (уж простите за банальность) — особенно круто, когда эксперты сами осознают важность своего вклада в развитие коллег.
Что делать, если на этот текст наткнулся разработчик, который планирует стать сеньором?
На этот случай я подготовил простые рекомендации по подготовке к повышению для самого кандидата. Кстати, мы уже частично затрагивали эту тему в статье про нюансы карьеры разработчика C++ — рекомендую почитать!
Заранее проговаривайте о своих желаниях — например, на 1-2-1
Увы, тимлиды не умеют читать мысли (по крайней мере, я точно), поэтому в идеале сам мидл должен указывать на свои цели. Если сам сотрудник не будет проявлять инициативу по развитию своих скиллов, тимлид едва ли сможет воспринимать его как кандидата на промоушен.
Смотрите на свои задачи с точки зрения бизнес-решений
Сеньор в первую очередь должен быть полезен и актуален для бизнеса — и именно с такой оптикой надо подходить к решению любых задач. Технические хард-скиллы — это безусловная база, но ты всегда должен понимать, какие конкретные коммерческие потребности они помогают тебе закрыть.
Ну а третий лайфхак я пока что сохраню в тайне: если захотите о нем узнать — приходите к нам в «Лабораторию Касперского» :)
Вместо заключения
Повышение до senior-грейда — сложный этап, который требует от тимлида большой вовлеченности в конкретного кандидата. Централизованный промоушен в этом плане значительно упрощает жизнь и руководителю, и кандидату — оба понимают правила игры и могут подготовиться к конкретным критериям повышения. Именно поэтому в «Лаборатории Касперского» мы активно используем этот метод: только в 2023 году грейд успешно получили без малого 100 специалистов. Звучит заманчиво, не так ли? :)
Комментарии (41)
Farongy
24.08.2024 18:27+9Самая распространенная причина отказа в повышении — если тимлид в заявке не смог объяснить ценность конкретных выполненных кандидатом задач с точки зрения бизнеса.
А кто у вас задачи то выбирает? Сам разработчик что-ли придумывает? Или всё таки бизнес? А если бизнес, то почему этот бизнес не знает какую ценность эти задачи несут?
AnROm
24.08.2024 18:27+7Здесь поднимается вопрос некомпетентности тимлида. Странно, что им может быть непонятна ценность выполняемой командой работы. Отсюда приходим к теме "Как понять, что ваш сотрудник готов стать тимлидом?"
mvv-rus
24.08.2024 18:27+8психологи называют это умным словом моральное стимулирование.
"А может, лучше деньгами?".
PS Эта фраза - из моей комсомольской юности. Конечно, к выводам всяких буржуазных наук тогда не прислушивались, но моральное стимулирование было хорошо изввестно и использовлось широко. Отношение людей - а мы были студентами, людьми умными - было к этому адекватное. И когда однажды у нас на местном собрании комсомольский босс начал втирать нам в уши очередную туфту про то, что мы там должны что-то сделать (не помню уже), а за это то ли грамоту дадут, то ли на Доску Почета поместят, один мой знакомый, там присутствующий сказал окржавшим его студентам эту самую фразу. Сказал он тихо, но босс услышал. Кароче, были тому студенту проблемы, но не фатальные - в деканате он был на хорошем счету, так что долг перед Родиной (а в те времена его запросто можно было отдать в Афгане, вместе с жизнью) ему отдавать не пришлось. Но фраза запомнилась.
Совка давно уж нет но его дух - как развести работников на работу забесплатно - гляжу, жив.
summerwind
24.08.2024 18:27+3Обычно грейды взаимосвязаны с повышением зарплаты, и как раз вводятся для того, чтобы сотрудникам было прозрачно и понятно, как повысить уровень оплаты своего труда. Так что, думаю, такого нет, что просто вешается лычка senior-грейда без изменения уровня зарплаты. Иначе это было бы совсем уж странно.
piton_nsk
24.08.2024 18:27"Моральное стимулирование" было про экспертов, которые оценивают потенциального сеньора.
mvv-rus
24.08.2024 18:27Ну, я понимаю, что повышение грейда - это вполне честный процесс отбора тех работников, которые могут принести больше пользы предприятию, с целью навешивания на них дополнительных обязанностей, компенисруемы однако повышенной(обычно) зарплатой.
Но моральное стимулирование автор зачем-то упомянул.
VitaminND
24.08.2024 18:27+1В Лаборатории Касперского своя атмосфера, достаточно почитать более раннее творчество.
iosuslov
24.08.2024 18:27+2Не увидел в статье пункту про "в первую очередь тимлид должен знать есть ли у конторы бюджет на повышение ЗП ещё одному работнику". Иначе, если контора не готова платить больше, все эти танцы вокруг повышения бессмысленная трата времени.
В остальном, тимлид должен пытаться тянуть каждого своего разраба в сеньоры, вне зависимости от того, хочет разраб этого или нет. Во-первых и люди не заскучают, т.к. будет цель, а во вторых будут объективные причины ЗП повышать.
Разумеется, если при таких попытках встречается сильно сопротивление со стороны сотрудника, темп этого продвижения нужно снизить, чтоб не душить человека. Но развитие в этом направлении должно быть по умолчанию. Кто не развивается - тот деградирует.
И ещё одна проблема в том, что большинство тим лидов не умеют правильно расставлять приоритеты и делегировать, отсюда возникает нехватка времени на действительно важную часть работы лида - наблюдение за командой, понимание ее слабых мест и сильных мест, и выстраивание стратегии развития исходя из этого. В общем, на бумаге все красиво, а по уму все это реализовать смогут единицы.
MadeByFather
24.08.2024 18:27+4Опять вода водой. Вот вы пишите, что нужно иметь прозрачный и понятный план, что нужно сделать, чтобы вырасти в грейде. А дальше пишите воду про понимание ценности для бизнеса, мотивацию и софт-скиллы. Что это значит? Даже джун может быть супер-мотивированным, иметь идеальные софт скиллы и даже понимать ценности бизнеса и зачем в конце концов он двигает такси в джире. Он уже может на этом основании стать сеньором?
Ладно, дальше получше - тимлид собирает список задач и проектов, которые сделал разработчик. А кто давал ему эти задачи и назначал на эти проекты? Наверное, не сам разработчик, особенно на уровне миддла. То есть если разработчик оказался на поддержке какого-то легаси, которое ещё никому и не нужно особо, то он не увидит повышение примерно никогда, потому что бизнесу он не принёс достаточно ценности.
piton_nsk
24.08.2024 18:27А кто давал ему эти задачи и назначал на эти проекты? Наверное, не сам разработчик, особенно на уровне миддла.
Во, тоже хотел это спросить.
ayushindin Автор
24.08.2024 18:27Привет.
В тексте есть важное упоминание, что разработчик должен успешно решать задачи, но просто решать задачи недостаточно чтобы стать старшим разработчиком.
Если мы смотрели бы на опыт MAANG-компаний, то разработчик на проектах, которые менее важны для бизнеса, не получил бы продвижения - факт. В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании. We live in society) Но и да мы активно промоутим людей с самых различных проектов.
MadeByFather
24.08.2024 18:27В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании.
Что это значит?
По каким параметрам вы определите, есть понимание у кандидата или нет. Вот я условный разработчик, пишу какой-то внутренний сервис или продукт, он продается или помогает продавать другие продукты, чтобы принести деньги бизнесу. Я вам это сказал, вы сразу перевели меня в сеньоры? А если тоже самое скажет джун с 1 годом опыта, то он тоже пойдет в сеньоры?
Я могу понять оценку в количестве выполненных сторипоинтов или закрытых задач, в количестве МРов, которые проревьювил разработчик, в количестве разработчиков, которых он менторит. Я даже могу понять оценки в виде высокоуровневых и абстрактных задачах - мы слишком много денег тратим на поддержку клиентов; стоимость инфрастуктуры слишком большая; хотим, чтобы сейчас наш антивирус гнал трафик не по гигабайту в час от клиента, а в два раза меньше.
Тогда я могу прийти через полгода-год и сказать, вот, смотрите, тратили столько, стали на 30% меньше, я (наша команда) молодец. Или вот, раньше отвечали в поддержке в среднем в течении двух дней, а теперь в течении двух часов. Или даунтайм серверов обновления был 5% в год, стал 0.5%
А вот как мне доказать, что у меня за последний год стало больше какого-то мифического понимания, я не знаю.
ayushindin Автор
24.08.2024 18:27Понимание смотрим на этапе ревью анкет, которая заполняется лидом и кандидатом на промоушн.
Если человек напишет, что вот мои артефакты, которыми я горжусь и в рамках их он опишет их output+outcome, то это и есть понимание.
MadeByFather
24.08.2024 18:27+2Разработчик уровня миддла это не вольный охотник, который возвращается раз в год с докладом, что он придумал поделать, вы же сами давали ему конкретные задачи, если вы не выдали задач, которыми можно было бы гордиться или которые не были сильно полезны бизнесу, то получается разработчик вместо повышения будет сосать лапу?
И опять отмечу, что никаких конкретных критериев вы не озвучили (понимаю, что их нет и вы их сами не знаете и вам просто поручили написать статую в корпоративный блог) - например, мы ожидали, что разработчик сделает 30 сторипоинтов, а он сделал 20. Или наоборот, он сделал 50, поэтому он молодец и мы его повышаем
beasty4ever
24.08.2024 18:27+1А кто тогда соглашается работать на проектах с которых не возможно продвижение? Зачем это делать? Опыта там никакого а боль и страдание как от задач так и от отсутствия какого либо роста гарантирована. Если у вас в касперском тоже так и нет возможности выбраться из этого то бедные ребята. Я сам работал в болоте в другой компании долгое время и не кому не пожелаю.
deepmind7
24.08.2024 18:27+10И как всегда самый простой и быстрый способ апнуться в сеньёры - это перейти в другую компанию, а не проходить смотрины в каком-то блат-комитете.
ayushindin Автор
24.08.2024 18:27Согласен. Job hopping - один из самых понятных и быстрых способов в начале карьеры быстро забраться на синьера с отличной зарплатой.
Проблемы начинаются дальше. Например, у нас после синьера есть позиции ведущего разработчика, эксперта, старшего эксперта, ведущего эксперта и principal эксперта. Плюс есть возможность на этой карьерной лестнице сделать переход в менеджерскую ветку. Тут job hopping не помогает.
Мой личный опыт - 10 лет в компании. 5 лет от стажера до синьера и 5 лет на менеджерском треке. В целом очень рад, что не выбрал job hopping как карьерную стратегию
ruomserg
24.08.2024 18:27+19Давайте я из своего управленческого опыта скажу - все эти грейд-комитеты, ассесменты, промоушн-кампании и прочее - сделаны с одной целью: ЗАТОРМОЗИТЬ рост грейдов и зарплат в компании и сделать его более предсказуемым. Особенно - в сочетании с практикой: сначала покажите что вы уже достигли уровня, а потом мы вам его повысим.
Все эти комитеты и процедуры - суть воротца, которые руководство может открывать и прикрывать в зависимости от финансового положения, текущего состояния пирамиды сеньорити, состояния рынка труда, желания своей левой пятки и тому подобного. Побочным эффектом такой системы повышений является невозможность в явном виде продвижения "своих людей" и уменьшения скорости образования клик в компании. Спойлер: они все-равно появятся, и повышения через комитеты нужных людей будут происходить через неофициальную торговлю "ты-мне, я-тебе", но несколько позже и несколько менее интенсивно, чем если бы решение о повышении просто принимал непосредственный руководитель.
Что об этом надо знать разработчику ? Эта система - не для вас, она - против вас. Есть только одно справедливое число, оценивающее вашу ценность для цивилизации: сколько за вас готовы заплатить на рынке труда. Поэтому, ради всего святого - ходите периодически на собеседования, и знайте свою цену. Если вы имеете оффер хотя бы на 20-30 процентов выше текущего места работы - идите к начальнику, и не размахивая шашкой (оффером) прямо спрашивайте, что надо сделать чтобы через три месяца получать вот столько (называете сумму из оффера). Если вам говорят "нет" или начинают съезжать с темы (а все эти промоушн-комитеты - это идеальный вариант как съехать с темы для начальника: он же хороший, написал заявку - а какие-то злые эксперты зарубили - ну ничего, пока поработай мидлом а через полгода попробуем еще раз...) - ваш моральный долг - перейти на другое место работы.
Ибо есть только одна причина для повышения зарплаты с точки зрения руководства крупной организации - и это дефицит кадров. Не производство ценности, не личные качества и даже не производительность. Есть кадры для текущих проектов - сосите лапу: то что вы воспринимаете как повышение после промоушена - скорее всего индексация на инфляцию (но сделанная хитро - миддлам не прошедшим промоушн индексируют чуть меньше чем на инфляцию, а прошедшим - чуть выше). Есть проблема со стаффингом проектов - пойдет повышение внутри компании, а на освободившиеся позиции начнется набор миддлов и джунов.
Написанное верно для больших (этак человек от 50-100) компаний. В малых компаниях можно достукиваться до первых лиц, вести переговоры (и даже успешно при - условии, конечно, что у компании есть деньги). Но тут ирония рынка: у крупных компаний есть деньги на повышение зарплат, но хрен они будут договариваться с рядовым разработчиком; у малых компаний договориться о повышении намного легче - но у них зачастую банально нет на это денег...
LuigiVampa
24.08.2024 18:27+2Хотел написать что-то подобное, но вы уже изложили мои мысли на 100%.
Отрадно видеть что в комментариях люди не готовы уплетать за обе щёки сервированное им на совковой лопате с дымком.
ayushindin Автор
24.08.2024 18:27Да, мир сложный. Реальное продвижение по карьере зависит от сотен параметров: от уровня твоего руководителя до финансовых показателей компании. Любой процесс в крупной компании нужен, чтобы была управляемость, предсказуемость и общие понятные правила.
С позицией, что все построено против разработчиков, не соглашусь. Суть работы - это взаимный обмен. Ты нам x ютилей полезности, а мы тебе y рублей. Построить справедливую систему сложно, мы пытаемся.
MaxKitsch
24.08.2024 18:27+2Вот только компания заинтересована получить максимум полезности за минимум рублей, и рычагов давления у неё в общем случае — больше.
Всё остальное — это рассказы на тему того, «как мы покрасили мясорубку в розовый, чтобы уменьшить стресс для будущего фарша»
ruomserg
24.08.2024 18:27+1Мир очень сильно упрощается когда у тебя есть оффер от другой компании. Сразу становится пофиг, что компания сама себе написала в руководящих документах. Если менеджмент написал, что месяц перед повышением надо ходить в желтых штанах - теперь это проблема самого же менджмента. Точнее, нет никакой проблемы - составят бумагу (протокол, акт) что месяц ходили в желтых штанах, и вопрос закрыт. Бюрократия не оперирует фактами - она оперирует надлежаще составленными документами. Если же компания не хочет составить желаемые ею же документы - принимаем оффер и ага!
К компании в которой вы работаете надо относиться порядочно, но при этом предельно цинично: они вам не друзья. Какие бы ни были у вас хорошие отношения с коллегами, или даже с непосредственным начальником - как только изменятся экономические условия и/или поменяется ветер в голове высокого начальства - с вами сделают все, что сотчтут нужным: не повысят зарплату, не дадут обещанную должность, уволят, и т.д. И никто из руководства не будет страдать по этому поводу: "Бизнес, и ничего личного!". Нет у нас традиций пожизненной занятости как в Японии, восходящих в традиции к взаимным самурайским обязанностям вассала-господина...
P.S. Это не значит что надо становиться Вовочкой из анекдота: "...оденусь во все коричневое и вам все испорчу!". Надо сохранять нормальные рабочие отношения с максимальным количестком коллег - хотя бы для того чтобы работать было легче. Но вместе с тем, понимайте - имеют силу только те договоренности, которые вы письменно зафиксировали в трудовом договоре. Вы выполняете определенные обязанности - вам платят определенную зарплату. Все "договренности о будущем" - что вас повысят при определенных условиях, или увеличат грейд, или дадут премию - это тлен и пыль. И морковка, висящая перед носом чтобы тащить телегу было не так грустно... Что делать ? Развиваться и ходить на собеседования... Ходить на собеседования, и развиваться...
igor-sheludko
24.08.2024 18:27+2Для начала неплохо было бы определиться, кто такой тимлид, за что он отвечает и какие задачи решает - это технический эксперт или менеджер? А то по этой статье возникает ощущение, что от тимлидов слишком многого хотят и ожидают. Ну и неплохо было бы авторам знать, что могут быть орг структуры вообще без тимлидов в таком понимании, как у авторов, функции распределяются по более подходящим должностям - за бизнес интересы отвечают менеджеры, а за технологии - технические эксперты.
ayushindin Автор
24.08.2024 18:27Игорь, согласен, что в терминологии мы забыли синхронизироваться. Спасибо, что подсветил. Я исходил из того, что тимлид - это роль, ответственная за профессиональный и карьерный рост сотрудников. Где-то это руководитель разработки, где-то прожект менеджер, где-то тех лид.
И конечно же подходов к топологии команд, ролям внутри жутко много. И все пытаются адаптировать их под себя.
buldo
24.08.2024 18:27+2Выглядит так, что ново-нанимаемому сеньору проще доказать что он сеньор, чем уже работающему сотруднику.
Интересно, осознанно ли сделана ситуация, в которой сотруднику проще найти новое место работы, чем поднять грейд внутри компании?
AlexanderKireev75
24.08.2024 18:27+1Я что-то пропустил или нам в трудовую уже пишут грейд? Недавно три оффера получил, и везде "разраб с зарплатой xyz".
Где у нас "черные пояса" раздают?
lnkiseleva
24.08.2024 18:27+2По опыту задумываться о повышениях начинают тогда, когда команды начинают расходиться, не один-два человека, а прямо один за другим уходят. А в целом повышение до рынка идёт, когда темп разработки уже значительно замедлился. Пока есть возможность как-то напрячь оставшихся без повышения и более менее сохранить темп разработки, будут напрягать. Поэтому стоит смотреть на то, комфортно ли лично вам с той зарплатой и нагрузкой, которая есть. Не комфортно - просим комфортные суммы и условия, не дают или может быть когда-нибудь при определенных условиях - идём туда, где дают. Как-то так.
beasty4ever
24.08.2024 18:27+3У вас какое то неправильное понимание синьора. Задумываться о ценности для бизнеса это вообще-то задача менеджера а не сеньора. Если вы с мидла делаете промоушен человеку в лиды то да необходимо чтобы он это понимал. Ну а понять что человек дорос до сеньера очень просто что менеджменту что работнику. Открываем статистику в git lab и смотрим количество решенных задач с тегом 'high' и 'critical' если их сумма привалирует над 'low' и примерно эквивалентна 'medium' поздравляю у вас созрел сеньер-помидор и пора повышать. И созрел он не по абстрактным знаниям фреймворков и технологий а по общей пользе для вашего продукта. Найти ему замену будет уже очень дорого.
ayushindin Автор
24.08.2024 18:27Интересный подход. Опираться только на количественные данные по решенным задачам точно недостаточно, но сигнал для будущих решений сильный.
В моей картине мира любой сотрудник получает зарплату за решаемые бизнес задачи. И пониманием зачем он это делает критично. Даже если ему задачу делегирует лид, то это не повод не разобраться в чем ценность и что на самом деле хотят.
beasty4ever
24.08.2024 18:27+1А на что тогда опираться? Все остальное уже сильно субъективно и у собственника и разработчика может быть разный взгляд на бизнес модель компании и понимание того что приносит деньги(как уже писали и не раз любой разработчик на балансе компании это убыток, а продажник это прибыль). А метрика приведённая мной это не интересный подход а аварийная лампочка о том что давно пора. Дальше я рассматриваю ситуацию что человека выдвинули и комитет по промоушену отказал. Если не повысили человека по каким то субъективны причинам (луна не в той фазе, нет бюджета, ещё что то) то считаем последствия: от 2 недель до месяца человек крайне демотивирован и производительность снижена очень сильно, в это же время начинается на волне эмоций попытка оценить себя со стороны и походы по собесам. Если поход успешен контр офер этому человеку уже не нужен, уйдёт на эмоциях чисто из принципа. Что теряем в этоге: месяц производительности хорошего разработчика если останется то переодически как волк будет смотреть на сторону и общий перфоманс будет все равно снижен, или полностью разработчика в случае успешного прохождения им собеса в другой компании. Если отказывают в продвижении на грейд то хотя бы дают повышение зарплаты на текущей позиции за пользу и старания. Но все равно это мало кого мотивирует и чаще всего после неудавшегося промоушена люди уходят.
KIL2
24.08.2024 18:27Также в случае, если сотрудник принимает контр-офер, то эта информация рано или поздно становится известна другим коллегам, и они начнут оценивать, какой путь для повышения в должности/зарплаты легче. И, вполне возможно, выбор будет сделан не в пользу ритуалов промоушн-комитета.
Krasnoarmeec
24.08.2024 18:27Позвольте крамольный вопрос: а зачем все эти грейды и лычки? Может было бы проще оценивать человека по вкладу в прибыль компании?
Встречал я как людей без священной приставки «синьор» или «тимлид», к столам которых выстраивались очереди жаждущих получить ответы на все вопросы, так и «синьоров» не знавших основ программирования (паттерны же основы программирования, не так ли?).
piton_nsk
24.08.2024 18:27Может было бы проще оценивать человека по вкладу в прибыль компании?
Если бы можно было этот вклад взять и посчитать, но как?
Krasnoarmeec
24.08.2024 18:27Может просто посмотреть, что человек сделал за год: пофиксил столько-то ошибок, из которых столько-то критичных, закоммитил столько-то фич, отрефакторил столько-то классов, создал столько-то Unit тестов, сколько страниц документации написал, сколько рацпредложений сделал, сколько новых (и успешных) сотрудников собеседовал и принял. Всё же видно из репозитория, частично из переписки с начальством, ничего высасывать из пальца не надо. И выдавать премию/повышение зарплаты соответственно.
Гриды это тоже не измеряемая ни чем условность. В каких-то командах я буду едва джуном, а в каких-то просто гением (нет, я не гений, это была гипербола).
Yago
24.08.2024 18:27+1Так эти метрики не влияют на прибыль компании.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
piton_nsk
24.08.2024 18:27Это все хорошо, но оценить вклад в прибыль компании это не может. Отрефакторил разраб 10 классов, а как это на прибыль повлияло? Делал фичи в проект, который не выстрелил, прибыли нет, это разве разработчик плохой? Все вами перечисленное это технические вещи.
Безусловно, можно и с технической стороны завалить дело, но разработчик это исполнитель. А исполнитель отвечать за организаторов не может. У него банально нет ни полномочий, ни полноты информации. В своей зоне ответственности, да, должен качественно работать. Но это техническая часть, которая на прибыль влияет опосредственно. Можно прибыль получать и с технически убогими решениями, а можно ничего не получить с прекрасно написанным кодом.
143672
24.08.2024 18:27+1Очевидно есть более простой, быстрый, понятный и прибыльный путь. Идёшь на собеседование, собеседуешься, получаешь оффер с ЗП сеньора. Готово, никаких ожиданий по пол года
justreading
24.08.2024 18:27Добрый день, а данная схема промоушена актуальна для разработчиков?
А с остальными направлениями как, что с аналитиками, тестировщиками, архитекторами?
AnROm
Вопрос к иллюстрации: когда вы успели перейти с медведей на колобков? :)
rakdolina
Да что-то Голованов изменился...