От Senior к Tech Lead: что меняется кроме зарплаты

Когда понял, что всё изменилось

Понедельник, 9:47. Я открываю pull request с рефакторингом, который планировал неделю. Архитектура красивая, код чистый, тесты зелёные. Через 15 минут — встреча с продактом. Затем синхронизация с бэкендом. Потом личная встреча с джуном. Затем планирование. К 18:00 я понял, что за весь день написал ровно 12 строк кода.

Зато:

• Разрулил конфликт приоритетов между продактом и бизнесом
• Объяснил джуну, почему его подход к кешированию сломает систему через месяц
• Согласовал архитектуру интеграции с командой бэкенда
• Провёл планирование на 2 недели для команды из 6 человек

Старый я (Senior): "Я сегодня ничего не сделал, только встречи." Новый я (Tech Lead): "Я сегодня разблокировал команду на 2 недели работы."

Это первое, что меняется: критерий продуктивности. Раньше я измерял день в закрытых тасках. Теперь — в разблокированных людях.

Что действительно меняется (спойлер: почти всё)

1. Фокус внимания: от задач к людям

Senior Developer:

• "Как решить эту задачу быстрее?"
• "Какой паттерн тут подходит?"
• "Как оптимизировать этот запрос?"

Tech Lead:

• "Кто из команды может вырасти на этой задаче?"
• "Почему мидл застрял на этой таске уже третий день?"
• "Как распределить задачи, чтобы никто не выгорел к релизу?"

Реальный кейс из практики:

Мидл застрял на таске с оптимизацией запроса. Третий день пытается выжать performance через индексы. Я как Senior: "Дай, я посмотрю" → фиксу за 20 минут → все счастливы.

Я как Tech Lead: сажусь рядом, смотрю вместе. Оказывается, проблема не в индексах, а в том, что он не знает про EXPLAIN ANALYZE. Трачу час на объяснение. Мидл сам находит решение. Через месяц он уже консультирует джунов по оптимизации запросов.

Разница:

• Senior решил проблему → +1 фича
• Tech Lead обучил мидла → +∞ фич в будущем

2. Коммуникация важнее кода

Раньше я мог сидеть в наушниках 6 часов подряд и писать код. Это была медитация. Сейчас самый длинный фокусный блок — 90 минут. И это роскошь.

Новая реальность:

Как изменился мой день:

3. Ответственность: от "моего кода" к "нашему продукту"

Кейс, который всё изменил:

Релиз в пятницу. Джун запушил фичу в продакшен. В субботу утром — падение сервиса. N+1 запросы, которые я пропустил в код-ревью.

Старая логика (Senior): "Не я писал, не моя проблема."

Новая реальность (Tech Lead): звонок от CTO в субботу 9:00. "Почему упало? Ты Tech Lead, ты отвечаешь за стабильность."

Я отвечаю:

• За код, который сам не писал
• За архитектурные решения всей команды
• За то, что джун не знал про EXPLAIN
• За то, что в код-ревью проглядел проблему
• За отсутствие автоматических проверок на N+1

Что я изменил после этого:

1. Добавил в CI проверку на N+1 (gem bullet для Rails)
2. Провёл воркшоп по performance для команды
3. Обновил чек-лист код-ревью
4. Внедрил правило: критичные PR ревьюят минимум 2 человека

4. Время: фрагментированное vs фокусное

Самая болезненная метаморфоза.

Senior может заблокировать календарь на 4 часа и погрузиться в глубокую работу. Tech Lead так не может. У тебя постоянно кто-то застрял:

• "У меня CI упал, не понимаю почему"
• "Продакт просит оценку срочной фичи"
• "Конфликт в репозитории, как мерджить?"
• "Инфра-команда спрашивает про нагрузку на новый сервис"

Мой топ-3 прерываний за день (реальная статистика):

1. Технические вопросы: 8-12 раз (Slack, подходят к столу)
2. Разблокировка задач: 5-7 раз (CI, код-ревью, архитектура)
3. Согласования: 3-5 раз (продакт, смежные команды, менеджмент)

Итого: 16-24 прерывания в день. Средняя длина фокусного блока: 40-60 минут.

Как я адаптировался:

