Источник
Code of Leadership #6
Статья о Staff Engineer, роли архитектуры и секции SDLC в оценке Staff+ уровня.
Источник
Code of Leadership #6
Статья о Staff Engineer, роли архитектуры и секции SDLC в оценке Staff+ уровня.
Staff+ — это не «еще один Senior». Это уровень системного влияния: когда инженер меняет не только свой сервис, но и то, как компания принимает архитектурные решения, поставляет изменения и управляет качеством SDLC.
О чем глава
Материал главы основан на статье и выпуске подкаста: какие бывают роли Staff+, как отличать уровень по реальным сигналам, как растить людей до Staff внутри компании и как строить найм, чтобы проверять не только System Design, но и зрелое мышление про архитектурный процесс и SDLC.
TL;DR
- Staff+ — это масштаб влияния, а не набор технологий.
- Архитектура и SDLC — отдельная компетенция, которую нужно проверять явно.
- Внутренний рост обычно надежнее и дешевле внешнего найма.
- Лидерство Staff+ строится через механизмы, а не через формальные полномочия.
Подкаст
Эпизод про Staff Engineer
Разбор практики: рост Staff+ внутри компании и найм с рынка с фокусом на архитектуру и SDLC.
Подкаст
Эпизод про Staff Engineer
Разбор практики: рост Staff+ внутри компании и найм с рынка с фокусом на архитектуру и SDLC.
Почему Staff+ это отдельный уровень
Senior обычно оптимизирует локальный контекст команды. Staff+ оптимизирует систему на уровне нескольких команд: архитектурные границы, процессы принятия решений, устойчивость delivery и качество инженерной среды.
Глубокий фокус на домене команды и качестве решений внутри потока.
Решает критически сложные технические узлы и вытаскивает «невозможные» задачи.
Держит целостность архитектуры, границы доменов и правила эволюции систем.
Переводит стратегию техлидерства в исполнимые инициативы и меняет поведение системы.
Матрица ожиданий Staff+
| Критерий | Что смотрим | Сигнал уровня |
|---|---|---|
| Scope | Граница ответственности | Несколько команд, домен, платформа |
| Impact | Изменение бизнес/тех-результата | Улучшения остаются после автора |
| Complexity | Сложность связей и ограничений | Работа с компромиссами и рисками |
| Leadership | Влияние без полномочий | Договоренности между командами |
| Improvements | Системные улучшения среды | Платформа, стандарты, SDLC-практики |
Как это устроено в Т-Банке: рост и калибровка
Dual-track карьерная лестница
В статье отмечено, что в Т-Банке формализованы два трека: management и IC, с возможностью осмысленного выбора пути.
Явные сигналы уровня
Оценка роста опирается на Scope, Impact, Complexity, Leadership, Improvements, а не на «впечатление от кандидата».
Процесс Т-Рост
Для внутреннего роста используется self-promo формат с артефактами результата, что снижает субъективность при калибровке.
Почему стандартной воронки инженера недостаточно для Staff+
- Рекрутерский скрининг.
- Техническое интервью (язык, алгоритмы, задачи уровня).
- Системный дизайн (обычно без глубокой секции по SDLC).
- Финальный fit с командой/менеджером.
- Слабо проверяется архитектурный процесс, а не только итоговая схема.
- Почти не видны навыки изменения SDLC и инженерной среды.
- Недооценивается способность к системному влиянию без формальных полномочий.
- Нет уверенности, что кандидат сможет масштабировать практики на несколько команд.
Почему в найме нужна отдельная секция «архитектура + SDLC»
Классический интервью-луп часто оценивает алгоритмы, кодинг и «рисование дизайна». Для Staff+ этого недостаточно. Кандидат должен показать, как он организует архитектурный процесс в живой компании: от постановки проблем до миграций и изменений SDLC.
- Как кандидат принимает архитектурные решения под ограничениями.
- Как управляет техдолгом и эволюцией системы без «большого переписывания».
- Как меняет SDLC: review, quality gates, release, incident learning.
- Как выстраивает кросс-командные договоренности и ownership.
- Кейс из реального контекста компании, а не абстрактная задача.
- Вопросы про trade-offs, критерии успеха и обратимость решения.
- Оценка влияния на систему: люди, процессы, архитектура, эксплуатация.
- Интервью проводят Staff+ инженеры с понятной калибровкой сигналов.
- Как определить границы архитектуры и зону ответственности между командами?
- Какие trade-offs были приняты и почему отказались от альтернатив?
- Как решение повлияло на SDLC: review, release cadence, observability, incident learning?
- Какие механизмы сделали решение устойчивым после ухода автора?
Эволюция подхода в компании
- Секция «Архитектура + SDLC» сначала применялась для собеседований Staff+ инженеров.
- По материалам статьи, практику использовали в найме Staff+ и техлидов около четырех лет.
- В 2025 году подход начали масштабировать и на инженерные интервью в целом.
Как растить Staff+ внутри
- Зафиксировать ожидания по матрице и согласовать текущий gap.
- Дать задачи нужного масштаба, где есть межкомандное влияние.
- Собирать артефакты: ADR, RFC, решения по SDLC, результаты миграций.
- Проводить регулярную калибровку с Staff+ комьюнити.
- При необходимости использовать ротацию для расширения контекста.
Антипаттерны
Что ломает Staff+ трек
- Считать Staff+ просто «сильным Senior» без изменения масштаба задач.
- Оценивать только личный output вместо системного impact.
- Назначать титул без механизмов влияния и зон ответственности.
- Пытаться измерять роль через локальные KPI и индивидуальную выработку.
Для связанной темы посмотрите главы про варианты ролей Staff+ инженера, архитектурную роль high-grade IC и влияние без полномочий.
Итог
Staff+ уровень появляется там, где инженер начинает проектировать систему целиком: и код, и архитектуру, и SDLC, и способы взаимодействия команд. Именно это делает роль ключевой для масштабирования инженерной организации.