Около полутора лет назад мы развернули карьерный рост для инженеров Poll Everywhere. Я систематизировал свои размышления об этой работе в виде пошагового руководства по определению лестницы индивидуальных участников для вашей группы инженеров.

Poll Everywhere была основана в 2007 году тремя инженерами с опытом консультирования. Наша команда инженеров внедрила этот прогресс только в 2018 году. 11 лет - это долгий срок без формальных уровней.

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

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

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

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

Вдохновить инженеров, что есть что-то, выходящее за рамки их текущего уровня квалификации
Расширение возможностей позволяет активнее участвовать в повседневном принятии решений по проектам.
Командный бай-ин для лестницы
Избегайте бесцельной проверки задач в списке только для продвижения
Изучите пейзаж
Я начал с того, что широко изучил отрасль SaaS, чтобы увидеть, как организованы наши крупнейшие компании. Levels.fyi помог мне понять структуру в таких местах, как Facebook, Apple, Netflix и Google.

У этих чудовищ было намного больше уровней, чем имело смысл для нашей команды из 20 инженеров. Я не мог определить достаточно технических проблем, чтобы оправдать 5 или 6 уровней, не говоря уже о старшем научном сотруднике уровня 11 Poll Everywhere . У меня получилось 4 уровня, изначально называвшиеся

Младший
Середина
Старший
Директор
Решив, что с организационной точки зрения мы не можем поддерживать столько уровней, сколько технологические гиганты, я обратился к компаниям, которые по размеру были ближе к Poll Everywhere. Rent the Runway, Buffer и Basecamp публикуют свой карьерный рост.

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

Автономия
Программист Basecamp Junior: Работа тщательно проверяется, и перед слиянием часто требуется существенная обратная связь.
Программист Basecamp: Работа пересматривается, время от времени требуется существенное изменение направления или реализации.
Старший программист Basecamp: Работа не обязательно должна быть пересмотрена, но общий подход может быть.
Ведущий программист Basecamp: Работа происходит полностью автономно, без регулярной проверки.
Главный программист Basecamp: полностью способен разрабатывать, владеть и запускать совершенно новые, новаторские системы (проектирование биллинговых систем, Trix, Active Record с нуля)
Техническое мастерство
Младший программист: основные языковые функции освоены, но некоторые расширенные структуры могут быть незнакомы.
Старший программист: глубокий опыт как минимум в одной среде программирования.
Ведущий программист: глубокий опыт работы в различных средах программирования.
Главный программист: широко признан в отрасли за существенный вклад в современные разработки. Придумывает новые концепции, регулярно продвигает вперед всю организацию.
Последовательность
Младший программист: Иногда возникают проблемы, связанные с шаблонами и подходами в рамках существующего кода.
Программист: легко следует установленным шаблонам и подходам в рамках существующей кодовой базы.
Наставничество
Старший программист: может предоставить материальный отзыв о работе младших программистов и программистов.
Объем работ
Младший программист: работает в основном над рутинными задачами с жестким охватом.
Старший программист: Работа не обязательно должна быть пересмотрена, но общий подход может быть. Полностью способен реализовать важные функции от концепции до поставки в качестве единственного программиста (наряду с дизайнером).
Ведущий программист: Работа происходит полностью автономно, без регулярной проверки.
Главный программист: может создавать и руководить целым отделом, например SIP, Core Product или Research & Fidelity.
Соответствующий опыт
Младший программист: обычно менее 2 лет опыта работы профессиональным программистом в определенной области.
Программист: Обычно не менее 2-5 лет опыта работы профессиональным программистом в определенной области.
Старший программист: обычно не менее 5-8 лет опыта работы профессиональным программистом в определенной области.
Ведущий программист: обычно не менее 8-12 лет опыта работы профессиональным программистом в определенной области.
Главный программист: Обычно минимум 12-15 + лет опыта работы профессиональным программистом в определенной области.
Сделать шаблон
Я обобщил категории на обязанности, применимые к каждому инженерному уровню.

ИНЖЕНЕР X - ДОЛЖНОСТЬ
Как проделана работа? Кто решает, как тратить время инженера?
Какой уровень решения проблем они применяют в своей работе?
Насколько развиты их технические навыки?
Насколько последовательна их работа?
Насколько эффективно они справляются с несколькими обязанностями?
Насколько широко они видят свою работу?
Сделай их своими
Этот шаблон был довольно хорош, но казался слишком общим. На этом этапе я объединил ценности компании и существующие критерии эффективности, чтобы сделать ее более узнаваемой в Poll Everywhere.

ИНЖЕНЕР X - ДОЛЖНОСТЬ
Как проделана работа? Кто решает, как тратить время инженера? Люди и команда, Суждение, Доставка
Какой уровень решения проблем они применяют в своей работе? Контент, Доставка
Насколько развиты их технические навыки? Инструменты и процессы
Насколько последовательна их работа? Инструменты и процессы, Суждение
Насколько эффективно они справляются с множеством обязанностей? Суждение
Насколько широко они относятся к работе? Суждение
Что они делают, чтобы продолжать учиться? Стремитесь расти
Масштабируйте их
Затем я применил шаблон с большим объемом и влиянием для каждого повышающегося уровня инженерии. По возможности я использовал внутренний язык, чтобы описания были более знакомыми.