• Временные блоки: отрезки по 90 минут, чётко в календаре с пометкой "Время для фокуса"
• Асинхронная коммуникация: учу команду сначала писать в Slack с контекстом, а не "можно вопрос?"
• Часы для вопросов: 2 окна в день по 30 минут — "приходите с любыми вопросами"
• Глубокая работа вечером: 2-3 раза в неделю остаюсь на час после команды, когда тихо

Навыки, которые внезапно стали критичными

Я думал, что хороший код — это 80% работы Tech Lead. Ошибался. Вот что реально определяет успех:

1. Умение объяснять "почему"

Плохой Tech Lead: "Делаем микросервисы, потому что так модно."

Хороший Tech Lead: "Делаем микросервисы, потому что команда выросла до 15 человек, монолит стал узким горлышком при деплое, и бизнес требует независимых релизов модулей. Но платим за это сложностью инфраструктуры и распределёнными транзакциями. Вот компромиссы..."

Кейс:

Продакт хочет real-time чат. Джун предлагает WebSockets. Я объясняю:

"WebSockets — это про постоянное соединение. У нас 100k активных пользователей. Это 100k открытых соединений. Сервер упадёт. Давайте сначала посчитаем: сколько сообщений в секунду? Критична ли задержка в 2-3 секунды? Может, Server-Sent Events или long polling дешевле?"

Команда понимает логику выбора, а не просто технологию.

2. Делегирование (самое сложное)

Мой провал №1:

Критичная фича, 3 дня до релиза. Мидл делает медленно. Я думаю: "Быстрее сам сделаю." Забираю таску. Делаю за ночь. Релиз успешен.

Что пошло не так:

• Мидл демотивирован ("я недостаточно хорош")
• Команда не растёт (я решаю все сложные задачи)
• Я выгораю (работаю за двоих)
• Бизнес зависит от одного человека (если я уйду — всё встанет)

Правильный подход (который я освоил через боль):

1. Оценить риск: если фича критична, но есть 3 дня — риск приемлемый
2. Сесть рядом с мидлом: "Давай разберём вместе. Где застрял?"
3. Парное программирование: первый час вместе, дальше — с поддержкой
4. Дать упасть, но подстраховать: смотреть PR особо тщательно

Результат:

• Мидл делает фичу за 2.5 дня (медленнее меня, но!)
• Он вырос
• В следующий раз сделает быстрее
• Я освободил время на другие задачи

3. Эмоциональный интеллект

Что это значит на практике:

Сценарий 1: Джун третий день бьётся над багом. Я вижу: он раздражён, устал, близок к выгоранию.

Плохой подход: "Разберись сам, это простой баг."

Правильный подход: "Вижу, ты застрял. Давай сделаем паузу: пойдём попьём кофе, обсудим проблему на свежую голову. Иногда баг — это не про знания, а про усталость."

Сценарий 2: Мидл опоздал на встречу в третий раз за неделю.

Плохой подход: публично отчитать.

Правильный подход: личная встреча после. "Заметил, что ты опаздываешь чаще обычного. Всё ок? Может, что-то мешает?"

Оказывается, у него сломался детский сад, утром возит ребёнка к бабушке. Решение: сдвигаем встречу на полчаса позже для всей команды.

Вывод: люди — не ресурсы. У них жизнь, проблемы, эмоции. Учитывать это — не слабость, а прагматизм. Счастливая команда пишет лучший код.

4. Умение говорить "нет"

Худший навык для Senior, лучший для Tech Lead.

Продакт приходит: "Нам срочно нужна интеграция с новым API, клиент требует."

Senior (я раньше): "Ок, сделаем."

Tech Lead (я сейчас): "Давай посмотрим на roadmap. У нас сейчас рефакторинг auth, миграция БД и два критичных бага. Эта фича добавит 2 недели. Что из текущего мы дропаем? Или сдвигаем дедлайн?"

Результат: продакт идёт к бизнесу, бизнес решает приоритеты. Часто оказывается, что интеграция не такая уж критичная.

Мои провалы (чтобы вы не повторяли)

Провал #1: Микроменеджмент

Что случилось:

Первый месяц Tech Lead'ом я ревьюил каждую строчку кода. Требовал переписывать, если не по моим стандартам. Указывал, какие переменные как назвать.

