В этом году исполнилось 25 лет, как я ковыряюсь в ИТ, из них лет 15 я занимаю позиции уровня +- СТО. Когда я был юным техдиром, хватание за все подряд и вписывание себя во все задачи не казалось какой-то проблемой, энергии хватало на все. Потом я подрос, и с некоторым удивлением обнаружил, что вписывание себя в задачи стало более осознанным, но "за все подряд" осталось, просто слегка видоизменилось. Периодически на просторах интернетов появляются дискуссии - должен ли тимлид программировать или технический директор разбираться в бизнесе, результатом всегда плотный срач без победителей. Де-факто, короткого и однозначного ответа на то, кто такой СТО нет. Более того, спросите пять разных CEO и получите пять разных ответов. Для одного это техлид, который «разберётся с серверами и вот этим непонятным софтом для бухгалтерии за кучу денег». Для другого - правая рука, способная закрыть все технические вопросы для него и всей лавки. Для третьего - «тот парень из ИТ», который должен сделать быстро, дёшево и вчера, но делает долго, дорого и вообще не вчера:). Стандарта просто нет.

Итогом СТО - это конкретная не роль. Это конструктор, который бизнес собирает под себя, особо не задумываясь о нюансах. Техлид и всякоразноопс. Менеджер проекта. Менеджер продукта. Нанимающий менеджер. Ментор. HR. Спикер и лицо компании на конференциях. А еще иногда шкаф может подвинуть или дверь починить в раздевалке. Куча профессий в одном человеке, и ни от одной по-хорошему не откажешься. Уберёшь найм - получишь так себе команду. Забьёшь на менторство - потеряешь ключевых людей через полгода. Выкинешь продуктовое мышление, и вот ты уже пилишь какие-то очень нужные никому фичи.

В итоге под воздействием бизнеса получается оч часто не СТО, а тимлид тимлидов, который лично лезет во всё, потому что «ну а кто, если не я». И лезут паровозиком проблемы. Вкладываться особо не хотят, хотят фичи и выполненные планы, и меняться тоже не очень хочется. Почему-то нет места ни техническому долгу, ни архитектуре, ни тому, что производительность зависит от системы, а не от героизма одного человека. Максимизация локальных показателей почти всегда портит систему в целом, но попробуй объясни это шэфу, у которого горит квартальный план.

Кто виноват и что делать? Корень большинства проблем СТО - это узкий фокус на технине, незнании возможностей своих людей и незнании устройства бизнеса. В довесок обычно идут излишняя конформность, страх брать сильных игроков и неумение делегировать. Последнее напрямую связано с тем - ты оркестр или дирижер.

И немного про ИИ, потому что ща все про него. Он все еще не заменил СТО, но сдвинул все плиты. Идёт жёсткий дрейф от "сделать" к "поставить задачу" и "проконтролировать результат". Нейросети забирают рутину и быстро пишут код (ага), а вот все остальное становится я бы даже сказал сложнее, чем было до этого. Плюс уходит любимый блокер "нам на это не хватит сил". Сил теперь как бы больше. Осталось обуздать:) А для этого нужен реально широкий инженерный и продуктовый кругозор, ибо сложно контролировать еще больше различных результатов без него. Кто не учится и не расширяет кругозор во все стороны, тот рискует стать узким горлышком собственной компании.

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

Про вышесказанное с примерами и ответами на вопросы голосом я расскажу на "Менеджмент 360" - бесплатном курсе-интенсиве от Стратоплана про четыре управленческие позиции в IT. Каждый день с 1 по 4 сентября отдельный трек для таких позиций: тимлид, руководитель отдела, СТО (я тут) и СОО. Обо всём этом — подробнее, с примерами и живыми вопросами в чат говорю на лекции "СТО - человека-оркестр" 3.09 в 19 по Москве. Регистрация тут. Бесплатно за подписку на каналы спикеров. На меня вы уже и так подписаны:)