Карьерные треки и оптимизация работы тимлида#

Документ описывает оценку разных карьерных специализаций, оптимизацию нагрузки тимлида и FAQ.

Оценка разных карьерных треков#

Контекст: Начиная с грейда 4 (Middle I), технический трек допускает разные специализации: Technical Depth, Platform Engineering, Reliability Engineering, Generalist. Все специализации ведут к одинаковым грейдам и компенсации.

Ключевой принцип: Оценивается уровень влияния и impact, а не специализация.

Middle II Platform Engineer = Middle II Performance Engineer по компенсации и требованиям к грейду.

Как оценивать impact разных специализаций#

При оценке готовности к повышению важно понимать, что impact может проявляться по-разному:

Важно для менеджеров: Не дискриминируйте operational work!

❌ Неправильно:

"Ты много чинишь баги, но не делаешь новые фичи.
Для Senior нужно делать что-то более сложное."

✅ Правильно:

"Ты стабильно чинишь баги с высоким качеством (50% снижение багов).
Это сильный impact. Для Senior нужно масштабировать:
- Построить quality processes для команды
- Менторить других в багфиксинге
- Влиять на reliability стратегию продукта"

Оценка Technical Skills по специализациям#

Middle I → Middle II (грейд 4 → 5)#

Technical Depth:

• Глубокое понимание .NET internals (GC, JIT)
• Многопоточность и параллелизм
• Оптимизация производительности

Platform Engineering:

• Экспертиза в CI/CD
• Ownership за качество
• Автоматизация процессов

Reliability Engineering:

• Ownership за качество
• Масштабный рефакторинг legacy
• Снижение tech debt

Generalist:

• Знает 3+ модулей глубоко
• Может работать в любой части кодовой базы
• Кросс-функциональные проекты

Senior I → Senior II (грейд 6 → 7)#

Technical Depth:

• CLR internals, unsafe code, Span, Memory
• SIMD, vectorization, GC modes
• Архитектор высокопроизводительных систем

Platform Engineering:

• Архитектура platform уровня продукта
• Техническое стратегирование
• Кросс-командные инициативы

Reliability Engineering:

• Reliability стратегия для продукта
• Quality culture в команде
• Кросс-командные инициативы

Generalist:

• Эксперт во всех частях продукта
• Кросс-командные инициативы
• Системное мышление

Как собирать доказательства для operational work#

Проблема: Operational work часто “невидим” — багфиксинг, рефакторинг не создают “героических” историй.

Решение: Фиксировать метрики и impact в дневнике достижений.

Пример для Reliability Engineer#

Квартал Q1 2025:

Багфиксинг модуля Водоснабжение:
- Исправил 47 багов (средний приоритет: High)
- Снижение open bugs: с 89 до 42 (-53%)
- Среднее время исправления: 1.2 дня (было 3.5)
- User-reported bugs снизились на 60%
- **Impact**: Пользователи отмечают стабильность модуля

Рефакторинг legacy кода:
- Рефакторинг класса WaterCalculator (1200 строк → 400)
- Покрытие тестами: 0% → 85%
- Cyclomatic complexity: 45 → 8
- **Impact**: Теперь легко добавлять новые типы расчетов

Пример для Platform Engineer#

Квартал Q1 2025:

CI/CD улучшения:
- Построил автоматический release pipeline
- Время релиза: с 4 часов до 30 минут
- Частота релизов: с 1 раз в 2 недели до 2-3 раза в неделю
- **Impact**: Команда выпускает фичи быстрее

Автоматизация тестирования:
- Написал integration test framework для nanoCAD интеграции
- 45 integration тестов (покрывают 80% критичных сценариев)
- **Impact**: Поймали 12 регрессий ДО релиза

Пример для Generalist#

Квартал Q1 2025:

Кросс-модульная работа:
- Реализовал фичу "Экспорт в IFC" (затронула 4 модуля)
- Понял архитектуру всех модулей, нашел общие паттерны
- **Impact**: Единый подход к экспорту во всех модулях

Кросс-модульный рефакторинг:
- Выделил общую библиотеку GeometryUtils
- **Impact**: Фикс бага в 1 месте → исправляется в 3 модулях

Частые ошибки при оценке operational work#

Ошибка 1: Недооценка “черновой работы”

❌ Неправильно: “Ты много багфиксишь, но это не рост” ✅ Правильно: “Ты багфиксишь с высоким качеством. Для следующего грейда масштабируй: quality processes, менторинг”

Ошибка 2: Требование универсальности

❌ Неправильно: “Ты хорош в CI/CD, но не делаешь performance оптимизацию” ✅ Правильно: “Ты Platform Engineer. Для Senior масштабируй platform impact, не добавляй другую специализацию”

Ошибка 3: Игнорирование метрик

❌ Неправильно: “Ты улучшаешь CI/CD, молодец” ✅ Правильно: “Давай фиксировать метрики: время релиза, частота, экономия времени команды”

