Достигая условного «потолка», инженеры часто уходят в другие компании в поисках амбициозных задач. Бизнес теряет опытных людей, хотя на самом деле рост был возможен, просто не формализован, или тимлиду некогда было этим заняться. Я подумал, что круто — иметь в команде систему, которая сделает развитие предсказуемым для инженера. Когда он сам или с поддержкой смог бы строить карьеру, в зависимости от личных целей. Кто-то хочет прокачиваться и расти, кто-то выше зарплату, а кому-то важно сейчас оставаться на уровне и не гнаться за новыми повышениями.

Я, Константин Лапин, руководитель технической поддержки Nexign. Мы пишем софт для телекома, создаём международные продукты и платформы, ускоряющие работу внутри компаний. Моя команда поддерживает одного из крупнейших телеком-операторов России. Мы отвечаем за то, чтобы технических сбоев либо не было, либо, если сбой случился, то минимально влиял на абонентов. В отделе четыре команды по 8-10 человек в каждой, работающие в графике 2×2.

Расскажу, как мы создали и внедрили систему развития от инженера до главного эксперта в своей команде. Мы обсудим:

• что такое инженерный карьерный трек, кому он нужен, а кому нет;

• что влияет на продвижение по треку;

• как мы обосновываем повышения бизнесу и сотрудникам;

• как растим новичков и что получилось по итогу внедрения готовой схемы в команде из 40 человек.

Дисклеймер

Дисклеймер: в разных компаниях я видел примеры, когда инженера подталкивают в руководители ради роста в деньгах. Я за то, чтобы переход в менеджмент был осознанным выбором, поэтому расскажу, как расти именно в инженерном треке.

Карьерный трек

Знаете ли вы, что вам нужно сделать для следующего повышения? А если вы руководитель, знают ли об этом люди в вашей команде? Если на оба вопроса ваш ответ — «Да», возможно, эта статья вам не пригодится. Если «Нет» — давайте попробуем вместе найти решение.

Как руководитель я часто сталкивался с тем, что одна из главных проблем по итогам пульс-опросов в командах — сотрудники не понимают, что нужно сделать для роста в роли и деньгах. Как эффект домино, это влечёт другие последствия. Люди уходят, даже не пытаясь обсудить свои ожидания, потому что не видят возможности повысить зарплату. Им кажется, что процесс повышения непрозрачен и зависит не только от их работы, но и от каких-то специфических условий — например, необходимости регулярно общаться с руководителем.

Ещё бывает, что в команде вырастает несколько сильных специалистов, которым нужно повысить зарплату. Но у компании на момент запроса просто нет на это бюджета, а руководство или HR не знали о такой потребности заранее.

Чтобы избежать этих проблем, нужен инструмент, позволяющий заложить бюджет и согласовать ожидания заранее. В случае моей команды им стал карьерный трек — список уровней и требований к ним, распределённый по должностям. Чтобы перейти на новый уровень роли или зарплаты, инженер должен подтвердить, что его навыки соответствуют всем критериям.

Схема карьерного трека, к которой мы пришли, включает десять уровней и четыре должности — от инженера до главного эксперта. Вот как это выглядит:

Такой формат помогает быть более гибкими:

• у нас много уровней для развития, они распределены во времени. На каждом уровне инженеры получают повышение в деньгах; 

• мы сразу можем сказать, какие перспективы роста у специалиста, и как ему подготовиться к новому этапу.

С другой стороны, у подхода были проблемы. Я пробовал внедрить карьерный трек три раза. Первые два подхода — это была красивая страничка на Confluence, которой не пользовались. Руководители считали, что лучше знают, кого стоит повысить и как работает каждый инженер. А наши критерии в треке использовали только для  формального обоснования повышения, предварительно притянув их к результатам конкретного человека. Ещё я видел, что ребята приобретали знания, без разницы — «софты» или «харды», которые никак не помогали им лучше работать. А мы стремились привязаться к результату. В итоге проблем от непродуманного внедрения было намного больше, но я понял, как их можно избежать.

Формулируем ожидания

Процесс повышений должен быть понятен на всех уровнях, а не только в паре руководитель-инженер.

Инженеру важно видеть перспективы роста и понимать, как их достичь.

