---
title: Карта опыта — готовые STAR-истории под секцию управленческого опыта (этап 4)
source: подготовлено 2026-10-07, TASK-50; факты — из полного CV (/mnt/storage/projects/publicity/blog/cv.md) и AGENTS.md проекта. Всё неподтверждённое помечено ✳ — это каркас, который нужно наполнить реальными деталями
---

# Карта опыта: истории под вопросы Тимура

**Правило:** факты не выдумывать. Истории без ✳ — подтверждённые факты (можно рассказывать как есть). Истории с ✳ — жанр и структура верные, но конкретные детали ты подставляешь свои; на секции звучит только то, что реально было.

## Сводка: какие факты у тебя есть (опорные цифры)

- **20+ лет разработки, 9 лет руководства** (с 2017), команды: 7 → 9 → 18+ (три команды) → юнит 20+ разработчиков и аналитиков.
- **~20 выросших инженеров за 9 лет**; пятеро до повышения + преемник-тимлид (Самокат); 3 выросли в тимлидов (Телематика); преемник (Баланс); инициированное повышение (Райф).
- Процессы: 1:1 (Райф), техроудмап трёх команд и техдолг-процесс (Райф), матрица компетенций Ruby + 10+ семинаров (Баланс), PBR и дежурства (Баланс), DDD и процессы новых команд (Самокат), критерии код-ревью и параллельный CI (Дикси).
- Публичность: RubyRussia 2023/2024, TechLead Conf 2025, SberMarket RubyMeetup 2023, GeekBrains.
- Запуски: 3 продукта в прод (Самокат, 800K+ пользователей); миграция на новую инфраструктуру — готовность 80% за период (Райф); ускорение синхронизации остатков в 10 раз (Дикси).

---

## История 1. Целеполагание: единый техроудмап трёх команд (Райф)

**Отвечает на:** целеполагание, планирование, работа с несколькими командами, техстратегия, коммуникации со стейкхолдерами.

- **S:** Райф, юнит из трёх кросс-функциональных команд (20+ разработчиков и аналитиков) — три продукта, у каждого свой роудмап и приоритеты; общей картины нет.
- **T:** нужно единое техническое планирование юнита, чтобы приоритеты не конфликтовали и бизнес видел целое.
- **A:** провёл ревизию архитектуры (актуализировал C4-схемы трёх продуктов), собрал технические потребности команд, ввёл единый подход к ведению техроудмапа, завёл процесс управления техдолгом с приоритизацией по влиянию на бизнес.
- **R:** единый роудмап трёх команд, целостное описание архитектуры, процесс техдолга работает; миграция одного продукта на новую инфраструктуру — готовность 80% за период.
- **Рефлексия:** «Понял: роудмап — это не список задач, а договорённость о приоритетах. Если три команды не видят общую картину, они будут тянуть в разные стороны при полной загрузке».
- **Формат:** 2–3 мин; при уточнении — детали про критерии приоритизации техдолга.

## История 2. Найм: система оценки кандидатов (Баланс)

**Отвечает на:** найм, процессы, стандарты, работа с качеством.

- **S:** Balance Platform, практика Ruby: команды растут, нанимают много и параллельно; единых критериев оценки кандидатов нет — решения зависят от интервьюера.
- **T:** сделать найм предсказуемым и справедливым.
- **A:** внедрил комплексную систему оценки кандидатов: критерии и структура этапов, единая шкала, распределение ролей интервьюеров, обратная связь кандидату.
- **R:** процесс стал единым для практики; качество решений выросло (снизились «случайные» наймы и разногласия между интервьюерами).
- **Рефлексия:** «Ошиблись в найме — дороже, чем в архитектуре: человека не переписать, можно только развивать или расставаться. Поэтому дешевле вложиться в критерии».
- **Формат:** 2 мин.

## История 3. Развитие: 5 повышений и преемник (Самокат)

**Отвечает на:** развитие, мотивация, делегирование, преемники, «как растите людей».

