Старый конь 🐎 борозды не испортит

Почему сильные сеньоры на управленческих позициях (тимлида, техлида, хеда профессии и т.д.) - не всегда благословение, а иногда и антипаттерн.

На заре своей юности когда у меня появился свой первый независимый бюджет и карт-бланш на найм новой команды я конечно же сразу начал смотреть самых матёрых бойцов, как следствие время поиска больше, себестоимость для организации выше, но как говорится долго запрягаешь, потом быстро едешь. Дальше все шло по разному, либо действительно организовывалась дримтим, и появлялся четкий механизм доставки ценности, либо что-то шло не так (задачи не выходили в срок, команда не отличались единым мнением и ссорились на грумингах, увеличивался отток и т.д.).

Если в начале все было хорошо, то в процессе становления продукта/системы неизбежно увеличивается ареал обитания и ответственности команды, и как следствие команде нужно масштабировать свои процессы и использовать более совершенные методики и инструменты. Здесь тоже не всегда шло гладко.

По прошествии времени, я понял что не только в разработке, но и в других сферах утверждение "Чем опытнее тем лучше" - это далеко не всегда догма, а даже иногда и антипаттерн.

Сеньоры часто приходят с боевым опытом, уверенные, что знают, как должно быть. Но поле управления — не IDE и не гит. Тут нет pull-request’ов, есть только переговоры, баланс интересов и “непойманные” приоритеты.

И вот что как правило происходит:

💣 Скорость вместо согласования. “Я сам всё быстрее сделаю” (классическая форма прокрастинации управленца) - и пошла дублирующая инициатива.

🧱 Опора на прошлый опыт. “В прошлом банке это работало” — но контекст другой.

🎯 Фокус на инструменте, а не на системе. Сеньор чинит конкретные горячие баги по Jira, когда нужно чинить процесс коммуникации.

Сильные сеньоры бесценны в продуктах и технологиях. Но если не дать им менеджерского “сдвига контекста” — они начнут управлять так, как раньше разрабатывали код.

🧠 Управление — это не апгрейд уровня, это смена профессии с соответствующим изменением парадигмы. И чем раньше это понять, тем меньше багов будет у вас в оргструктуре.