Тони Шей в книге «Доставляя счастье. От нуля до миллиарда» пишет, что человек, который управляет процессом и видит перспективы, чувствует себя счастливее. В его компании Zappos сотрудники контактного центра получали повышение зарплаты раз в полтора года. Руководство изменило подход и разбило это повышение на три этапа по шесть месяцев, сохранив общую сумму повышений. По итогам опросов оказалось, что сотрудники стали чувствовать себя счастливее, потому что видели понятный путь роста и могли контролировать своё развитие. С инженерами работает тот же принцип.

Команде важно понимать, как проходят повышения. Например, в какой-то момент мы повысили двоих инженеров и сразу же сообщили об этом. Через несколько часов пришла группа сотрудников, работающих удалённо, с вопросами: почему выбрали именно этих инженеров, как проходил отбор, и есть ли у удалённой команды такие же шансы на повышение, как у тех, кто работает со мной в кабинете? Мы обсуждали около часа, и, как мне показалось, нашли точки контакта. Но спустя неделю один из инженеров уволился. Карьерный трек помогает сразу задать понятные рамки и условия для всех.

Теперь C-level. Руководителю, будь то IT-директор или HR, важно заранее прогнозировать, сколько сотрудников мы планируем повышать, ведь бюджеты на это ограничены. Если ожидается больше повышений, бюджет нужно пересмотреть или подумать, как в него вписаться. Лучше заранее к этому готовиться и просчитывать дополнительные шаги.

Тимлид ожидает от трека счастья команды и сохранения её целостности. Но кроме этого, трек помогает обосновывать повышения и увеличивать бюджет команды — зарплаты, премии, обучение. Вместо субъективных аргументов, что «Петя или Маша стали работать лучше», можно привести конкретные примеры: заранее оговоренные результаты достигнуты, значит, стоит повысить этих ребят.

Кем станет инженер, когда дойдёт до последнего уровня?

Это важный ориентир для команды, который нужно определить заранее, чтобы избежать завышенных ожиданий.

Представьте на финальном уровне человека, способного провести любую аналитику. При этом он fullstack и умеет продавать решения клиентам и руководству. Что будет, если вы такого специалиста найдёте или вырастите? Как удержать его в команде по задачам и деньгам? Не захочет ли он перейти туда, где вызовов больше? Ориентировать всю команду на такой путь развития — нереалистично.

В нашем треке на последнем, десятом уровне, появляется развилка. С одной стороны, инженеры могут разрабатывать новую функциональность, которую можно монетизировать. Например, инструменты для предиктивной аналитики, чтобы выявлять проблемы в продакшене или фиксировать сетевые активности, а в случае сбоев предоставлять все необходимые данные для анализа.

С другой стороны, мы хотим снижать затраты на эксплуатацию продуктов. Чаще всего это затраты на лицензии и оборудование. Если оптимизация запросов уменьшила нагрузку на базу данных, нам не нужно докупать дополнительные мощности, соответственно, мы сэкономили деньги.

В итоге, на верхнем уровне трека получается не человек-оркестр, а в идеале — сильный эксперт в области поддержки, предыдущий опыт которого помогает двигаться дальше.

Карьерный трек — гибкий

Так как трек растянут во времени на несколько лет, то, конечно, по мере его прохождения у инженера могут измениться интересы или видение карьеры. Тогда мы создадим для него новый трек: наша HRM-система Neon это позволяет. Например, эксперт 10-го уровня в поддержке может стать, мидлом 6-го уровня в DevOps или джуном 3-го уровня в разработке.

Пример, как выглядит трек опытного сотрудника, который начинал с позиции ведущего инженера:

Что сделать перед началом проектирования трека:

• Подумать, кто и как будет работать с карьерным треком.

• Определить совместно с командой/тимлидами, кем станет инженер, когда дойдёт до последнего уровня.

• Оценить сложность подготовки специалиста — чего будет стоить его вырастить/найти и удержать.

Связываем трек, навыки и пользу для бизнеса

Примерно 70% людей, уходящих из нашей команды, остаются внутри компании — меняют линию поддержки, переходят в разработку и другие направления. Поэтому мы регулярно набираем и адаптируем новичков. Но есть трудность — каждый инженер должен быть взаимозаменяемым из-за графика работы и должен уметь поддерживать 10–15 сложных продуктов. В какой-то момент мы задумались: а нужно ли новичку сразу глубоко понимать все эти продукты? Или можно сначала дать практические знания, чтобы он не тратил полгода на изучение документации, а уже на старте приносил пользу?