Результат:

• Команда перестала проявлять инициативу ("всё равно переделывать")
• Я тонул в ревью (по 3 часа в день)
• Мидлы росли медленно (не принимали решений сами)

Что изменил:

• Ревью на архитектуру и логику, не на стиль (для стиля — линтеры и prettier)
• Правило 2 замечаний: если больше — зову на парное программирование, а не пишу портянку комментариев
• "Я бы сделал иначе, но твой вариант тоже работает" — часто говорю эту фразу

Провал #2: Не делегировал код-ревью

Я думал: "Только я знаю архитектуру, только я могу качественно ревьюить."

Результат:

• Узкое место: PR висели по 2-3 дня в очереди ко мне
• Команда не росла (мидлы не учились ревьюить)
• Я выгорал (30-40 PR в неделю)

Решение:

• Мидлы ревьюят код джунов (я подстраховываю)
• Я ревьюю только критичные части (auth, payments, core logic)
• Еженедельные воркшопы по код-ревью: разбираем интересные PR всей командой

Провал #3: Забыл про код

Первые 2 месяца я так погрузился в менеджмент, что почти не писал код. Только ревью, встречи, планирования.

Результат:

• Потерял навык (через 3 месяца заметил, что медленнее пишу)
• Отдалился от команды (они в коде, я в Confluence)
• Потерял радость (я кодил, потому что люблю код, а не встречи)

Решение:

• Минимум 20% времени на практическую работу с кодом
• Беру сложные технические задачи (не рутину, а то, что интересно и развивает команду)
• Среда — мой "фокусный день": никаких встреч, только код и архитектура

Как понять, готовы ли вы к переходу

Не каждый Senior должен становиться Tech Lead. Это разные карьерные треки.

Вы готовы, если:

• Вам интересно учить людей (не просто делиться знаниями, а видеть, как они растут)
• Вы можете объяснить "почему", а не только "как"
• Вас бесит, когда команда работает неэффективно, и вы хотите это исправить
• Вы готовы тратить меньше времени на код (и это не пугает)
• Вы умеете слушать (не только говорить)
• Вам не страшна ответственность за решения, которые принимают другие по вашим советам
• Вы готовы к фрагментированному дню (прощай, 4 часа фокуса)

Вы НЕ готовы (и это нормально), если:

• Код — это ваша медитация, и вы хотите кодить 80% времени
• Встречи вызывают отторжение (не усталость, а именно отторжение)
• Вам не интересно разбираться в людях и их проблемах
• Вы хотите роста зарплаты, но не ответственности
• Вам важнее глубокая техническая экспертиза, чем широта

Чек-лист готовности к переходу

Пройдитесь по этим вопросам честно.

Технические навыки:

• Вы можете спроектировать архитектуру системы от начала до конца
• Вы знаете компромиссы основных технологий в вашем стеке
• Вы умеете проводить качественное код-ревью (не только находить баги, но и учить)
• Вы понимаете production: мониторинг, деплой, инциденты

Soft skills:

• Вы провели минимум 5 технических интервью (и понимаете, как оценивать людей)
• Вы менторили джуна или мидла (и видели результат)
• Вы умеете разрешать конфликты (не избегать, а разрешать)
• Вы можете объяснить сложное простыми словами (тест: расскажите бабушке, что такое API)

Мотивация:

• Вы хотите быть Tech Lead'ом не ради денег, а ради роста команды
• Вам интересно влиять на продукт, а не только на код
• Вы готовы учиться заново (потому что это другая работа)

Если 10+ галочек — вы готовы. Если меньше — дайте себе время.

Практические советы для первых 90 дней

Дни 1-30: Наблюдайте и слушайте

Не делайте:

• Переписывать процессы с нуля
• Критиковать старые решения
• Пытаться доказать, что вы "главный"

Делайте:

• Личные встречи со всеми в команде (узнать: что их бесит, что радует, где застревают)
• Обзор кода: попросите каждого показать кусок кода и объяснить архитектуру
• Тихий код-ревью: ревьюите всё, но пока без радикальных требований

Цель: понять контекст, заслужить доверие, увидеть боли команды.

Дни 31-60: Первые изменения

Выберите 1-2 боли, которые можно решить быстро:

