Приветствую Хабр, это моя первая статья и я решил поделиться своим личным опытом развития в IT, изменению подходов к управлению командой и не остывающей любовью к волшебству кода. Просто еще одна история от еще одного программиста.

Немного о себе
Меня зовут Юрий, через месяц будет 16 лет с моей первой записи в трудовой книжке о работе в IT. Закончил мехмат, немного занимался наукой, работал в крупном американском аутсорсе, затем в красно-синем российском банке и последние 8 лет тружусь в технологических и AI стартапах. Да, столько опыта, а хоть что то написать решил только сейчас. В общем погнали.
Немного философии и кластеров
Я лично не разделяю руководство в директивном смысле и лидерство на какие то разные сущности и считаю, что это лишь разные грани одного и тоже умения сподвигать людей выполнять коллективно задачи, превосходящие возможности одного человека. Это можно сравнить с кластерными технологиями как в режиме single-master так и в режиме multi-master.
Как ни странно даже если кажется, что ты single-master и якобы единолично руководишь группой разработчиков или нескольким группами, то есть либо master более высокого порядка либо неявный master в виде "опытного разработчика", которые в значительной степени оказывают влияние на процесс, либо и то и другое, поэтому как принято в мат. доказательствах будем рассматривать более общий случай multi-master. Это к тому, что все мы "стоим на плечах гигантов" и благодарны за советы старших товарищей.
Стиль #1
Обычно, чтобы начать кого то на что то сподвигать достаточно личного желания и еще не иметь страха ответственности. Он будет позже, но там мы уже научимся его усмирять. Отличное сочетание чтобы добровольно вызваться на героическую борьбу с очередной непокоренной вершиной. Так было и у меня. И конечно при всем этом необходимо иметь хотя бы небольшой технический талант, чтобы самому затаскивать чисто технически сложные задачи, тогда вашему желанию сподвигать смогут довериться. Это важно.
Итого мой первый «подход к управлению» я бы назвал «айда за мной». В этот момент ты как правило набирающий интеллектуальную силу молодой разработчик в стае себе подобных. Управление строится на твоем личном примере и инициативности.
В пример можно привести историю редизайна фронтенда внутренней crm силами команды бэкенда в одном банке с jsp на еще не выбранную в тот момент технологию. В команде уже были руководители: архитектор и менеджер. Я в тот момент плохо ладил с js, считал это своей слабой стороной и ровно по этой же причине вызвался сделать mvp на нескольких популярных тогда frontend фреймворках, представить плюсы и минусы каждого и презентовать их команде. В итоге я стал по этому проекту неформальным лидером и обучал остальных бэкендеров как писать на js. Обучение js от бэкендера бэкендерам звучит иронично, но в функциональные и нефункциональные требования мы выполнили, поэтому «высота» засчитана.
Стиль #2
Стили управления командой неразрывно связаны с личными стадиями развития себя как технического специалиста: junior -> middle ->senior -> tech/team/arch lead.
Когда ты уже опытный, признанный специалист, написал условную половину проекта и уже формально значишься как руководитель, то и стиль управления меняется.
Приходится не только брать штурмом технологические вершины, но и совершать много нужной рутины, обрядов, распределять повинности, поощрять, вести разъяснительные беседы, проводить найм(это огромная тема о личном опыте которой еще расскажу) и тд и тп
В этой реальности я перешел в режим медиатора, хранителя равновесия и стандартов.
Стиль #3
Стиль управления конечно зависит от твоей жизненной философии и склада характера. Мне изначально не нравился микро-менеджмент, излишняя опека ко мне самому и от меня к другим. Мои фибры души протестовали, но в какой то момент пришлось освоить и этот инструмент, как когда то освоил например js. Как бы к нему не относиться (к микро-менеджменту, а не js ;-) ), но такой режим может быть полезен в минуты особой напряженности или важности происходящего и им надо владеть и конечно знать когда остановиться.
Стиль #4: Комбо
Завершу описание моих личных стилей последним. Он есть сочетание всех трех выше описанных, это умение применять их для команд в разной стадии развития, команд разного состава и разных временных стадий развития продукта.
Заключение
Владение каждым инструментом и что самое главное знание границ его применимости очень важно. Как говорится, чтобы применять мат методы надо знать их ограничения.
Комментарии (3)

rootkie
05.11.2025 23:41Поздравляю, вы состарились. )

rurikovich Автор
05.11.2025 23:41Спасибо, тоже иногда подкатывало такое ощущение )) как минимум повзрослел))
Dharmendra
Давно было нужно открыть платный клуб психоанализа анонимных управленцев, они будут сидеть на табуретках кругом и делиться друг с другом своими переживаниями. Пахнет стартапом!