- **S:** Samokat.tech, три команды (18+ разработчиков), формировал команды с нуля.
- **T:** командам нужен рост людей, а мне — перестать быть единственной точкой экспертизы.
- **A:** выстроил работу через 1:1 и планы развития, раздавал зоны ответственности, менторил персонально, готовил преемника руководителя команды.
- **R:** 5 разработчиков выросли до повышения, включая **преемника руководителя команды**; команды продолжили работать без моего постоянного участия.
- **Рефлексия:** «Растить — значит отдавать зоны, а не задачи. Первое время страшно: сделают хуже, чем ты. Но без этого ты — бутылочное горлышко».
- **Формат:** 2–3 мин; усиливается цифрой «~20 выросших за 9 лет».

## История 4. Выращивание лидеров: 3 разработчика → тимлиды (Телематика)

**Отвечает на:** развитие в лидеров, преемники, «какой у вас результат через людей».

- **S:** Soft Telematics, команда из 7 разработчиков.
- **T:** команде нужны были свои лидеры: масштаб проектов («Платон», «Обоз», «Коспро платные дороги») рос.
- **A:** менторил троих middle/senior системно: расширял ответственность, доверял вести направления и людей, разбирал управленческие ситуации.
- **R:** все трое выросли до позиций руководителей команд.
- **Рефлексия:** «Лучший результат лидера — люди, которые сами стали лидерами. Это же и есть ответ на страх "меня подсидят"».
- **Формат:** 2 мин.

## История 5. Преемник и делегирование (Баланс, команда 9)

**Отвечает на:** делегирование, преемники, «не бутылочное горлышко», процессы.

- **S:** Balance Platform, команда из 9 разработчиков; процессы от дизайна до поставки, дежурства, релизы.
- **T:** команда должна работать устойчиво, а не «пока лид в отпуске».
- **A:** ввёл PBR и процесс дежурств, распределил зоны (релизы, качество, архитектурные решения), подготовил преемника руководителя команды.
- **R:** преемник подготовлен; пропускная способность системы выросла, стабильность и дисциплина процессов улучшились.
- **Рефлексия:** «Процессы — то, что остаётся после тебя. Если всё держится на лиде — это не команда, а зависимость».
- **Формат:** 2 мин.

## История 6. Защита интересов человека перед руководством (Райф)

**Отвечает на:** «защищали команду/человека перед руководством», влияние, коммуникации вверх, справедливость.

- **S:** Райф, один из сотрудников вырос до уровня выше своего грейда, но формального решения о повышении не было.
- **T:** справедливость и удержание сильного человека; нужно обосновать повышение перед руководством.
- **A:** собрал факты (результаты, зона ответственности, влияние на команду), подготовил обоснование и **инициировал повышение**.
- **R:** повышение состоялось; человек остался и продолжил рост.
- **Рефлексия:** «Лид должен быть адвокатом своих людей наверху. Если не я — то кто?»
- **Формат:** 2 мин.

## История 7. Конфликт: спор двух сильных инженеров об архитектуре ✳

**Отвечает на:** конфликты, принятие решений, работа с сильными людьми, техспор.

- **S ✳:** двое сильных разработчиков спорят о решении (пример из твоей практики: DDD-разбиение, миграция БД, ClickHouse↔PostgreSQL); спор затягивается, страдает команда.
- **T:** принять решение, не потеряв ни одного из них и не сломав отношения.
- **A:** выслушал отдельно каждого; свёл спор к критериям (нагрузка, стоимость эксплуатации, риск, срок) и данным; договорились о POC/замере на узком кейсе; назначил владельца решения; зафиксировали «disagree and commit».
- **R:** решение принято на данных, оба продолжили работать; спор не перешёл в личный.
- **Рефлексия:** «Пока спор идёт про "кто прав" — он бесконечен. Как только появляется критерий — он заканчивается. Плюс: недовольный решением не значит потерянный человек».
- **Формат:** 2–3 мин. **Нужны твои реальные детали** (какое решение, какой критерий решил).

## История 8. Конфликт сроки vs качество/техдолг с бизнесом ✳

**Отвечает на:** коммуникации со смежниками, конфликты с бизнесом, защита команды, аргументация.

