У нас в компании нет грейдов — и это прекрасно

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

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

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

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

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

Грейды — это в том числе описания «функций» сотрудников, которые находятся в прямой зависимости от компетенций. Также это некоторые «уровни» в зависимости от ценности, которую сотрудник может принести.

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

Вот какие недостатки модели деления на классические уровни мы заметили.

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

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

Деление функций по грейдам часто выглядит искусственно и создает ненужные ограничения. Часто у грейдов есть временные рамки. Допустим, чтобы перейти из джуна в миддла, нужно два года. Эта норма устанавливается как средняя температура по больнице и иногда служит искусственным ограничителем роста зарплат. Она также способствует застреванию человека в каком-то статусе. И джун и синьор на самом деле выполняют одни функции, но на проектах разной сложности. При этом в зависимости от грейда не должны меняться ожидания от уровня качества и самостоятельности. «Так-себе программист» (джун во многих компаниях) — это не маленький плюс для компании, а настоящий минус.

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

В итоге мы в SmartHead отказались от системы грейдов. Часто это инструмент больших компаний, которым необходимо «просеивать» людей.

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

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

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

У нас в команде дружественная атмосфера: стараемся сделать ревью не экзаменом, а местом синхронизации точек зрения на вклад, компетенции и ожидания.

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

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

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