Карьерный рост из senior: кто такой staff-инженер?
Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер». У нас в компании это один из грейдов технической ветки развития инженеров, которую мы обобщенно именуем «Staff-инженер».
Считаю, в IT-индустрии есть большой запрос на формализацию карьерного роста за рамками senior-грейда, особенно в больших компаниях. Подтверждение тому, жаркий круглый стол »Есть ли жизнь после сеньора» с конференции Dump-2024. Участие в нем в качестве зрителя (и местами комментатора), а также стандартизация роли staff-инженера в Купере, привели меня к написанию статьи, в основе которой обобщенный опыт десятка моих коллег, staff-инженеров из Купера, с которыми я провел интервью, вдохновившись второй частью книги Вилла Ларссона.
Цель статьи — сформировать у senior-разработчика общее представление о роли стафф-инженера, как об одном из направлений карьерного роста. А также дать практические советы, что прокачивать, на случай, если описанные трудности вас не отпугивают.
Статья будет состоять из двух частей, в этой части разберем, чем занимаются стафф-инженеры, и что вас ожидает в этой роли. Приступим!
Терминология
Если кратко, staff-инженер — это сеньорный сеньор, работающий индивидуально (individual contributor). Сильный технарь с большим влиянием на технологическое направление компании. Помимо глубокого технического мастерства он практикует управление большими проектами и имеет соответствующие для этого навыки. У него может не быть административных полномочий, а проекты он тащит за счет опыта, харизмы и сочетания технических и управленческих навыков.
Сначала определимся с терминологией, от компании к компании она разнится:
Юнит (unit) — структурное объединение из нескольких (2–4) команд, под руководством юнит-лида.
Домен (управление разработки) — объединение нескольких юнитов. Технический менеджмент домена осуществляется управленцем на позиции EM (engineering manager). Домены — наибольшая единица дробления IT-подразделения крупной компании.
Staff-инженеры имеют несколько градаций, в зависимости от масштаба деятельности и сферы влияния:
staff-инженер обычно работает на уровне юнита (несколько команд), структурно подчиняясь юнит-лиду.
principal-инженер — на уровне домена (несколько юнитов) под руководством EM (engineering manager).
fellow-инженер — подчиняется CTO компании, его никто не разу не видел :)
Для простоты я буду обобщенно называть все грейды staff-инженеров (staff, principal, fellow) из желтого прямоугольника просто staff-инженерами, стафф-инженерами или просто стаффами.
Чем занимаются стафф-инженеры?
Staff-инженер не имеет постоянной команды и людей в подчинении, хотя может часто работать с одной или несколькими группами инженеров над проектами. Он может выступать в роли техлида или быть техническим консультантом на проекте. Возможны и варианты, где он подключается в проект на ранней стадии, чтобы дать команде kick-start.
Иерархически стафф подчиняется руководителю отдела, находясь на одном уровне с EM/юнит-лидами/тим-лидами. В таком положении он обладает возможность выстраивать прямые взаимоотношения с техменеджментом и имеет соответствующий уровень влияния на проект или продукт. Он участвует в больших проектах или инициирует их. А если горит пожар и команда не может выдернуть человека из цикла планирования, он может прийти и починить острые проблемы разработки своими руками. В крайнем случае он может подменить разработчика, чтобы в ответственный момент работа команды критически не просела.
Ниже рассмотрим потенциальные направления работы staff-инженеров. Несмотря на разнородность, их объединяет общая цель — решать технические проблемы большого масштаба в интересах бизнеса, текущие или на перспективу.
Архитектурный трек
Проработка архитектуры существующих и планируемых подотчетных систем — одна из ключевых активностей staff-инженера. Исходя из потребности или выстроенных в домене процессов, стафф выступает консультантом при составлении архитектурного решения командой разработки. Он может и полноценно вовлечься в этот процесс, если задача масштабная и требует глубоких исследований.
Совместная цель стаффа и команды — прийти к консенсусу о работоспособности предложенного решения, или указать на его недостатки в долгосрочной перспективе. Очень часто это подразумевает нахождение компромисса между решением бизнес задачи и правильной архитектурой: где-то можно срезать углы и вернуться к этому позже, где-то адаптировать требования под технику.
Стафф на ранних этапах поможет подсветить потенциальные сложности и нюансы реализации, еще до того, как мы пошли в конкретную команду разработки с планом. Это можно назвать очень ранней оценочной консультацией потенциальных трудозатрат (времени и ресурсов).
Стафф-инженер финально проводит ревью архитектурного решения перед выходом команды на архитектурный комитет и сопровождает команду в процессе его прохождения.
Без знаний в архитектуре, паттернов и антипаттернов, насмотренности, ошибок и рефлексии над ними не обойтись.
Представительская функция
Стафф лучше всех разбирается в техническом устройстве своего домена, является центральной точкой компетенции и осведомленности по большинству технических вопросов. Готов проконсультировать сам или свести с нужным специалистом.
Наша система уже сейчас настолько большая, что целиком ее никто не представляет. И даже просто консультировать и делится знаниями о системе — полезная и важная нагрузка. В этом смысле стафф иногда может заменить системного аналитика.
Представьте, Вам необходимо взаимодействовать с другим отделом. В техническом плане он для вас черная коробка, внутри которой очень много команд со своим фрагментарным знанием. Стафф выступает единым лицом с целостным восприятием систем и может говорить за всю технику всего домена (а там десятки сервисов).
Это так же означает, что при пересечении взаимных интересов доменов нужны стафф-инженеры с двух сторон. В каком-то смысле это работа клеем между доменами и командами. Стафф хранит знание и понимание всех систем целостно, а не фрагментарно, либо знает, где их быстро получить.
Это предполагает, что он обладает навыками работы архитектора: разрисовать решение, особенно когда нужно будет сравнивать компромиссные варианты.
Проектирование больших кросс-доменных фичей
Крупные продуктовые изменения, затрагивающие несколько доменов, со стороны техники лидирует именно стафф-инженер. Особенно на начальных этапах, когда приходится склеивать продукт и инженерку для реализации новой фичи, предварительно сформулированной бизнесом.
Обычно на этом этапе нет никакого представления, как это положить на технику. Не понятно как это сделать, какие команды и отделы будут задействованы, и какой «волновой эффект» (ripple) планируемые изменения могут дать.
Здесь роль стаффа — помочь продакту и продуктовой команде составить техническое требование, формализовать описание, провести исследование, подсказать, куда обратиться за консультацией к коллегам — стаффам из другого домена.
Цель — предварительно проработать техническое решение, прийти к концептуальной договоренности с другими отделами, декомпозировать его до уровня, когда проект можно запустить в работу.
Ценность этой работы в системном и согласованном внедрении изменений, когда «пазл складывается» (даже если отдельные его части приходится забивать молотком).
Стафф помогает «строить мосты» согласованно, имея предварительный архитектурный план и расчеты. В противном случае реализация одной фичи не синхронизированными командами может привести к неожиданным результатам: вместо функционального моста может появится кусок дороги с одной стороны, кусок метро с другой и плот, их соединяющий.
Хорошая проработка, это:
понятные артефакты — команда их прочитала, все все одинаково поняли, и не возникало двусмысленности;
реализация проходит с малым количеством уточняющих вопросов или вообще без них;
на выходе получили продукт, соответствующий ожиданиям бизнеса.
Работа в этом направлении предполагает встречи и общение с коллегами. Требуются развитые коммуникативные навыки: умение поддержать беседу (small-talk) и начать разговор, четкая формулировка мыслей, фасилитация встреч, удержание фокуса на результат.
Стабильность процессов в домене
В некоторых отделах стафф-инженер участвует в процессе улучшения стабильности работы систем:
участвует в разборах инцидентов с прицелом на архитектурный план;
помогает команде разобраться и починить проблему системно;
выстраивает графики и процессы SLI, что они отражали действительность и помогали выявлять инциденты.
Метрики стабильности должны коррелировать с реальной жизнью: разработчики технически оперируют latency, статусами ответов или лагом в консьюмер группе. Но эти факторы не всегда определяют проблему в реальном мире. Например, может не прийти ответ от партнера по какому-то инфообмену: по графикам все зеленое, а по-факту «все плохо и мы об этом не знаем».
Задача стаффа в этом случае — выстроить графики стабильности, документирующие подобные ситуации, для лучшего контроля работы системы. А также поверх графиков выстраить комплексный процесс управления стабильностью.
В этом направлении стаффу здорово помогает опыт разработки и эксплуатации различных систем.
Hands-on работа
Большинство стафф-инженеров владеют сильной технической экспертизой в одном или нескольких стеках (или какой-то технологией) и достаточно часто работают руками.
К примеру:
помогут разобраться с технической проблемой, написать код, подебажить или проконсультировать коллег;
часть проблем могут исправить сами или передать в виде артефактов команде разработки;
провести исследование, либо быстро набросать какой-то технический отчет по срочной проблеме;
накидать доказательство концепции (PoC) или сделать прототип какого-то решения;
исследовать OpenSource зависимости и особенности их реализации или код сервисов из другого домена;
пойти писать код вместе с командой, если того требует ситуация.
Для этого требуется глубокая экспертиза и опыт разработки. Большинство стафф-инженеров в Купере в прошлом — Senior-разработчики с серьезным техническим бэкграундом. Работа руками позволяет staff-инженеру не отрываться от реальности и не терять квалификацию.
Но есть тонкий момент hands-on работы: стафф не может позволить себе делать лонг-терм задачи, требующие постоянной поддержки и внимания, потому что внимание стаффа в будущем может быть легко переключено на что-то более приоритетное, что больше горит.
Поиск технологических блокеров
Стафф-инженер выявляет и изучает технологические (или любые другие) блокеры в своем домене наперед. Ищет особенности системы, которые в перспективе ухудшают стабильность работы, снижают Lead Time или иначе сдерживают развитие бизнеса. Такие исследования обычно выровнены с IT-стратегий домена или компании, чтобы лечить то что реально болит у бизнеса.
Стафф и его руководитель здесь в одной лодке. Управленец обязан выявлять технологические блокеры в своем отделе. Но, фактически, сам не всегда может это сделать в силу отсутствия времени, глубоких знаний системы или экспертизы. У стаффа же есть время, знания системы и экспертиза!
Сдерживающие факторы не всегда могут быть технологическими, или иметь техническое решение, как например внедрение или улучшение некоторых процессов.
В такого рода исследованиях стафф пользуется своим опытом, общается с командами, управленцами, продуктом и бизнесом, выявляет проблемы, изучает дашборды или внедряет метрики для измерения проблемы.
Первостепенная задача — изучить и сформулировать проблему, оценить возможные риски и эффект, ожидаемый от потенциальных улучшений.
Помимо сложно формализуемого «навыка решения проблем (problem solving)» для постановки проблемы потребуется системное мышление, умение отделять причину и следствие, находить закономерности и аномалии, а так же продуктовый подход — разрабатывать гипотезы и проверять их пока метрика не улучшится. Чем быстрее будет проверка гипотез и качественнее гипотезы — тем лучше.
Лидирование технологических изменений
После выявления и постановки проблемы стафф-инженер будет верхнеуровнего прорабатывать ее решение, согласовывать выделение ресурсов и примет участие в проекте в роли тех-лида. Далее он будет координировать работу подключенных команд, взяв на себя ответственность за техническую часть проекта.
Приведу два реальных примера таких технологических инициатив.
Пример 1: перевод монолита на платформу
В Купере есть PaaS — платформа, которая ускоряет запуск и упрощает обслуживание сервисов (вот статья от моего коллеги о том, как это устроено у нас). С другой стороны у нас было два больших неплатформизованных монолита, на обособленное обслуживание которых расходовались ресурсы девопсов.
Чтобы высвободить ресурсы на поддержку монолитов, а также, чтобы монолиты получили из коробки фичи платформы: алерты, SLO, автоматическую выдачу прав на топики, стейджи и прочее, нужно было перенести их в платформу. Это была первая масштабная проверка универсальности PaaS. До этого считалось, что монолиты настолько большие, сложные и специфические, что не могут быть помещены в платформу.
Стафф-инженер лидировал этот переезд, работая с кросс-функциональной командой, собранной из разных подразделений: продакты, DevOps, QA и разработчики и др.
Сам план переключения в день X был настолько проработан, что оно происходило по принципу «копируй команду в консоль».
Кто-то может воспринять составление подобного плана как менеджерскую задачу. А сборка ракеты — это управленческая работа или инженерная? Мне кажется, инженерная, в которой каждый из инженеров имеет свое понимание части работ во всей этой сборке. Иначе из ракеты получится что-то непонятное.
К слову разработка платформы — такая же сложная техническая задача, которую лидирует один или несколько стафф-инженеров.
Пример 2: декомпозиция монолита для снижения нагрузки
В один момент технологическим блокером всей системы стала запредельная нагрузка на БД крупного исторического монолита.
Стафф-инженер в этом случае сработал наперед:
Самостоятельно исследовал инциденты, выявил и обобщил проблему.
Разработал систему метрик для анализа самых нагруженных частей монолита (как настроить систему метрик нагрузки на БД, и искать эффективные точки оптимизации можно посмотреть в докладе или на слайдах).
Выявил ограниченный контекст, требующий переноса из монолита в отдельный сервис с сопутствующим переносом нагрузки.
Разработал поступательный план миграции, с фокусом на стабильность (подробней об этом проекте — я рассказывал в статье, в докладе на конференции).
Презентовал проект менеджменту, оценил необходимые ресурсы, выторговал их, и запустил работу.
Сопроводил проект, осуществляя помощь и поддержку всем участникам.
Довел проект до результата.
В итоге к сезону высоких нагрузок снят важный ограничивающий фактор. А многие инженерные практики, впервые обкатанные на этом проекте, растиражированы в повседневные рабочие процессы разных команд.
Как видите из примеров, наравне с техническими требуются навыки управления проектами и командной работы (хоть и утверждается, что стафф — это индивидуальный контрибьютор).
Но самое важное — быть самонаводимым. Если у стаффа есть задача, он сам исследует ее, ставит встречи с другими доменами, изучает процессы и бизнес-область. При этом выйти на проблему и сформулировать задачу может сам стафф (см. предыдущий пункт).
Поддержка company-wide инициатив
Для осуществления масштабных технологических изменений, требуется их поддержка со стороны различных отделов разработки. Таким образом крупный проект превращается широкомасштабную инициативу, к которой со стороны доменов в первую очередь подключатся стафф-инженеры.
Пример, рабочая группа по подготовке к сезону высоких нагрузок, предполагающая:
разбор результатов нагрузочного тестирования (как устроено нагрузочное тестирование в Купере можно посмотреть в докладе);
составление плана оптимизаций в своем домене с прицелом на архитектурные изменения;
формирование беклога декомпозированных задач, который дальше уйдет в команды разработки.
Тут пригодится опыт эксплуатации сервисов под нагрузкой (highload), полноценное понимание систем домена, а также умение формулировать и декомпозировать задачи.
Хранитель знаний
В компании из-за бурного роста люди, работающие больше трех лет, являются ценными экспертами, и видели такое, что не видело 90% компании. Они обладают недокументированным контекстом о реализации той или иной фичи.
А за пределами технической экспертизы у стаффа может быть глубокая экспертиза в бизнесе. С такой экспертизой купить человка с рынка невозможно и ее можно только взрастить. Стафф может быть глубоко погружен в то, что сейчас есть, почему оно так сделано, и понимать, что в итоге хочется, а так же систематизировать и распространять эти знания в виде артефактов (ADR, комьюнити-гайдов, документации), формируя локальные (для компании) «лучшие практики» про то как надо делать и как не надо и почему.
Обмен опытом
Стафф делится знаниями внутри и за пределами компании, продвигает инженерную культуру, помогает менее опытным инженерам продвигаться на следующий уровень своей карьеры.
У большинства стаффов есть одна или несколько активностей из списка ниже:
наставник и участник программ технического образования;
доклады на технических конференциях, встречи, выступления, подкасты;
ведение блога (личный блог, stackoverflow, github, habr и т.д.);
Написание этой статьи — часть моей работы, как principal-инженера.
Также перед стаффом может стоять задача развивать архитектурные компетенции внутри команд в формате совместного проектирования:
поддерживать команду в процессе и делится опытом;
помочь сравнить плюсы и минусы различных подходов к решению;
постепенно давать командам больше свободы и возможность самостоятельно проектировать решения, приходя уже с готовым наработками;
В этом случае команда растет, и работа стаффа приобретает больше консультационный характер.
Правая рука руководителя
Стафф-инженер разделяет цели руководителя домена/компании, который отвечает на всю инженерку своего отдела. Задача стаффа — сделать так, чтобы подотчетные системы были превосходны, развивались в соответствие с бизнес-планом, опережали стратегию развития компании.
В этом плане, стафф-инженер иногда выступает в роли заместителя или правой руки (в книге Вилл Ларсон использует термин «right hand»), оказывая руководителю помощь в управлении, а также консультирование по ключевым техническим решениям.
Right Hand — очень распространенный паттерн работы стаффа, в каком-то смысле стафф и управленец — параллельные треки с частично пересекающимся скилл-сетом.
Хороший стафф помогает руководителю достигать целей. В этом ему помогает управленческий опыт (и у большинства респондентов он был на позиции тим- или юнит-лида).
Но есть тонкий момент: у управленца есть административный рычаг, а у стафф-инженера его нет. Как эффективно работать тех-лидом в таких обстоятельствах рекомендую доклад.
Ожидания руководителя
Руководитель большого подразделения мыслит широко. У него совмещена продуктовая и технологическая стратегия на год-два вперед. Чтобы ее поддерживать, работа стаффа в основном имеет проектный характер: где больно, туда и идем.
При этом руководитель может полностью делегировать какую то проблему стаффу на решение, чтобы разгрузить себя.
Вот списков обобщенных требований к стафф-инженерам от технического менеджмента, который я собрал в результате интервью:
самонаводимость — стафф получает направление или проблему, и действует самостоятельно;
принимает технические и архитектурные решения и несет ответственность за них;
лидирует проекты направленные на важные метрики, к примеру, SLA, lead time, прохождение сезона и тд;
помогает командам прорабатывать продуктовые изменения;
держит в актуальном состоянии документацию своего юнита;
участвует в устранении инцидентов и последующих их разборов;
помогает с срочными задачами в его зоне;
формирует техническое видение развитие своего проекта юнита;
гибко принимает участие в ключевых проектах в разных ролях (не только консультантом)
Как видите практически зеркально совпадает с предыдущим разделом. Отмечу лишь, что с большой вероятностью один человек не сможет закрыть все эти пункты, и в большом подразделении может быть несколько стафф-инженеров.
В следующей статье я подробнее рассмотрю путь он Senoir«а до Staff«а — основой этому также стал цикл интервью со стафф-инженерами Купера, которые я провёл этим летом.
Если тема вам интересна и не хотите пропустить, подписывайтесь на мой tg-канал Стафф-инженер или на соцсети Купер.тех— Telegram и YouTube.