• CI долго собирается → распараллелить
• Код-ревью висят по 3 дня → внедрить ротацию ревьюеров
• Нет документации архитектуры → провести воркшоп, нарисовать C4 диаграммы

Принцип: быстрые победы. Команда должна увидеть результат вашего лидерства, а не только встречи.

Дни 61-90: Ритм и процессы

Внедрите регулярность:

• Еженедельные личные встречи с каждым (30 минут, не про задачи, а про рост и проблемы)
• Технический синк раз в две недели (обсуждаем архитектуру, техдолг, эксперименты)
• Ежемесячная ретроспектива (что бесит, что улучшить)

Документируйте решения:

• ADR (Architecture Decision Records) для всех важных решений
• Руководство по адаптации для новичков
• Руководство по инцидентам для production

Что меняется в зарплате (честно)

Все говорят про soft skills, но давайте про деньги.

Средний рост зарплаты при переходе Senior → Tech Lead:

Важно:

• Просто title "Tech Lead" без изменения ответственности = рост 0-10%
• Реальное лидерство команды 5+ человек = рост 20-40%
• Переход в другую компанию на позицию Tech Lead = рост 30-50%

Но:

Вы платите за рост зарплаты временем и стрессом:

• Больше часов (встречи + код = 50-60ч/неделю первые полгода)
• Меньше фокусного времени на код (если это ваша радость — будет грустно)
• Больше ответственности (звонки в выходные, когда прод упал)

Окупаемость перехода:

• Финансовая: окупается через год (если рост зарплаты > 20%)
• Карьерная: открывает путь в CTO, VP Engineering, Principal Engineer
• Эмоциональная: зависит от того, любите ли вы людей и процессы

Главная мысль

Tech Lead — это не просто Senior с более высокой зарплатой.

Это другая работа:

• Меньше кода, больше людей
• Меньше решений, больше объяснений
• Меньше "я сделаю", больше "мы сделаем"

Это переход от "я крутой разработчик" к "у меня крутая команда".

И если вам интересно растить людей, а не только код — это ваш путь.

Если нет — Staff Engineer, Principal, Architect ждут вас. И это не менее крутые треки.

Ключевые выводы:

1. Ваш код — это 20-30% работы. Остальное: ревью, менторство, архитектура, синхронизация.
2. Критерий продуктивности меняется: не "сколько я сделал", а "сколько разблокировал".
3. Ответственность растёт нелинейно: вы отвечаете не только за свой код, но и за код всей команды.
4. Делегирование — самый сложный навык: придётся учиться давать задачи другим, даже если вы сделаете быстрее.
5. Эмоциональный интеллект важнее технических скилов: умение слушать, мотивировать и разруливать конфликты.
6. Первые 90 дней — про доверие, не про революцию.
7. Не каждый Senior должен быть Tech Lead'ом: это нормально выбрать другой трек.

Что делать прямо сейчас

Если вы думаете о переходе:

1. Спросите себя честно: "Мне интересно растить людей или я просто хочу больше денег?"
2. Попробуйте на практике: возьмите джуна в менторство на 3 месяца. Если кайфуете — ваш путь.
3. Поговорите с менеджером: "Хочу попробовать лидерство. Можно взять часть задач Tech Lead'а?"
4. Учитесь сейчас:
   • Проводите код-ревью с обучающими комментариями (не просто "исправь", а "почему")
   • Участвуйте в архитектурных решениях
   • Предлагайте улучшения процессов

Если вы уже Tech Lead:

1. Найдите ментора (кто-то, кто прошёл этот путь)
2. Делегируйте хотя бы одну задачу сегодня (даже если вы сделаете быстрее)
3. Заблокируйте время для фокуса (хотя бы 2 блока по 90 минут в неделю)
4. Запланируйте личные встречи со всеми в команде (если ещё не делаете)

Если решили, что Tech Lead — не ваше:

1. Это нормально. Карьера Staff/Principal Engineer — это рост без менеджмента.
2. Поговорите с менеджером про альтернативные треки.
3. Инвестируйте в глубину, а не в ширину: архитектура, performance, security.

---

Связанные статьи:

• Математика найма джунов: когда окупается, а когда горят деньги
• Ошибка адаптации, которая стоит вам 42% команды