Мы решили ускорить адаптацию и разделили продукты по приоритетам. Определили, какие системы ломаются чаще всего и оказывают наибольшее влияние на клиентов. Новички сначала изучают только их и только по ним решают аварии.

Затем мы пошли дальше и завязали обучение на практику.

Если Груту сказать: «В случае проблемы жми эту кнопку», он может пока и не знать, в чём суть проблемы, но уже будет приносить пользу.

Наши эксперты выбрали рабочие кейсы, с которыми инженер обязательно столкнется — по аналогии с обучением в автошколе:

• 3 месяца: работа с куратором, совместный разбор задач и самостоятельная практика;

• 6 месяцев: больше свободы в работе, но в рамках контролируемой среды, как на автодроме;

• 12 месяцев: полное самостоятельное выполнение задач, но пока без статуса эксперта.

На каждом из временных отрезков порядка 10 кейсов, которые решают инженеры. Это не синтетические примеры, а реальные задачи и аварии, которые нужно уметь устранять. По итогу каждого кейса инженер оставляет комментарии в JIRA, где фиксируется алгоритм решения и скрипты. Куратор проверяет эти данные.

Бывает, инженер работает год, но не сталкивается с некоторыми кейсами, потому что обычно их берут эксперты. Теперь куратор и инженер видят пробелы и целенаправленно берут соответствующие задачи для самостоятельной работы.

Проверку каждого этапа проводит инженер, который не был куратором и в чьих знаниях мы уверены. Этот эксперт посмотрит кейсы, оставит комментарии и подготовит вопросы. Потом вместе с новичком на встрече всё разберёт. Так мы получаем два мнения внутри команды — куратора и эксперта.

В карьерном треке — только нужные навыки

Не нужно всё тащить в карьерный трек.

Один из навыков, который мы всегда проверяли на начальных этапах собеседований — умение работать с Unix-системами и командной строкой. Считали, что это важно, но на практике у инженеров достаточно времени, чтобы найти ответ самостоятельно, с помощью интернета или коллег. Тогда мы подумали: зачем включать это в трек? И оставили это требование только на этапе собеседований.

Ещё мы каждый день работаем с базами данных. Это наш основной инструмент, но новички из непрофильных специальностей с большинством кейсов просто не сталкивались. Мы закрыли этот пробел короткими 4-5-минутными видео с мемами и фрагментами из фильмов. В каждом ролике разбираем работу с одним инструментом: как найти блокировки в базе данных, или «отстрелить» зависшую сессию, или оптимизировать запрос, и даём один или несколько способов решения. Такой формат помогает дополнить знания и не требует использования трека.

Дальше о том, что отделяет успешное внедрение трека от других попыток.

Определяем критерии повышения

Что влияет на повышение в нашей команде? И как мы выбираем людей, которых собираемся повышать?

В первых версиях карьерного трека не учитывались достижения конкретных результатов и поведенческие аспекты — только изучение материалов, успешное подтверждение знаний с экспертами, обучение других. Трек был очень техническим и фокусировался больше на процессе, а не на результате. А о том, как люди при этом достигают верхних уровней, не помогая другим членам команды или не используя полученные знания, мы изначально даже не думали.

Тогда мы выписали все важные критерии, сравнили их с тем, что уже было в треке, и добавили пункт: выполнение задач под ключ. Это не отдельная задача, а подход к решению. Специалист не только выполняет то, что ему поручили, но и пытается понять, какую проблему решает. Если ему предложили конкретный способ реализации, то оценивает, насколько это оптимально, и предлагает альтернативы. А после выполнения задачи проверяет, достиг ли ожидаемого результата, или проводит ретро и корректирует подход.

Примеры вопросов, над которыми стоит подумать, формулируя критерии повышения:

• Готовы ли вы повысить крутого, но токсичного эксперта?

• А если эксперт не передаёт знания? Готовы ещё больше от него зависеть, давая сложные проекты?

• Или если эксперт выполнил все критерии трека, но вы недовольны его работой — вы его повысите?

Что заложить в трек:

• Подумать, как быстрее включить новичка в работу над задачами, ради которых его нанимали.

• Решить, как глубоко погружать новичка в процессы и какие задачи уже можно передать.

