Привет! Меня зовут Дима Салахутдинов, я 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: декомпозиция монолита для снижения нагрузки

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

Стафф-инженер в этом случае сработал наперед:

1. Самостоятельно исследовал инциденты, выявил и обобщил проблему.

2. Разработал систему метрик для анализа самых нагруженных частей монолита (как настроить систему метрик нагрузки на БД, и искать эффективные точки оптимизации можно посмотреть в докладе или на слайдах).

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

4. Разработал поступательный план миграции, с фокусом на стабильность (подробней об этом проекте — я рассказывал в статье, в докладе на конференции).

5. Презентовал проект менеджменту, оценил необходимые ресурсы, выторговал их, и запустил работу.

6. Сопроводил проект, осуществляя помощь и поддержку всем участникам.

7. Довел проект до результата.

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

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

Но самое важное — быть самонаводимым. Если у стаффа есть задача, он сам исследует ее, ставит встречи с другими доменами, изучает процессы и бизнес-область. При этом выйти на проблему и сформулировать задачу может сам стафф (см. предыдущий пункт).

Поддержка company-wide инициатив

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

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

• разбор результатов нагрузочного тестирования (как устроено нагрузочное тестирование в Купере можно посмотреть в докладе);

• составление плана оптимизаций в своем домене с прицелом на архитектурные изменения;

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

Тут пригодится опыт эксплуатации сервисов под нагрузкой (highload), полноценное понимание систем домена, а также умение формулировать и декомпозировать задачи.

Хранитель знаний

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

А за пределами технической экспертизы у стаффа может быть глубокая экспертиза в бизнесе. С такой экспертизой купить человка с рынка невозможно и ее можно только взрастить. Стафф может быть глубоко погружен в то, что сейчас есть, почему оно так сделано, и понимать, что в итоге хочется, а так же систематизировать и распространять эти знания в виде артефактов (ADR, комьюнити-гайдов, документации), формируя локальные (для компании) «лучшие практики» про то как надо делать и как не надо и почему.

Обмен опытом

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

У большинства стаффов есть одна или несколько активностей из списка ниже:

• наставник и участник программ технического образования;

• доклады на технических конференциях, встречи, выступления, подкасты;

• ведение блога (личный блог, stackoverflow, github, habr и т.д.);

Написание этой статьи — часть моей работы, как principal-инженера.

Также перед стаффом может стоять задача развивать архитектурные компетенции внутри команд в формате совместного проектирования:

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

• помочь сравнить плюсы и минусы различных подходов к решению;

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

В этом случае команда растет, и работа стаффа приобретает больше консультационный характер.

Правая рука руководителя

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

В этом плане, стафф-инженер иногда выступает в роли заместителя или правой руки (в книге Вилл Ларсон использует термин «right hand»), оказывая руководителю помощь в управлении, а также консультирование по ключевым техническим решениям.

Right Hand — очень распространенный паттерн работы стаффа, в каком-то смысле стафф и управленец — параллельные треки с частично пересекающимся скилл-сетом.

Хороший стафф помогает руководителю достигать целей. В этом ему помогает управленческий опыт (и у большинства респондентов он был на позиции тим- или юнит-лида).

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

Ожидания руководителя

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

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

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

• самонаводимость — стафф получает направление или проблему, и действует самостоятельно;

• принимает технические и архитектурные решения и несет ответственность за них;

• лидирует проекты направленные на важные метрики, к примеру, SLA, lead time, прохождение сезона и тд;

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

• держит в актуальном состоянии документацию своего юнита;

• участвует в устранении инцидентов и последующих их разборов;

• помогает с срочными задачами в его зоне;

• формирует техническое видение развитие своего проекта юнита;

• гибко принимает участие в ключевых проектах в разных ролях (не только консультантом)

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

В следующей статье я подробнее рассмотрю путь от Senoir’а до Staff’а — основой этому также стал цикл интервью со стафф-инженерами Купера, которые я провёл этим летом. 

Если тема вам интересна и не хотите пропустить, подписывайтесь на мой tg-канал Стафф-инженер или на соцсети Купер.тех — Telegram и  YouTube.