ИНЖЕНЕР I - МЛАДШИЙ ИНЖЕНЕР
Большая часть работы назначается эпическим лидером или PM. Ожидается, что существенное взаимодействие и итерация произойдут до объединения кода. Люди и команда, Суждение, Доставка
Работает ли разработка в рамках функций или специализаций других людей. Исправляет ошибки, вносит изменения и реализует функции, конкретно определенные в Pivotal Stories. Контент, Доставка
Базовые языковые функции освоены, но продвинутые концепции могут быть недоступны. Инструменты и процессы
Может быть предложено следовать шаблонам, определенным в существующей кодовой базе. Инструменты и процессы, Суждение
Может потребоваться сосредоточиться на одной задаче и выполнить ее перед тем, как двигаться дальше. Работа над расстановкой приоритетов в работе по ценности. Суждение
Могут сформулировать контекст своей текущей истории. Суждение
ИНЖЕНЕР II - СРЕДНИЙ ИНЖЕНЕР
Работа проверена. Ожидается, что работа иногда требует изменений в архитектуре, дизайне или реализации, но их необходимо пересмотреть в нужное время. Люди и команда, Суждение, Доставка
С легкостью следует установленным шаблонам и подходам в рамках существующей кодовой базы. Инструменты и процессы
Работает в основном с четко определенными и ограниченными отдельными функциями или проблемами. Не часто определяет следующие шаги или самостоятельно обнаруживает неизвестное. Содержание, суждение, доставка
Может сформулировать контекст текущего спринта. Суждение
ИНЖЕНЕР III - СТАРШИЙ ИНЖЕНЕР
Работу не обязательно нужно пересматривать, но архитектура и общий дизайн требуют ввода. Решение, Доставка
Младшие программисты просят ваших отзывов как надежных экспертов. Содержание, суждение
Владелец нескольких сервисов в системе. например, Rails App, Viz, Mobile, Poll Renderer, Apps. Содержание
Ставит во главу угла собственное время для достижения более чем одной цели на уровне или выше ожиданий. Включает текущие обязательства и ответственность вместе с их основным проектом. Сосредоточен на самых важных деталях и сводит к минимуму разбивку велосипедов. Решение, Доставка
Последовательно участвует во всех частях создания эпопеи, включая архитектуру, планирование проекта, коммуникацию, документацию и исполнение. Считается важным для успеха проекта. Полностью способна перенести важные функции от концепции до доставки. Поиск решения, контент, доставка
Постоянно инвестирует в личное развитие и приносит знания остальной части команды (например, читая книги, блоги, статьи, посещая конференции или участвуя в программном обеспечении с открытым исходным кодом). Стремление к росту.
Может сформулировать контекст текущего эпоса. Поиск решения, суждение
ИНЖЕНЕР IV - ГЛАВНЫЙ ИНЖЕНЕР
Полностью способна разрабатывать, владеть и запускать совершенно новые эпические произведения с нуля, особенно когда идеи неоднозначны и не полностью конкретизированы. Поиск решения, содержание, суждение
Возможность сделать шаг назад и увидеть систему в целом, подвергнуть сомнению существующие предположения и значительно упростить или улучшить дизайн. Поиск решения, Стремление к росту, Суждение
Включены в сообщество, чтобы иметь возможность узнавать и оценивать состояние дел, включая то, что принесет пользу PE. Стремление к росту, Инструменты и процессы, Суждение
Придумывает новые концепции, регулярно продвигает вперед всю организацию. Поиск решения
Действует как усилитель во всей инженерной организации, заставляя целые команды работать более эффективно. Стремление к росту, Суждение, Люди и команда
Может сформулировать контекст всех текущих проектов и последствия для будущей работы и наших будущих продуктовых предложений. Время и сложность. Поиск решения, Стремление к росту, Суждение
Обзор с вашими тренерами
Я начал со своих коучей, включив их отзывы, а затем открыл их остальным нашим инженерам, стремясь к общему консенсусу.

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

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

Только что прочитав Turn the Ship Around (позже Shape Up подтвердил это мнение), я хотел дать возможность инженерам проекта управлять своей судьбой. Я утверждал, что даже очень технические менеджеры проектов не будут знать подробностей так же хорошо, как человек, реализующий функции.

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

Применить их
Сядьте с каждым тренером и пройдите уровни, чтобы увидеть, как работа их коучей соотносится с ожиданиями их текущей роли и той, которая находится выше. Как правило, мы ожидаем, что люди будут регулярно выполнять около 75% следующего уровня перед официальным повышением.

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

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

Вот наша копия по состоянию на октябрь 2020 года и изменения, которые мы предложили после первого года.

Выводы
Имена для ролей
Я сделал ошибку. Определение инженерной лестницы для Poll Everywhere фокусирует ожидания вокруг ценности Poll Everywhere как бизнеса. Однако названия должностей, используемые во всей отрасли, имеют неявный смысл. Инженеры часто имеют предвзятые представления о том, что значит быть младшим или директором. Вдобавок к этому вы можете оказаться в ситуации, когда у вас будет уровень кого-то с большим опытом работы в отрасли, но меньшим опытом в вашем конкретном бизнесе или навыками, которые ваш бизнес ценит ниже, чем они ожидали.

Я бы посоветовал вам не смешивать названия с уровнями, если вы не определяете уровни для очень большой компании. Наш внутренний язык определяет Software Engineer 2.x, где 2 означает второй уровень нашей лестницы IC Engineer, а x равен 1, 2 или 3 для описания их навыков на этом уровне.

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