• Навести порядок: зафиксировать в карьерном треке все критически важные знания и навыки, которые проверяются и убрать те, которые вы не проверяете.

• Честно оценить, какие негласные критерии для повышений именно в вашей команде.

• Обсудить всё перечисленное с тимлидами/командой.

Закладываем передачу знаний в карьерный трек

Допустим, карьерный трек стартовал, и инженеры растут. Как решить проблему, когда  нужно работать вечером, ночью или в выходные, чтобы достичь нужного уровня? Здесь такой совет — заложите в карьерный трек все ожидания от инженера, чтобы ему не приходилось прокачивать их в дополнительное время.

Наставничество

Изначально наставниками были эксперты внутри нашей команды. Фактически это была дополнительная нагрузка. Но если новичок изучает продукт, решает кейсы, его проверяет куратор и ведущий инженер, отличный от куратора, то почему бы ему самому не учить других новичков? Ведь он только что сдал этот продукт, а значит может быть наставником для тех, кто только начинает обучение.

Такой подход снижает нагрузку на экспертов и формирует ответственность. Эксперт понимает, что если он плохо научил новичка, тот будет плохо обучать других. В итоге, если нужные знания не переданы, нагрузка на исправление ошибок ляжет обратно на эксперта — но уже в рабочем процессе, а не в рамках обучения.

С точки зрения новичка, наставничество помогает закреплять знания. Он дополнительно пересматривает материал, с которым работал, и анализирует вопросы, которые ему задавали. Какие-то вопросы будут для него новыми, ведь он такие сам, возможно, не задавал.

Демо для команд

Можно провести демо для команды даже по уже используемым продуктам или фишкам. Так мы сразу охватим больше людей: расскажем важное новичкам и поможем обменяться лайфхаками опытным инженерам. Кроме того, материалы демо можно переиспользовать в базе знаний или курсе адаптации, ведь продукты и процессы меняются быстрее, чем мы успеваем их фиксировать.

Статьи или выступления вовне

У публичной активности много плюсов — обмен опытом, больше людей узнают о компании и экспертизе, а это позволяет быстрее нанимать людей. Но важно делиться информацией о задачах и крутых проектах и внутри компании. Я видел примеры, когда сотрудники увольнялись, а позже узнавали, что в компании были направления, которые им интересны. Некоторые даже возвращались из-за этого.

Определяем очерёдность уровней в треке

Уровни должны отличаться друг от друга не только сложностью. Посмотрим на примере:

1. Практические кейсы → инженер учится решать наши задачи на практике.

2. Задачи под ключ → инженер пытается разобраться, какие есть ещё варианты решения.

3. Наставничество → инженер сам становится наставником — не только обучает нужным «хардам» и продуктам, но и передаёт инженерные подходы, знакомит со способами взаимодействия с клиентом и с другими подразделениями.

4. Старший инженер → наставник является примером для других инженеров в команде и продолжает расти на инженерном уровне.

Так каждый предыдущий уровень готовит специалиста к следующему — получается продолженный карьерный трек.

Пример того, как выглядит специализация и конкретный уровень в HRM Nexign:

Связываем трек с личными целями и другими процессами

Допустим, от нас ушло много человек, и после найма нужно быстро адаптировать новых сотрудников. Вместо того, чтобы назначать отдельные тренинги, мы говорим: «Петя, ты хочешь двигаться дальше? Тогда выполни задачу под ключ и помоги с обучением новичков». Это значит, что он:

• проверит знания и выявит пробелы;

• посмотрит, какие задачи даются команде сложнее всего;

• запланирует обучение, исходя из реальных проблем;

• проведёт повторную проверку знаний, чтобы оценить усвоение;

• подготовит индивидуальные рекомендации;

• задокументирует ключевые моменты для базы знаний.

Получается, мы решим и бизнес-задачу — быстро адаптируем новичков, и задачу развития — поможем инженеру прокачать навыки выполнения задач под ключ.

Что учесть в содержании трека:

• Включить необходимые/поощряемые действия инженеров.

• Подумать, как переиспользовать результаты работы.

• Связать уровни карьерного развития друг с другом, чтобы полученные ранее знания помогали инженеру/команде.

• Убедиться, что задачи трека и цели инженера сочетаются.

Планируем карьерный трек эксперта