Ключевые принципы оценки треков#

1. Оценивайте impact, не специализацию
2. Не требуйте универсальности — каждый трек ценен
3. Фиксируйте метрики для operational work
4. Масштабирование impact для повышения: Middle делает сам, Senior менторит и строит процессы, Staff влияет на стратегию
5. Поддерживайте переключение треков — грейд сохраняется при смене специализации

Оптимизация нагрузки тимлида#

Проблема: Высокая нагрузка на people processes#

Типичная ситуация: Тимлид с командой 7 человек тратит 10-12 часов в неделю на people management — ~25-30% рабочего времени.

Источники нагрузки:

• Еженедельные 1-on-1 (7 человек x 1 час = 7 часов)
• Карьерные беседы
• Подготовка к калибровкам
• Дневники достижений
• 360° feedback
• Найм и онбординг

Реалистичная нагрузка по размеру команды#

Правило 8+: Делегировать или разделить#

При команде 8+ человек у тимлида есть три варианта:

Вариант 1: Делегирование части people management#

• Senior разработчики становятся buddy/наставниками для Junior
• Peer mentoring: Middle менторят Junior
• Тимлид фокусируется на Senior и на системных вопросах

Вариант 2: Вложенный тимлид / техлид#

• Назначается Junior Team Lead или Tech Lead
• Часть команды переходит под его менеджмент
• Ведущий тимлид координирует и развивает Junior TL

Вариант 3: Разделение команды#

• Команда делится на 2 подкоманды по 4-5 человек
• Каждая со своим тимлидом
• Координация через Engineering Manager или Head of Department

Когда какой вариант выбирать:

Механизмы делегирования#

1. Buddy система для Junior#

Суть: Senior разработчик назначается buddy для Junior и берет на себя часть менторинга.

Что делегируется buddy:

• Ежедневная помощь с задачами и code review
• Первичные технические консультации
• Onboarding новых сотрудников (техническая часть)
• Помощь с дневником достижений (техническая сторона)

Что остается у тимлида:

• 1-on-1 (но реже: раз в 2 недели вместо еженедельно)
• Карьерные беседы
• Оценка performance
• Решение конфликтов

Пример распределения для команды 8 человек:

- 2 Senior (buddy для Junior)
- 3 Middle
- 3 Junior

Тимлид:
- 1-on-1 с Senior: еженедельно (2 x 30мин = 1ч)
- 1-on-1 с Middle: еженедельно (3 x 30мин = 1.5ч)
- 1-on-1 с Junior: раз в 2 недели (1.5 x 30мин = 0.75ч)
- Итого: 3.25ч/неделю на 1-on-1 вместо 4ч

Senior buddies:
- Ежедневное взаимодействие с Junior
- Code review Junior'ов
- Помощь с задачами

2. Peer mentoring (Middle -> Junior)#

Суть: Middle разработчики менторят Junior в рамках конкретных проектов.

Что делегируется:

• Code review на конкретных проектах
• Техническое обучение в рамках задачи
• Pair programming

Важно: Peer mentoring — это НЕ передача management ответственности. Тимлид остается ответственным за performance и карьерное развитие.

Реалистичные ожидания по уровням тимлида#

Красные флаги (когда нагрузка слишком высока):

• Тимлид регулярно пропускает 1-on-1
• Дневники достижений не обновляются месяцами
• Карьерные беседы откладываются
• Тимлид выгорает или качество кода падает

Что делать при красных флагах:

1. Обсудить с Head of Department
2. Рассмотреть варианты: делегирование, разделение команды
3. Временно снизить требования к техническому вкладу
4. Приоритизировать: 1-on-1 > карьерные беседы > 360°

FAQ#

Q: Как часто можно получать повышение? A: Нет жестких ограничений. Если демонстрируете компетенции следующего грейда — можете подавать. Типичные сроки: Junior→Middle 12-18 мес, Middle→Senior 18-24 мес, Senior→Staff 24-36 мес.

Q: Можно ли получить повышение без менеджера? A: Нет. Менеджер — обязательная часть процесса, он оценивает компетенции и принимает решение (с head of department).

Q: Что если менеджер несправедливо отказывает? A: Можно обратиться к skip-level manager (руководитель менеджера). Он проверит объективность решения.

Q: Влияет ли отказ в повышении на зарплату? A: Нет. Зарплата зависит только от текущего грейда. Отказ в повышении = остаетесь в текущем грейде с текущей зарплатой (+ годовая индексация).

Q: Можно ли вернуться с Team Lead на IC? A: Да. Технический грейд сохраняется, убирается только управленческая надбавка. Зарплата = базовая для грейда (без TL premium).

Q: Нужно ли проходить 360° для повышения? A: Не обязательно, но рекомендуется для Middle+ (особенно для Senior→Staff+). Feedback от коллег усиливает документ на повышение.

Связанные документы#

• Feedback и развитие — механизмы обратной связи
• Шаблоны 1-on-1 — шаблоны для экономии времени