# Баланс Платформа (сентябрь 2019 — апрель 2023)

Роль по CV: Senior-разработчик → Руководитель команды → Руководитель Ruby-практики.
Продукт: LaaS-платформа кредитной автоматизации (собственный продукт, не аутсорс).

> Черновик по итогам рассказа (09.10.2026). «уточнить» — открытый вопрос.

## Почему ушёл из Телематики (важно как контекст решения)

- Решение уходить принял примерно **за полгода** до ухода, в момент конфликтов с руководством.
- Для Сергея был отдельный вызов: **остаться и выбрать момент для ухода самому** — когда у него будет хорошая позиция на рынке и формально всё работало хорошо. Даже при плохих отношениях с руководством формальных поводов предъявить претензии не было. Со временем отношения даже наладились.
- Но он понял: постоянные пожары — **системная проблема компании** (заказной софт для государственных компаний). Люди принимают авральную систему: постоянные переработки, работа на выходных, жёсткие дедлайны, невозможность влиять на объём работ.
- Вывод: «это не моя история» → начал искать предложения.

## Вход в Баланс

- Переходил на роль **ведущего разработчика** — должность изначально не тимлидская.
- Шёл **к сильному тимлиду**, который ему понравился тем, как рассказывал про ситуацию и как мыслил.
- Было несколько офферов; выбрал этот, потому что понял: здесь сможет влиять и улучшать (этого хотелось).
- Важное совпадение ценностей: команда продуктивно трудится и **делает свой продукт** — «совсем другая история». Понравился и менеджер. «Ребята меня вдохновили».
- Первые шаги: порешал много технических проблем, настроил автотесты.

## Хронология ролей

### 1. Ведущий разработчик

- Техническая работа, автотесты, решение технических проблем.

### 2. Руководитель команды (первый коллектив)

- **Не прошло и года**, как их тимлид уволился: в компании вводили кодекс этики; тимлид любил нецензурно выражаться и посчитал, что это «не его вайб» — покинул компанию.
- **К удивлению Сергея, тимлидом назначили не его** — ушедший тимлид, судя по всему, сам рекомендовал преемника.
- Назначенный парень был слишком медленный и спокойный; **через ~3 месяца выгорел и ушёл** — и тогда лидерство передали Сергею.
- Период «спокойного выстраивания продукта»: выстраивал процесс, **планомерная работа с Jira** (не в чатах, а именно в Jira), работа с документацией.

### 3. Второй проект: кредит наличными

- Ему предложили возглавить **ещё один проект** — из команды выделили небольшую вторую команду. Задача: меньше увязать в операционке внутри первого коллектива.
- Цель: **вырастить самостоятельность в ребятах** — больше процессов доверял, больше делегировал.
- Возник коннект с одним разработчиком, на которого возлагал надежду как на следующего тимлида.
- Две команды параллельно:
  - старый проект — в зоне расширения и стабилизации;
  - новый (кредит наличными) — на стадии стартапа, **запустить в течение нескольких месяцев**.
- Справились малым коллективом: не потеряли процессы, соблюли качество, команда работала **независимо от Сергея** — он входил только в кризисные моменты.
- Это удалось. Начальство увидело: обе команды могут работать без него.

### 4. Руководитель Ruby-практики

- Предложили возглавить **всю Ruby-практику**. Согласился с радостью — новый вызов.
- Задачи: улучшение практик, рост сотрудников, внедрение практик:
  - 1:1 (системно; «ван-ту-ваны»),
  - **матрица компетенций** — как оценивать людей, как проходят raise'ы,
  - отслеживание объективных метрик по разработчикам: у кого проблемы, где слабые зоны.
- **Метрики через Jira:** сколько кода производят, сколько задач закрывают, как долго задачи висят на человеке, оценки против факта, сколько возвратов по задачам. Много метрик выстраивали вместе с руководителем: с него шла задача «что надо померить», Сергей придумывал как; плюс добавлял свои метрики.
- **Семинары для разработчиков:** архитектура, лучшие практики, микросервисная архитектура, работа с задачами.

## Найм

- **Телематика:** примерно на 5 сотрудников Сергея начали активно привлекать к найму.
- **Баланс:** тимлид часто делегировал ему собеседования новых Ruby-разработчиков и **доверял решению брать/не брать**, полагался на его оценку.
- **~5 человек наняты через Сергея.**

## Увольнения и расставания (важный блок)

- **Первый случай — ротация (Миша).** Разработчик был нанят предыдущим тимлидом до прихода Сергея; не тянул по квалификации. Провести разговор доверили Сергею. Сказал прямо: «у тебя не получается, команда работает в другом темпе; мы много тебе объясняем, вкладываемся, все открыты для тебя — но самостоятельно ты задачи решать не способен». Человек расстроился, но был готов. **Перевели в другую команду.** Там был сильный дефицит кадров — брали любого. Он поработал ещё ~месяц-полтора, сначала речь шла о продлении испытательного срока, но в итоге и там его попросили уйти — не справился.
- **Второй случай — бывший коллега Сергея с прошлого места работы.** Ротации для него не было: Сергей **рекомендовал увольнение** и провёл разговор сам.
  - Контекст: коллегу наняли, **пока Сергей был в отпуске**, при предыдущем тимлиде. Когда Сергей вернулся (уже тимлидом), у человека оставалось ~2 месяца испытательного срока.
  - Наблюдение: работает медленно, старается, «закапывается», не вывозит — примерно **вдвое медленнее остальных**; разрыв не «немного».
  - Разговор: много коммуникации; сказал, что вклад недостаточен — «по стараниям и желанию всё есть, но не тянет». Человек понял, сильно спорить не стал, но эмоционально принять было тяжело — «проронил скупую мужскую слезу». Сергей оказал максимальную поддержку.
  - После: остались на связи во «ВКонтакте»; человек устроился в небольшую компанию с более низким темпом и там смог раскрыться.
  - **Принцип Сергея:** «для компании лучше ошибиться и расстаться с человеком сильным и достойным, чем оставить недостойного» — иначе потом тратишь время, деньги и время других сотрудников на его увольнение. Риск есть всегда, но он склонен «закручивать гайки»: лучше перестраховаться и найти человека, в котором не будет сомнений.