Важно на старте понять, что вы ожидаете от самых крутых инженеров. Готова ли компания платить ведущим специалистам зарплату, например, в три раза выше, чем у новичков, если их результат будет всего на 20–30% лучше? Или такие инженеры должны выполнять принципиально другие задачи?

Представьте, у вас есть болид Формулы-1 и вы хотите ставить на нём рекорды скорости. Но вместо этого ездите по городу в пробках. В дождь. Так и у меня — порой задачи экспертам приходилось придумывать, и иногда это были параллельные задачи с нашей основной работой. Мы получали хороший результат, эксперты были довольны. Но по итогу всё равно уходили — за теми задачами, которые для них более интересные и сложные.

В начале года к одному из моих тимлидов пришёл эксперт с вопросом о своей зарплате. В позапрошлом году у него были хорошие повышения, премии, его часто хвалили. В прошлом году он работал так же качественно, но признания стало меньше. Разбираясь в ситуации, мы поняли, что дело в задачах, которые он выполнял — они не отличались по сложности от тех, что решали менее опытные коллеги. Вот какое решение можно использовать в этом случае:

1. Даём честную обратную связь.

Объясняем эксперту, что дело именно в результате. Признаём, что не всегда можем придумывать для него сложные задачи, и было бы здорово, если бы он сам их находил.

2. Обсуждаем направления развития и более широкий круг задач.

Если основная команда занимается авариями, эксперт может углубиться в Problem Management и устранить причины сбоев, предотвращая их повторное появление.

3. Озвучиваем свои ожидания от применения экспертных знаний.

Как вторая линия поддержки, мы часто взаимодействуем с владельцами продуктов, аналитиками и разработкой. И, возможно, лучше многих понимаем, как используются наши продукты, какие у них проблемы и запросы от клиентов. Поэтому от экспертов хотели бы видеть предложения по улучшению продуктов, бизнес-процессов клиентов, разработке инструментов автоматизации.

Если эксперт не знает, с чего начать, мы предлагаем составить для него дорожную карту (roadmap). В ней пишем конкретные шаги, как найти идею: количество проблем, которые он должен посмотреть, доработки, которые стоит систематизировать, контакты внутри компании, с кем стоит обсудить потенциальные улучшения.

Если идей не будет, специалист не сможет перейти на следующий уровень. Но если он пройдёт все шаги, цель мы ему зачтём, и дальше вместе подумаем, что ещё сделать, чтобы появилась идея, как улучшить продукт.

4. Предлагаем изучить новые технологии и помочь их внедрить.

Эксперты могут не только предлагать новые технологии, но и помогать с их внедрением. Это часто снижает сопротивление, ведь на таких инженеров равняются их коллеги внутри команд.

Конечно, эксперты уже получают много, но для компании и команды важно, чтобы они продолжали развиваться. Подумайте, как задачи экспертов влияют на финансовые результаты:

• Укрепление IT-бренда → Быстрый наём → Экономия затрат и снижение рисков по проектам.

• Создание новой функциональности → Растёт возможность продажи.

• Снижение затрат на эксплуатацию → Экономия на лицензиях, оборудовании, поддержке.

Когда эксперт публично рассказывает о достижениях, делится техническими знаниями с сообществом, это помогает быстрее нанимать специалистов и закрывать ключевые роли в бизнес-проектах. Если он создаёт новый продукт — это возможность дополнительного дохода. Если сокращает затраты на эксплуатацию, это даёт компании гибкость в управлении ресурсами.

Тогда мне, как руководителю, проще аргументировать повышения перед HR или своим руководством: «Мы сэкономили на таком-то проекте 10 миллионов, нам не нужна дополнительная закупка оборудования, давайте запланируем повышение для тех, кто участвовал в проекте».

О чём подумать в работе с экспертами:

• Определить, выполняют ли эксперты задачи, которые не может решить никто другой в команде.

• Подумать, как вы можете помочь им находить такие задачи самостоятельно.

• Узнать, являются ли эти задачи важными для компании/бизнеса.

Ищем баланс развития (можно ли остановиться?)

Продолжая аналогию с Формулой 1: чтобы приехать первым к финишу, нужно спланировать стратегию пит-стопов. Иногда без остановок до финиша в принципе не доехать.