- **S ✳:** бизнес требует фичу к дате; команда видит, что без технической работы (техдолг/миграция) сроки и качество будут под угрозой.
- **T:** не сорвать бизнес-обещание и не загнать команду в переработки и техдолг.
- **A:** пришёл не с «нет», а с вариантами и ценой: сокращённый скоуп, этапность, отдельная доля спринта на техдолг; показал риск, если не делать.
- **R:** договорились о скоупе и выделенной доле на техдолг; сроки выдержаны.
- **Рефлексия:** «Спорить с бизнесом бесполезно — надо давать выбор и цену. И никогда не приносить только проблему».
- **Формат:** 2 мин. **Нужны реальные детали.**

## История 9. Сложное решение по людям: несоответствие и расставание ✳

**Отвечает на:** увольнения, испытательный срок, «самое сложное решение по людям» — **обязательный блок** официальной секции.

- **S ✳:** сотрудник не показывает ожидаемого прогресса (или не соответствует уровню после изменений).
- **T:** дать честный шанс и принять решение вовремя — и для команды, и для человека.
- **A:** зафиксировал ожидания письменно; составил план с точками контроля; давал конкретную обратную связь (SBI), не оставляя неясностей; по итогам — честный разговор и расставание, человечно и без сюрпризов.
- **R:** команда увидела, что ожидания реальны; человек ушёл без обиды (или с минимальными потерями); процесс найма впоследствии улучшен.
- **Рефлексия:** «Если человек удивлён решением — это моя вина: значит, я не говорил правду раньше. С тех пор фидбек — в момент события».
- **Формат:** 2–3 мин. **Если реального увольнения не было** — честно сказать об этом и рассказать про отказ в повышении/разговор о несоответствии грейду.

## История 10. Токсичный топ-перформер ✳

**Отвечает на:** кейс из официального банка — «здоровье команды vs производительность».

- **S ✳:** сильный инженер, который даёт результат, но токсичен к коллегам (резкость в ревью, обесценивание).
- **T:** сохранить и результат, и команду.
- **A:** зафиксировал конкретные факты (не «токсичен вообще», а что и когда), провёл прямой разговор с границами и последствиями, дал время; если рецидив — решение о расставании.
- **R:** поведение изменилось / произошло расставание; команда выдохнула.
- **Рефлексия:** «Топ-перформер — не индульгенция. Один токсичный человек стоит дороже, чем его вклад: он выбивает людей, а замену искать месяцами».
- **Формат:** 2 мин. **Реконструкция** — если похожего не было, не рассказывать; можно честно ответить принципом + близким реальным примером.

## История 11. Провал: миграция не завершена в период (Райф)

**Отвечает на:** «срыв сроков», «неудачные решения», рефлексия — **официально ожидаемый блок**.

- **S:** Райф, миграция одного из продуктов на новую инфраструктуру.
- **T:** довести миграцию в рамках периода работы.
- **A:** курировал миграцию, выстраивал этапность и готовность; параллельно — архитектурные схемы, роудмап, техдолг.
- **R:** готовность достигла 80% — миграция не была завершена в мой период; передана команде.
- **Рефлексия:** «Я недооценил связанность продукта и цену параллельной работы по трём командам. Вывод: миграцию нужно резать на независимые этапы с ранними измеримыми вехами и защищать ресурс отдельно — иначе она всегда проигрывает текучке».
- **Формат:** 2 мин. Честно и без самобичевания — это готовая история «провал + вывод».

## История 12. Инженерная культура и процессы (Дикси / Самокат / Баланс)

**Отвечает на:** технические вопросы лида — код-ревью, стандарты, техдолг, баланс код/менеджмент.

- **S:** в разных командах процессы не были системными (ревью «как получится», CI блокирует релизы, техдолг копится).
- **T:** сделать качество и поставку предсказуемыми, не давя сверху.
- **A:** Дикси — единые критерии код-ревью (обязательные замечания vs рекомендации), параллельный CI вместо последовательного, DevContainers и скрипты для стандартного запуска; Самокат — DDD и сквозные процессы для новых команд; Баланс — стандарты ревью, библиотека Core, матрица компетенций.
- **R:** скорость поставки и предсказуемость выросли, новые разработчики включаются быстрее.
- **Рефлексия:** «Стандарты работают, когда это договорённость и автоматизация, а не приказ. Линтер надёжнее уговоров».
- **Формат:** 2 мин; здесь же — позиция про баланс код/менеджмент.