- Итог: у Сергея есть **реальный опыт увольнений/расставаний из своих команд** — с прямыми разговорами лицом к лицу, не через HR.

## Эмоциональная дистанция (сильный личный кейс)

- Когда был тимлидом, **сильно привязывался к ребятам**: уход человека из команды переживал как большую потерю.
- Что изменил после нескольких эпизодов: **перестал эмоционально привязываться к людям как к друзьям на работе** — «коллеги, работа — работа», чуть больше баланса.
- Важный нюанс: в **1:1 ничего не поменялось** — как и раньше, он персональный защитник и ментор человека, максимально эмпатично вытаскивает его позицию. Изменилось одно: душевно перестал прикипать, потому что это работа и человек может уйти.
- Это прямо подходит под вопрос «как вы держите границу и не выгораете от потерь в команде».

## Развитие людей и преемники

- Уходя на позицию руководителя практики, **менторил двоих**, чтобы они стали тимлидами в командах: **девушка и парень**. Оба успешно дальше вели свои проекты.
- **Павел** — команда «кредит наличными»: Сергей был тимлидом рядом, Павел всё больше и больше руководил, потом возглавил команду.
- **Второй парень (имя не помнит)** — опытный разработчик, Сергей помогал ему занять должность тимлида и **помогал коммуницировать**. По состоянию на 2026 всё ещё работает в Баланс Платформе, у него уже команда больше.
- По CV: двое менти-тимлидов (девушка + парень) — уточнить, совпадает ли это с Павлом и вторым парнем или это четыре разных человека.

## Публичность

- **Телематика:** внутренние митапы — доклады про Docker, системный подход, исправление проблемных продуктов, решение кризисных ситуаций.
- **Баланс:** вышел на **внешние конференции** — доклад про архитектуру, в т.ч. **чистую архитектуру в Ruby on Rails** проектах. Продолжал участвовать во внутренних митапах.

## Почему ушёл из Баланса

Причины сложились в один вектор:

1. **Курс компании:** продукты стали заказными — компания превратилась в «придаток к банкам», перестали быть владельцами продукта. Делали то, что говорят банки; продукты делались малыми ресурсами и в сжатые сроки — «невозможно было делать ничего стоящего». Проекты закрывались **до выхода в продакшн**.
2. **Частая смена руководства:** директор менялся несколько раз, менялся руководитель департамента; резкие смены курса без улучшений. Начались финансовые проблемы.
3. **Потеря реального импакта:** как руководитель практики он мог рассказывать, мотивировать, но **не мог связать это с метриками и премиями/KPI** команд — «сколько угодно хороших вещей рассказывать». Обратной связи не было.
4. **Увеличилась дистанция от людей:** раньше был в командах и мог напрямую задавать, «делаем теперь так»; теперь в каждой команде свои тимлиды и разработчики, **никак от него не зависящие**. Возможность внедрять свои регламенты, документы и практики исчезла.
5. Даже когда придумал **инструмент для оптимизации** — до внедрения не дошло: «компания шла своим чередом, а я своим».
6. Итого: позиция, подход компании и то, как использовали его работу, не подошли → начал искать вариант.

## Рефлексия

- Роль руководителя практики — совсем другие задачи, чем продуктовая разработка: меньше прямого влияния, больше «влияния через других».
- Ключевая неудовлетворённость: **импакт без рычага** (метрики, премии, KPI, прямое подчинение).
- Ценность продуктовой модели и владения продуктом — подтвердилась как личный критерий выбора работы.

## Грейды и матрица компетенций (подробно)

- Как руководитель Ruby-практики **расписывал матрицу компетенций**: что требуется для каждого грейда в знаниях.
- Матрицу **до внедрения довели**, но **повышений через неё никто не получил**: долгий процесс ассессмента и принятия текущих грейдов.
- Куда матрица реально работала: где ассессменты уже были приняты, Сергей **курировал процесс**, спрашивал, что не получилось, мотивировал пробовать снова.
- **Аргумент про повторные попытки:** «сама попытка — это тоже опыт: сталкиваешься с проблемой, понимаешь, чего не хватает, и готовишься дальше. Иначе в своём коконе можно сидеть очень долго».
- Вывод по зрелости процессов: в разных компаниях повышения часто шли **«на глаз»**, без формальной матрицы.

## Открытые вопросы

1. Точное устройство LaaS-платформы: для кого, какой масштаб (пользователи, сделки, нагрузка).
2. Как именно Сергей получил команду после ухода тимлида: передали формально или он сам проявил инициативу.
3. Названия продуктов/проектов: «кредит наличными», автокредит, что-то ещё.
4. Что за инструмент оптимизации придумал и почему не внедрили.
5. Метрики практики: конкретные цифры и что по ним выяснилось.
6. Матрица компетенций: как выглядела, по каким уровням, что с raise'ами.
7. Число людей в практике (сколько всего Ruby-разработчиков).
8. Судьба двух менти-тимлидов (девушка и парень) — как складывалось дальше.