Мы задались вопросом, есть ли у специалиста возможность остановиться при прохождении карьерного трека? Ведь не все хотят расти (или расти постоянно). У нас такая возможность есть. Мы определили уровень (примерно смесь 3-4 уровней из 10), где инженер может остановиться и зафиксировать развитие. Здесь сотрудник сам выбирает, хочет ли он двигаться дальше после базового уровня. А он у нас не запредельный и включает сочетание практических навыков + знание основных продуктов + качество выполнения задач.

Когда инженер решает остановиться в продвижении по треку, он берёт на себя ответственность за то, что возможность его дальнейшего повышения будет зависеть от роста задач и их сложности. Если он не двигается дальше, более значимые и мотивирующие задачи, а также повышение, в первую очередь получат те, кто продолжает развиваться.

После презентации подхода в команде часть ребят сразу сказали, что в ближайшие полгода не будут повышать сложность выполняемых задач и переходить на следующий уровень. Их устраивали текущие полугодовые цели. Были и те, кого полностью устроил базовый уровень, так как в данный момент для них важнее личные приоритеты. Это нормально.

Внедрение карьерного трека

Трек в команде мы запустили только с третьего раза. Как я готовился к внедрению:

1. Обсудил критерии с экспертами и тимлидами

В первую очередь, я обсудил все критерии оценки по каждому из уровней с экспертами и тимлидами.

Будучи руководителем, даже выросшим внутри команды, важно признаться, что постепенно ты теряешь знание всех деталей работы. Как процесс решения аварий, который красиво описан, но полностью следуют ему только руководители и новички, которые изучают его на онбординге. В работе же более опытные товарищи часто подсказывают нюансы и места, где можно безопасно «срезать угол». Или делятся тем, как у них заведено работать. Поэтому важно привлекать к обсуждению уровней не только руководителей и тимлидов, но и экспертов, которые по-прежнему решают реальные задачи.

2. Провёл встречи с пилотными рассказами

Мне было важно услышать конструктивную критику и увидеть трек глазами тех, кто будет его проходить впервые. Поэтому я рассказал о треке коллегам из своей и смежных команд — как инженерам, так и руководителям.

3. Оценил текущий уровень инженеров по новому треку и обсудил с тимлидом каждого из них

Я прикинул, на каком уровне мог бы находиться каждый из 40 инженеров и что нужно для перехода на следующий уровень, если бы трек внедрили сегодня. И обсудил это с тимлидами. Это позволило понять, насколько подход реалистичен и применим к моей команде.

4. Подготовил презентацию

Рассказал о треке так, как хотел бы услышать сам — просто, доступно, как разговор в баре, а не на корпоративной встрече. Выбирал такое время, когда большинство инженеров смогли бы участвовать, не отвлекаясь на задачи или инциденты. В итоге получилось четыре встречи, по одной на каждую из команд. Можно было задать любые вопросы — я отвечал на все и не заканчивал встречу, пока не ответил на каждый.

5. Сделал запись доступной команде

Запись рассказа с тайм-кодами, презентацией и ответами на вопросы, в том числе и каверзные, опубликована в нашем Telegram-канале. Любой инженер может вернуться к материалами в удобное время.

6. Собрал обратную связь, в том числе неявную

Трек не высечен в камне, да и у нас такой цели не было. Мы хотели сделать инструмент, который поможет ребятам увидеть перспективу роста, понять, что нужно для этого сделать, а нам — вкладывать в трек задачи, которые хочет бизнес.

После презентации трека одной из команд, тимлид заметил, что его инженер воспринял изменения негативно. У меня не было такого ощущения. При личном разговоре оказалось, что инженер решил, будто в рамках трека не сможет расти дальше. Но когда вместе обсудили, что конкретно этот специалист может делать и что уже делает, его мнение изменилось. Интересно, что именно в тот момент шло согласование повышения, о котором он ещё не знал.

Что ещё помогло с внедрением:

• открытость не только в рассказе, но и в цифрах. Я говорил, сколько человек уже получили повышение, чтобы показать, что трек работает;

• фокус на долгосрочном использовании трека. Мы делали акцент на том, что пересматриваем уровни минимум раз в полгода, чтобы привязать их к личным целям и задачам инженера;

• не ждали идеального инструмента, процесса или инициативы компании. Внедрили трек в своей команде, совместив его со стандартной процедурой пересмотра зарплат.