---

## Позиция: баланс код vs менеджмент (спросят почти наверняка)

> «Я 20 лет в разработке и не уходил из неё: последняя роль — Lead Backend Engineer, это hands-on лидерство. Моя формула: основной вклад — через команду, но руки сохраняю на сложных задачах, архитектуре и ревью. Это не "остатки времени", а осознанно: без технической глубины лид теряет право на решения и доверие сильных инженеров. Чем больше команда — тем меньше кода, и я это принимаю как норму: масштаб через людей».


---

## Дополнения под новые боевые кейсы

### История 13. Смежные команды и общая цель (Райф)
**Отвечает на:** блокирующая смежная команда, синхронизация, стейкхолдеры, влияние без власти.
- **S:** три команды в одном юните — у каждой свои приоритеты и свой взгляд на очередность работ.
- **T:** синхронизировать так, чтобы запуски не блокировали друг друга.
- **A:** ввёл общий ритм и единый подход к техроудмапу, синхронизировал приоритеты через общую картину, договаривался о взаимных обязательствах (что каждая команда даёт другим).
- **R:** команды работали из общего плана, а не из локальных бэклогов; блокировок стало меньше.
- **Рефлексия:** «Смежника нельзя "попросить подвинуться" — нужно показать, что от этого выигрывает его собственный план».

### История 14. Стандарты и bus-factor (Дикси / Самокат)
**Отвечает на:** «что вы сделали для стандартов команды», код-ревью, онбординг, bus-factor, системность.
- **S:** процессы ревью и запуска не системны; знание о критичных местах живёт в головах.
- **T:** сделать качество и онбординг предсказуемыми, снизить зависимость от отдельных людей.
- **A:** Дикси — единые критерии код-ревью (обязательные замечания vs рекомендации), параллельный CI, DevContainers и скрипты стандартного запуска; Самокат — сквозные процессы и DDD для новых команд; кросс-ревью как практика.
- **R:** новые разработчики включаются быстрее, релизы предсказуемее, bus-factor снижен.
- **Рефлексия:** «Стандарт работает, когда это договорённость и автоматизация. Линтер надёжнее уговоров, а кросс-ревью — дешевле, чем потеря единственного знающего».

### История 15. Инцидент и вывод (формат ответа)
**Отвечает на:** «крупнейший факап», blameless postmortem.
- **Каркас без деталей:** моя роль в моменте → как тушили → разбор без виновных → что изменилось в системе (алерты/автотесты/процесс) → вывод. Если своей истории с пад prod нет — не выдумывать: использовать миграцию 80% (история 11) как «недоделка + вывод» или честно сказать, что крупных аварий не вёл.

## Как отвечать быстро (шпаргалка соответствий)

| Вопрос | История |
|---|---|
| Почему тимлид, что даёт роль | модель (§ выше) + История 3/4 |
| Как ставите цели | История 1 |
| Найм | История 2 |
| Развитие и повышения | Истории 3, 4, 5 |
| Делегирование | Истории 5, 3 |
| Конфликты | Истории 7, 8 |
| Увольнение / сложное решение | История 9 (+10) |
| Защита команды / влияние вверх | История 6 |
| Провал и вывод | История 11 |
| Код-ревью, техдолг, процессы | История 12 |
| Публичность / экспертиза | семинары 10+, RubyRussia, TechLead Conf |
| Смежники / блокировки | История 13 |
| Стандарты, bus-factor | История 14 |
| Инцидент / факап | История 11, 15 |

## Связанные документы
- [`methodology.md`](methodology.md) — скелеты ответов и тайминг
- [`knowledge-base.md`](knowledge-base.md) — канон под каждый блок
- [`training/cases.md`](training/cases.md) — прогон этих историй на вопросы