41 вопрос — 41 мини‑история. [DRAFT]

«День выдался самым обычным: над Питером нависла привычная облачная шапка, я как все мы работал работу…»

И тут в Telegram всплывает сообщение: “Нужна помощь тимлидов — пройдите опрос, а взамен получите рекламу”. Ну а кто из нас откажется от бесплатного промо?

Я написал «Согласен» — и вот лежит документ из 41 вопроса. Ответил на каждый, а потом подумал: почему бы не оформить всё это в статью? Вдруг чей‑то путь тимлида только начинается, и мои заметки сэкономят ему пару бессонных ночей.

Как читать эту статью

• 41 вопрос — 41 мини‑история.
• Я пишу честно: как есть в реальной жизни тимлида кросс‑функциональной команды из 22 человек.
• «Врезки в таком стиле» добавляют немного личных эмоций и контекста.
• Смело берите выдержки в свои чек‑листы, доклады и резюме.

Готовы? Тогда поехали.

Q1. Образование

Я пожалуй опишу себя так:

«Всегда стараюсь выжать из любой ситуации максимум — будь то работа, учёба или очередной хакатон.»

Я — выпускник Ярославского промышленно‑экономического колледжа им. Н. П. Пастухова и бывший студент СПб Политеха Петра Великого (высшее так и не закрыл, но это отдельная история).

Что я успел ухватить во время учёбы

• Работа в веб‑студии — писал фронт и бек, администрировал сервак с сайтами, тестировал на уязвимости и защищал днём и правки вносил ночью. Иногда после учебы в 19 ехал в офис, так как там лучше работается и сидел там до часу ночи.
• Постоянные заказчики с фриланса — прокачал навык «делать быстро и с качеством».
• Спортивное программирование + WorldSkills Russia — научился следовать ТЗ и критериям приемки (это, что DoD?)
• Лаборант ЦИТ в колледже — тянул сети, настраивал сервера, чинил интернет и принтеры (ещё и зарплату получал!).

Параллелизм? Да. Сон? Интересная концепция, но не слышал.

У нас было почти 6000 часов по базам данных (нормализация, проектирование, и т.д.), экономике предприятия и проектному управлению. Я тогда приставал к преподам: «Зачем мне это, если я просто разраб?» — на что получал философское «нужно».

Сегодня я понимаю, что именно эти фундаментальные знания помогают мне мгновенно погружаться в корень любой проблемы/задачи: от «почему упало» до «как оптимизировать косты».

MBA? Взять всё и сразу

Если бы у меня на руках был диплом MBA, уверен — выжал бы из программы по максимуму. Ключ не в корочке, а в умении превращать знания в действие. И вот здесь мой жизненный принцип «бери всё, что дают» срабатывает на сто процентов:

«Неважно, какой шильдик на двери — если видишь возможность, забирай и применяй.»

Вывод: классическое высшее, колледж, MBA — всё может стать трамплином, если подходить к учёбе как к проекту с задачами, дедлайнами и метриками успеха. Остальное — детали.

Q2. Когда в менеджмент?

«Сначала я просто писал код, потом понял, что хочу писать ещё и историю продукта — вместе с людьми, а не в одиночку.»

Я рос, рос долго. Сейчас сфера развивается быстрее, чем я раньше. Я был 15 - летним парнем, который учился в "закрытой" школе, у меня были отличные учителя умеющие заинтересовать, программирование со 2 класса, на информатике + кружок как обязательный.

Как всё начиналось

• За неделю проглотил курс HTML/CSS Евгения Попова, исписал две толстые тетради от корки до корки и…
• Первый заказ на Авито — сервис кредитования (лендинг + личный кабинет). Тогда же понял, сколько всего не знаю и как быстро надо расти.

«Чем больше я работал, тем больше я встречал ошибки менеджмента, из - за которых страдали мы - обычные разработчики. В голову все чаще приходила мысль, я должен не просто делать задачку, я должен влиять на продукт.»

От линейного разработчика к тимлиду

1. 7+ лет в проде — классический путь фронта с фулл‑стек привкусом.
2. Просьба о новой лычке — технический директор отвечает: «Ты не спец, у тебя просто талант писать код…»
3. Резкий поворот: ухожу техлидом — случайная вакансия цепляет желанием говорить с несколькими командами сразу.
4. Первые ростки менеджмента — небольшие команды в управление, бизнес‑цели, найм и менторинг.
5. Продукт продан → новый вызов → совмещаю роли тимлида и CТО текущего продукта.

Почему менеджмент всё‑таки “да”

• Влияние на продукт. Хочется определять траекторию, а не только реализацию.
• Влияние на людей. Растить сильных инженеров — самый масштабируемый способ делать крутые фичи.
• Непрерывное тех. развитие. СТО лычка требует держать руку на пульсе стека — код не бросаю, просто делюсь им реже.

«В чате “Боль Тимлида” однажды написали: “Каждый, кто начинает менторить, рано или поздно становится руководителем”. Пожалуй, это и есть мой путь.»

Итог: я не “ушёл” из тех. роли — я эволюционировал: добавил к навыку писать качественный код, способность строить среду, где этот код пишут другие.

Q3. Что изучать?

Если мы с вами вспомним, что было ранее, то давайте по порядку:

Люди: менторство и 1‑on‑1

• Начните с менторства. Программа «ведущий‑ведомый» резко ускоряет рост подопечного и самого наставника
• Освойте регулярные 1‑on‑1. Оптимальная длительность ~40‑45 минут, обязательна совместная повестка и фокус на обратной связи

Метрики: продуктовые и технические

Необходимо познакомиться с метриками продукта от стадии зародыша, до выхода на рынок

• product metrics: затраты на разработку, прибыль, окупаемость, и т.д.
• technical metrics: перфоманс под нагрузкой, учитесь читать перцентильные задержки (P90/95/99), чтобы понимать, где «болит» под нагрузкой

Системное мышление: System Design

• CTO и тех‑менеджер обязаны уметь собирать систему «из палок и гвоздей»: масштабирование, отказоустойчивость, cost control.

База знаний: книги и курсы

• От разработчика до руководителя [Камиль Фурнье]
• Элегантная головоломка. Системы инженерного менеджмента [Уилл Ларсон]
• Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО [Джеймс Стэньер]
• Радикальная прямота. Как управлять не теряя человечности [Ким Скотт]
• Трудные диалоги. Что и как говорить, когда ставки высоки [Паттерсон, Гренни, Макмиллан]
• https://link.excalidraw.com/l/4a6TZuhIabG/53dSoxSawv7 - собирал лично для начинающего менеджера

«Менторить хотя бы одного разработчика — самый быстрый способ понять, нравятся ли тебе люди больше, чем pull‑requests.»

Итог: чтобы плавно перейти из «просто разработчика» в менеджера, изучите стек навыков — люди → деньги → метрики → системы → процессы → знания. Осваивайте их последовательно, но применяйте сразу: заведите подопечного, посчитайте P&L маленькой фичи, соберите latency‑дашборд, проведите 1‑on‑1 и оформите матрицу компетенций. Через полгода вы уже начнете говорить на языке продукта и бизнеса, оставаясь технически убедительным.

Q4. Рост в/вне компании