Я видел и обратные примеры, когда в больших подразделениях, где суммарно больше тысячи человек, внедряли карьерный трек, но он не начинал работать автоматически. Один из вариантов его использования, когда руководитель звонил инженеру: «Петя, привет, ты теперь инженер пятого уровня!» — «Что? Какого уровня?» — «Не так важно, у нас появился трек, мы ещё разбираемся. Но ты молодец, продолжай работать». А были примеры, когда есть трек, но руководитель ориентируется, в первую очередь, на своё видение.

В книге «Шум. Несовершенство человеческих суждений» Даниэль Канеман с коллегами исследовали, насколько точна оценка кандидатов на собеседовании и как они проявляют себя в работе. Оказалось, что оценка руководителя совпадает с реальными результатами только в 60% случаев. Проблема в том, что мы часто смешиваем свою оценку выполненных заданий или ответов кандидата. Если он справился с самой сложной технической задачей, но не справился ещё с четырьмя другими, в нашей голове кандидат молодец и он технически очень сильный. В книге советуют разбивать оценку на конкретные критерии. В карьерном треке это уже заложено — вместо субъективных суждений ориентируемся на прозрачные уровни и ожидаемые результаты.

Какие итоги от внедрения

Инженеры включили карьерный трек в свои цели. Сразу после внедрения часть инженеров взяли цели по достижению критериев для перехода на следующий уровень.

Ведущие инженеры и эксперты начали смотреть шире. Они стали искать способы применить свои знания и улучшить наши продукты или бизнес-процессы клиентов. Да, часть идей сырая и часть из них не сработает, но важно двигаться в этом направлении.

Тимлиды лучше понимают, кого и когда повышать. Карьерный трек дал прозрачные ориентиры, которые легко объяснить бизнесу.

База знаний наполняется успешными кейсами. Мы создали структуру в Jira, где по определённым лейблам автоматически подтягиваются задачи, выполненные инженерами для перехода на следующий уровень. Эта информация доступна всей команде, и каждый может посмотреть, что реально у нас делается для перехода на новую ступень.

Прижились термины из трека. Например, термин «задача под ключ» мы теперь используем не только в общении с тимлидами, но и оценивая внешний сервис или при взаимодействии с другими подразделениями.

Основные шаги для внедрения трека:

• Определить совместно с командой/тимлидами, кем станет инженер, когда дойдёт до последнего уровня.

• Разобраться, как быстрее получать пользу от новичков.

• Оцифровать неформальные критерии, которые уже используются в команде.

• Включить нужные действия в трек, например, обучение. 

• Связать трек с целеполаганием. 

• Подготовиться к внедрению.

• Регулярно собирать обратную связь, даже неявную.

Можно ли обойтись без трека? 

Вы можете задать вопрос своему руководителю:

• Что мне нужно сделать для повышения?

• Лайфхак: а для повышения в два раза?

Я задавал руководителю оба вопроса. Ключевой момент здесь — не узнать конкретную сумму, а сделать так, чтобы руководитель задумался: «Что такого должен сделать Костя, чтобы я захотел поднять ему зарплату в два раза?»

И если вы тимлид или руководитель, обязательно спросите каждого в команде:

• Ты знаешь, что тебе нужно сделать для повышения?

Этот вопрос лучше обсуждать на встречах 1:1. Даже если вы, как руководитель, понимаете карьерный трек каждого члена команды, и ваш инженер знает, что ему нужно сделать для повышения, это не значит, что представления совпадают. Такие вещи всегда лучше проговаривать напрямую.

Полезные материалы:

• Мой канал о том, как применять новые идеи в жизни и работе, создавать команды и не бояться ошибок: https://t.me/ThoughtsAtBedtime

• Все уровни и критерии нашего карьерного трека: https://konstantin-v.yonote.ru/share/career_track_l2_nx 

• Подкаст: Podlodka #384 – Карьера в FAANG, продолжительность 2 часа, 6 минут

• Подкаст на YouTube: Секреты бигтеха от Principal Engineer в Apple. Максим Страхов|Team Lead Talks, продолжительность: 1 час 49 минут

• Статья «Как расти менеджерам: подробная инструкция на примере менеджерской линейки Авито», продолжительность: 12 минут

• Книга о компании, где нет необходимости получать повышения по должностям: «Никаких правил. Уникальная культура Netflix»