Любая программная компания рано или поздно сталкивается с проблемой должностей. Некоторые организации довольствуются «плоской» системой, но в отсутствие системы должностей возникают теневые иерархии, что на самом деле хуже. Должности дают чёткую демаркацию ожиданий от конкретного сотрудника. Например, гораздо проще возложить на ведущего разработчика ответственность за техническое руководство, если эта роль чётко определена. Без определений должностей наверх будут подниматься самые громкие, а тихие и вдумчивые останутся незамеченными.
Сложность чёткого определения должностей заключается в том, что люди пытаются обмануть систему (всегда заявляя, что они заслуживают новой должности/повышения зарплаты). Я наблюдал, как для борьбы с этим организации создают всё более длинные определения, позволяющие избегать пограничных случаев. Постепенно определения начинают занимать несколько страниц и перестают умещаться в головах. В процессе сложности системы соблюдение её правил ослабевает, а потом люди просто перестают им следовать. Я считаю, что есть более правильный путь, поэтому предлагаю следующее:
Не платите за то, сколько людей под руководством или сколько строк кода они написали. Платите им за генерируемые результаты.
Эта философия сильна и наделяет свободой. Неважно, если вы сотрудник, вносящий индивидуальный вклад (individual contributor, IC), занимаетесь техническим руководством или управлением командой. Важно то, насколько ваш вклад влияет на прибыль бизнеса.
В этом посте предлагается многоуровневая система, которую можно применять к IC, техническим руководителям и руководителям команд.
- Уровень 1 — задачи с чётко определённым масштабом
- Уровень 2 — проекты с чётко определённым масштабом
- Уровень 3 — проекты без чётко определённых масштабов
- Уровень 4 — умножающий силу всей команды
- Уровень 5 — умножающий силу всей группы
- Уровень 6 — умножающий силу всей компании
В посте я обозначу эти уровни с L1 по L6. Предлагаемая система имеет множество основополагающих правил, которые перечислены ниже.
Правило 1: с ростом влияния работника на бизнес должна расти и компенсация труда (измеряемая по уровню).
Правило 2: с ростом компании и снижением рисков философия начисления компенсации труда должна меняться, место доли в компании должна занимать зарплата.
Правило 3: когда компании очень малы, названия должностей обычно не важны, а когда они становятся очень большими, уровни с L2 по L6 обычно расширяются сеньор-должностями.
Правило 4: с ростом компании придётся периодически понижать сотрудников в уровнях (точкой отсчёта может быть число Данбара).
Правило 5: IC и руководители имеют одинаковый масштаб, потому что сотрудников измеряют по их влиянию на бизнес. IC шестого уровня редки, но вполне могут существовать.
Если вы стартап, использующий в качестве солидной части компенсации долю, то люди будут более мотивированы успехом компании, чем повышением своих уровней. Иными словами, лучшим путём к финансовому процветанию будет принятие решений, максимизирующее успех бизнеса, а не собственное положение внутри бизнеса. В такой среде полезнее воспринимать уровни как основу для измерения и обсуждения влияния на бизнес, чем как структуру для компенсаций.
Эта система хорошо работает для организаций, в которых от 25 до 1500 инженеров (от 100 до 4000 сотрудников). Повторюсь, в нижней части этого диапазона не стоит делать слишком большой упор на должности/уровни, но неплохо было бы познакомить сотрудников с этой концепцией.
Думаю, важно начинать с самого начала. В этом посте мы обсудим:
- мою философию компенсации труда (включая влияние на бизнес и дефицит ресурсов),
- более глубокое объяснение всех шести уровней
- снижение уровней сотрудников с ростом компании.
Философия компенсации труда
Философия проста: компенсация должна служить цели максимизации дохода, минимизации затрат или снижению рисков для финансовых потоков и максимизации прибыли.
Сравнение сотрудников с высокими и низкими показателями. Красная точка — общая компенсация труда, зелёная точка — генерируемая сотрудником ценность для бизнеса
Фундамент работы бизнеса — создание товара или услуги, которая стоит клиентам больше, чем затраты на неё. Компенсация труда сотрудников обычно состоит из непропорционального количества этих затрат на изготовление. В случае некоторых сотрудников можно думать о компенсации с точки зрения доходности по инвестициям (return on investment, ROI) в рамках фискального года, но в сфере разработки мы обычно думаем о ROI с точки зрения накапливаемой за несколько лет выгоды. В случае стартапов для полного восполнения ROI может потребоваться 5-10 лет, и только благодаря вашим первым сотрудникам вы сможете продержаться так долго. Думайте об этом так:
Каждая должность имеет влияние на финансовые показатели компании, даже если измерить это влияние сложно. Коммерческая компания должна всегда платить людям меньше, чем генерируемые ими средства, и стремиться максимизировать дельту между этими двумя числами. Минимальная компенсация зависит от востребованности на рынке этой должности (спрос/предложение). Идеальный уровень и план компенсаций должен создать систему, мотивирующую к увольнению плохих сотрудников и к росту средних и ценных сотрудников с целью максимизации показателей бизнеса. Это привело меня к следующим выводам:
- Каждая должность на достаточно долгом промежутке времени должна генерировать прибыль или снижать затраты.
- Коммерческая компания всегда должна платить людям меньше, чем генерируемые ими средства (в долговременной перспективе).
- Компенсация по рынку напрямую связана с дефицитом ресурсов.
- Коммерческая компания должна стремиться максимизировать дельту между компенсацией труда сотрудника и положительным влиянием на финансовые показатели.
- Наилучший способ максимизации дельты — это фокус на повышении генерируемой выгоды, а не на снижении суммарной компенсации.
Более глубокое объяснение шести уровней
В таблице ниже использован подход «снизу вверх»; в ней рассматривается каждый уровень компенсации по увеличению степени влияния на бизнес. Смысл в том, что чем ниже вы опускаетесь в таблице, тем выше влияние в компании. С ростом сотрудников в уровне они начинают переход от зависимых к независимым, а потом и к взаимозависимым (см. 7 навыков высокоэффективных людей Стивена Кови). Одновременно они становятся всё более ответственными за результаты для бизнеса (а не за техническую специфику).
▍ L1 — задачи с чётко определённым масштабом: стажёры и новички
Зависимые и не отвечают за результаты для бизнеса
Обязанности: L1 выполняет задачи, в которых нет или почти нет никаких неопределённостей, и масштаб которых уже установлен более опытным инженером. Обычно у каждого L1 есть назначенный ему ментор L3, помогающий в выполнении задач и позволяющий L1 выбираться из тупиков.
Показатели недостаточной производительности: это состояние приемлемо не более трёх месяцев, поэтому подходит для стажёров и новых сотрудников. Если человек не повысил свой уровень за первые 90 дней, то это говорит о существенной проблеме.
Готовность к повышению уровня: сотрудник способен сам решать задачи на техническом уровне и ему можно доверить пройти собственный путь от А к Б в проекте, при этом созданное ими решение будет технически надёжным и поддерживаемым. Он участвовал в полном жизненном цикле проекта, от создания до поддержки.
▍ L2 — проекты с чётко определённым масштабом: разработчик ПО
Зависим и не отвечает за результаты для бизнеса
Обязанности: L2 зависит от более опытного инженера, имеющего больше контекста бизнеса, чтобы принимать окончательное решение по техническим компромиссам, приоритизации фич или планке необходимого качества. Ожидается, что L2 выполняет задачи согласно плану, поэтому не отвечает за изъяны в самом плане. L2 доверяют быть в очереди поддержки.
Показатели недостаточной производительности: сотрудник не успевает выполнять свою работу вовремя и эффективно сообщать о препятствиях. Кроме того, большинство сотрудников L2 должно находиться на пути к L3, занимающем один-два года.
Готовность к повышению уровня: сотрудник берёт на себя ответственность за свои проекты, в том числе за межкомандные коммуникации и за технические решения. Можно проверить его на небольшом проекте без чётко заданных масштабов и посмотреть, может ли он выпускать фичи вовремя и в рамках бюджета, а также удовлетворяет ли результат клиента.
▍ L3 — проекты без чётко определённых масштабов: сеньор-разработчики и руководители команд
Независим и ситуационно отвечает за результаты для бизнеса
Обязанности: ключевое понятие для L3 — это «доверие». Вы верите, что он будет успешным в разнообразных проектах лишь с небольшим надсмотром со стороны L4/L5. Вы верите, что при необходимости он остановит работу, привлечёт к решению L4/L5 и изменит курс, если это требуется. Это идеальное рабочее место, и команда из L3 — это сила, с которой нужно считаться. Большинство (>50%) разработчиков ПО на протяжении всей своей карьеры остаётся на уровне L3.
L3 может быть руководителем команды или IC. Руководители могут отвечать за команду из двух-трёх человек. Они отвечают за исполнение, а не за карьерный рост или направление. Они работают в рамках обратной связи, структуры и направления команды (feedback, structure, direction, FSD), заданных техническим директором (Engineering Manager).
Показатели недостаточной производительности: вы теряете доверие к их способности к выполнению задач и начинаете сомневаться, что можно доверять их результатам. У них всегда есть оправдания провалам проектов, и это всегда не их вина.
Готовность к повышению уровня: L3 начинает работать за пределами своей ответственности и стремится изменять FSD команды. В случае IC это происходит в виде стимулирования технического роста команды, предложений новой архитектуры, организации инициатив по устранению важнейших технических долгов и становление центральной точкой технического руководства. В случае руководителей это происходит в виде стремления более глубоко участвовать в сборе и планировании требований, а также в карьерном росте.
▍ L4 — умножающий силу всей команды: ведущие разработчики и технические директора
Взаимозависим и отвечает за результаты для бизнеса
Обязанности: умножающие силу всей команды — это люди, увеличивающие влияние команды гораздо сильнее, чем вклад отдельного сотрудника (в качестве опорной точки можно взять троекратный рост). Это значит, что разработчик постоянно выходит за рамки собственной должности и двигает вперёд всю команду. Руководители команд и технические руководители делают это при помощи систем обратной связи, структуры и направления. Наглядный пример:
- Хороший специалист по проверке кода — это L3.
- L4 начинает читать информацию о том, как стать хорошим специалистом по проверке кода, стремится устанавливать анализаторы качества кода в кодовую базу и создаёт обучающие руководства по практикам проверки кода команды.
Другие разработчики почти сразу понимают, что перед ними L4, потому что он осязаемо влияет на всю команду. Можно одновременно быть IC и L4, но такое случается редко. Подразумевается, что их код в три раза эффективнее, чем у L3. Однако такое может происходить, когда внутренний код специализирован (аэродинамические алгоритмы, ИИ, планировщик в жёстком реальном времени и так далее).
Показатели недостаточной производительности: когда L4 ниже своего уровня, вся команда в целом страдает от снижения качества продукта и скорости выпуска фич. Обычно это результат плохих решений, отсутствия систематической работы или неспособности увеличения масштаба практик в соответствии с постоянно растущей сложностью команды.
Готовность к повышению уровня: как и L3, сотрудник L4 готов к становлению L5, когда он постоянно выходит за рамки своей локальной экосистемы (команды) и думает о макроокружении. Вы заметите, что они помогают другим командам с их FSD, активно участвуя в их планировании и руководстве. Сотрудникам L4, которые хотят стать L5, не нужна мотивация, чтобы перейти на следующий уровень, они к этому стремятся.
▍ L5 — умножающий силу группы: главные инженеры и директора
Взаимозависим и отвечает за результаты для бизнеса
Обязанности: L5 — это то же для L4, чем L4 является для L3. Они умножают силу умножающих силу. Это значит, что они могут действовать практически без вмешательства в сфере метаразработки. Это руководители руководителей; каждый технический директор существенно эффективнее в результате руководства L5. Технических L5 можно встретить гораздо реже, но они существуют. Это люди, которые или занимаются менторством ведущих разработчиков, или принимают архитектурные решения, влияющие на целые группы.
Показатели недостаточной производительности: как и в случае с L4, нужно смотреть на весь продукт как на отражение способностей к руководству. В случае предоставления адекватной автономности L5 имеет существенные способности к реструктуризации своего мира так, как посчитают это необходимым. Они управляют наймом, составом команд, целями и делегированием ответственности. Если сочетание всего этого приводит к получению плохого продукта, то рекомендую их заменить.
Готовность к повышению уровня: планка компенсаций и ответственности на этом уровне довольно высока и сильно зависит от контекста бизнеса. Даже между директором и вице-президентом требуется существенная смена в навыках.
▍ L6 — умножающий силу компании: вице-президент или head of engineering
Взаимозависим и отвечает за результаты для бизнеса
Обязанности: L6 мыслят системно, их основная задача — организация людей для получения существенных результатов. Это следующий слой между высшим руководством и остальной частью компании. В разработке основная задача вице-президента — обеспечение свободы команды руководителей в максимизации показателей благодаря качественной организации масштабирования и повседневных мелочей в компании.
Пример: когда head of infrastructure (новый) впервые общался с Марком Ц., он сказал: «Надеюсь, мы встречаемся в последний раз». Он имел в виду, что с этого момента Марк должен будет перестать заботиться о масштабируемости архитектуры и сосредоточиться только на том, что разрабатывать дальше.
Показатели недостаточной производительности: как говорилось выше, вице-президент не справляется со своими обязанностями, если не может отвечать потребностям бизнеса так, чтобы высшему руководству не приходилось думать о максимизации показателей.
Как работают с инициативами бизнеса на каждом из уровней
Ещё один способ объяснения уровней — пойти сверху вниз. В этом случае смысл в демонстрации того, как ключевые инициативы бизнеса трансформируются из инициатив верхнего уровня до конкретных задач, выполняемых L1. Эти примеры очень специфичны и могут не подойти для вашей конкретной организации.
| Уровень | Пример DevOps | Пример разработки фронтенд-ПО |
| Решаемая задача | Компании необходимо запустить критически важную бизнес-инициативу, чтобы повысить стабильность для удержания клиентов (вспомним о Friendster). | Существует потребность в новом продукте, требующем существенных объёмов фронтенд-разработки, но в компании это ограниченный ресурс. |
| L6 – умножающий силу компании | Создаёт SRE-организацию для решения задач стабильности.
L6 принимают решения, определяющие способы работы компании вплоть до её ядра. В этом случае они реструктуризируют компанию, изменяют направление найма и изменяют способ развёртывания и поддержки сервисов. При неправильной реализации это будет иметь огромные культурные и финансовые последствия, то есть такое решение влияет на всё компанию. |
Выявляет потребность в создании новой организации для разработки продукта.
Инициатива по созданию новой линейки продуктов может преобразовать бизнес и, скорее всего, будет встречена с большой степенью сопротивления и политических дрязг. Однако именно этот вид работы оказывает больше всего влияния на прибыли компании. Неспособность создания крепкого нового продукта может быть разрушительной для будущего компании. |
| L5 – умножающий силу группы | Снижает время восстановления после выхода из строя сервисов группы
Уровню L5 делегируется владение группой наподобие SRE, а затем передаётся бизнес-инициатива. Он отвечает за выбор метрики, на которую должна ориентироваться группа. Именно L5 определяет организационную структуру, руководителей и состав команды. В этом конкретном случае он может создать отдельную подгруппу для приобретения или разработки инструментария, которым будут пользоваться другие команды SRE. Сотруднику L5 требуется L6, чтобы тот оказывал влияние на компанию в целом и настраивал способ взаимодействия группы со всеми другими группами (разработки, поддержки и так далее). |
Создаёт организационную структуру, в том числе и команду, которая будет заниматься фронтенд-разработкой.
L5 занимается подготовкой «поля боя» и подбором подходящих военачальников; его успех измеряется как общий успех в руководстве группой. В данном случае L5 может выяснить, что узким местом является фронтенд-разработка и создать команду, занимающуюся обеспечением эффективности группы. |
| L4 – умножающий силу команды | Обеспечивает команде разработки возможность снижения времени восстановления после сбоев при помощи данных (платформы метрик).
L4 организует усилия группы по исследованию недостатков, сбору обратной связи и в конечном итоге придумывает способ решения проблемы. Он обнаруживает, что проблема заключается в недостатке метрик и решает её проведением исследований, выбором инструментов и интеграцией платформы данных метрик в экосистему. То есть мы измеряем показатели L4 как метрику времени восстановления, а не по степени использования инструмента. Сотруднику L4 необходим L5, чтобы тот указал ему на конкретную предметную область и предоставил автономию и персонал для получения результатов. |
Определяет, что наилучшим инструментом для повышения продуктивности группы является Storybook.
L4 отвечает за организацию усилий группы по исследованию проблемы, сбору обратной связи, и в конечном итоге придумывает решение для повышения продуктивности фронтенд-разработчиков. В этом случае он может прийти к выводу, что лучшим путём дальнейшего развития может быть библиотека компонентов UI, удобная и для дизайнеров, и для разработчиков. Сотруднику L4 нужен L5, чтобы тот помог во внедрении инструмента во всей группе, особенно если в кривой обучения возникают отстающие, которым нужна поддержка. |
| L3 – проекты без чётко определённых масштабов | Выбирает платформу метрик и интегрирует её в систему.
L3 отвечает за продвижение вперёд решения нечётко поставленной задачи и имеет свободу в выборе пути к решению. Он может спокойно игнорировать общие стратегии команды и сосредоточиться на глубокой работе с конкретным проектом. Сотруднику L3 нужен L4, чтобы тот указал ему на конкретную инициативу с обратной связью и руководством относительно того, как она согласуется с инициативами более высокого уровня. |
Создаёт компоненты Storybook.
L3 регулярно проводит совещания с дизайнерами и фронтенд-разработчиками, выбирает компоненты с наибольшим приоритетом и создаёт их. Он отвечает за отслеживание уровня применения инструментов, реагирование на обратную связь и так далее. Обладает автономностью во внесении изменений, повышающих продуктивность разработчиков. Сотруднику L3 нужен L4, чтобы тот донёс видение и осуществлял руководство, но после этого он способен превратить это видение в реальность. |
| L2 – проекты с чётко определённым масштабом | Создаёт демо четырёх конкретных фич Datadog
L2 — это исполнитель. Ему дают чёткий масштаб работ и ожидают их выполнения. Он не отвечает за стратегию проекта, только за свою часть работы. Сотруднику L2 необходим L3, чтобы тот указал ему конкретные задачи на выполнение. |
Создаёт все компоненты для <конкретного сценария использования>
Обратите внимание на разницу в тональности между L3 и L2. Сотруднику L3 предоставляется автономность в организации, исполнении и итерациях так, как он посчитает необходимым, а L2 выдают конкретную предметную область для решения задачи. Ему выделяется чётко очерченная сфера, но не конкретный список дел на каждый день. Сотруднику L2 нужен L3, чтобы тот взял на себя все взаимодействия с командами дизайнеров/разработчиков, а L2 мог тратить основную часть своего времени на работу. |
| L1 – задачи с чётко определённым масштабом | Развёртывает агент Datadog на всех Linux-хостах.
Сотруднику L1 даётся конкретная задача и он не отвечает за принятие решения о том, подходит ли в данном случае Datadog. В его труде нет никаких неопределённостей. Сотруднику L1 нужен L2/L3, чтобы тот выделил ему конкретную задачу для исполнения. |
Создаёт три конкретных компонента.
L1 дают настолько конкретное задание, что весь остальной контекст (повышение производительности) в его картине отсутствует. Сотруднику L1 нужен L3, чтобы тот ежедневно выдавал ему работу. |
Как IC и руководители умещаются на одном уровне
В таблице ниже приведены различия между руководителями команд, техническими руководителями и IC. Фундаментальный принцип этой системы уровня разработки заключается в том. что сотрудников вознаграждают за повышение степени влияния, а не за выслугу лет или количество непосредственных подчинённых. Однако мне кажется, что эта визуализация будет полезной тем, что позволит IC, техническим руководителям и руководителям команд понять, по каким путям они могут пойти, чтобы достичь одинакового уровня.
| Уровень | IC | Технические руководители | Руководители команд |
| L1 | Не доверяют исполнение без ментора | - | - |
| L2 | Не доверяют работать над проектом независимо | - | - |
| L3 | Доверяют независимую работу над большинством проектов | - | Управляет небольшой командой из 2-3 человек |
| L4 | Результаты в три раза выше, чем у L3 | Устанавливает техническую обратную связь, структуру и руководство командой | Устанавливает обратную связь, структуру и руководство командой |
| L5 | Результаты в десять раз выше, чем у L3 | Устанавливает направление и архитектуру для всей линейки продуктов | Устанавливает направление и архитектуру для всей группы. Предоставляет обратную связь и занимается ростом руководителей. |
| L6 | Результаты в сто раз выше, чем у L3 | Устанавливает техническое руководство и видение качества кода для всей компании | Создаёт структуру разработки для всей компании. Выращивает руководителей руководителей. |
Как IC может быть L6?
Чтобы вносящий индивидуальный вклад сотрудник смог достичь L6, он должен своим вкладом влиять на всю компанию. То есть его можно назвать 100x-инженером (этого человека можно обменять на 100 разработчиков). Теоретически это возможно, но сильно зависит от ситуации. Пример:
- инженер AWS, в одиночку переписавший <название фичи>, повысив её эффективность на 30% (сэкономив компании миллиарды на оборудовании).
Хотя сравнение может выглядеть натянутым, такова реальность в других областях, например, в спорте. Баскетболист Стефен Карри зарабатывает ежегодно $45 миллионов, а главный тренер всего $5 миллионов, из-за чего тренер оказывается на восьмом месте в списке самых высокооплачиваемых людей в команде. Это вызвано тем, что Карри как конкретный человек генерирует непропорционально большую долю успеха команды (а значит, и прибыли при помощи продаж билетов и рекламы). В разработке дефицитными ресурсами обычно оказываются технические руководители и руководители команд, и лишь немногие инженеры стоят в девять раз больше своих коллег.
Снижение уровней сотрудников с ростом компании
Можно и не говорить о том, что если инженер не дотягивает до своего уровня, у вас есть проблема. Нельзя оставлять людей на сеньор-должностях, если они не являются хорошими примерами для остальных. Это заметят все, и такая ситуация снизит ответственность сотрудников.
С ростом компаний в размерах (25 → 250 → 2,500) аналогично растут технические и лидерские сложности. На такие должности вырастают некоторые из людей, которых вы наняли изначально, но другие не справляются, поэтому их нужно или понизить в уровне, или уволить. Я считаю, что можно сильно облегчить процесс снижения уровня сотрудников, если сообщить им об этом заранее. Но для начала давайте поговорим о том, почему вообще должно происходить снижение уровня.
- Со временем растёт сложность — чем больше кодовая база, тем сложнее вносить в неё существенные изменения.
- Со временем нарастает инерция — как бы ни стремилась ваша компания всегда оставаться гибкой, чем дольше вы в бизнесе, тем больше аспектов переходит в категорию «у нас это делается именно так». Будь то процесс анализа годовой прибыли или планирования спринтов, со временем становится всё сложнее трансформировать конкретные идеи.
- Со временем усиливаются последствия — когда компания мала и зарабатывает ежегодно по $1 миллиону, то для удвоения прибыли нужен ещё $1 миллион. Для удвоения прибыли Google потребуется больше, чем весь ВВП Гватемалы. Если взять масштабы Walmart, то от решений, принимаемых руководством этой компании, зависят три миллиона людей.
По перечисленным выше причинам нельзя сравнивать ведущего инженера Google Ads с ведущим инженером в стартапе из десяти человек. Требования к должности и последствия слишком отличаются. Что же делать с ведущим инженером, нанятым среди десяти первых сотрудников, если его навыки не выросли настолько, чтобы соответствовать компании из 250 человек?
Прежде чем ответить на этот вопрос, давайте рассмотрим ещё одно ключевое различие: Google может позволить себе платить $750 тысяч в год инженеру, способному принимать решения, влияющие на миллиарды долларов. Стартап этого делать не может (и не должен). Однако с ростом стоимости стартапа растут и диапазоны зарплат, поэтому я рекомендую следующее:
При достижении стартапом основных показателей роста, проводите изменения в диапазонах компенсации труда и меняйте должности сотрудников.
Ведущий разработчик, способный принимать хорошие решения, влиявшие на десять человек, может начать испытывать проблемы с управлением пятьюдесятью людьми. Руководитель команды, успешно управлявший командой разработки на ранних этапах, возможно, в дальнейшем должен будет перейти на другую должность.
Если вы заранее предупреждаете сотрудников, что сложность их должностей повысится, в дальнейшем вам гораздо проще будет помочь совершить переход большинству из них.
Я был свидетелем того, как такая информация сообщалась по факту и отдельным людям; разговоры при этом оказывались гораздо тяжелее. Если вместо этого такое событие будет распространяться на всю компанию, то смена должностей не станет особой проблемой, особенно если скоординировать её с повышением диапазонов компенсаций. Благодаря организации скоординированного события вы сможете вносить множество изменений одновременно и не растягивать их.
Подведём итог
Философия компенсаций труда — сложная тема, и её очень легко переусложнить. Я считаю, что компенсации в зависимости от влияния на компанию — это более простая и честная методика, чем попытки учёта всех возможных обязанностей и работ. В конечном итоге, она согласует мотивацию бизнеса и сотрудников: их вознаграждают за результат их работы, повышающий самые важные метрики компании (прибыль, снижение затрат или уменьшение рисков в ключевых областях).
Предлагаемая система уровней:
- Уровень 1 — задачи с чётко определённым масштабом
- Уровень 2 — проекты с чётко определённым масштабом
- Уровень 3 — проекты без чётко определённых масштабов
- Уровень 4 — умножающий силу всей команды
- Уровень 5 — умножающий силу всей группы
- Уровень 6 — умножающий силу всей компании
Эта система применима к сотрудникам, вносящим индивидуальный вклад, техническим руководителям и руководителям команд. Её можно использовать с командой и из двадцати инженеров, и из пятисот. Постепенно эта система дополняется сеньор-должностями, обеспечивающими карьерный путь с большим количеством возможностей.
Автор:
ru_vds
