Привет, Хабр! Меня зовут Антон, я руковожу направлением автоматизации тестирования BIOS/BMC в YADRO. Как-то раз я моргнул — и наша команда из 10 инженеров выросла до 35. Вместе с этим у нас появились направления и лиды, а значит, я больше не могу прийти в любую задачу и сам ее быстро закрыть.

Общий дейлик тоже изменился: большая часть информации стала полезна конкретным группам людей внутри команды, а остальные просто теряли фокус. Конечно, ломалось не только это. В статье расскажу, что стало для меня неожиданным, где я ошибался и как мне удалось во всем этом выжить. А в конце поделюсь выводами, как при масштабировании команды избежать мучительной боли. Погнали!

Контроль, которого нет

Через нашу команду проходят почти все продукты компании: от серверов и СХД до моноблоков и планшетов. Мы разрабатываем и поддерживаем автоматизацию для разных платформ, поколений железа и версий BIOS/BMC. Чем больше таких платформ, тем быстрее растет команда — и тем меньше остается иллюзий, что один человек сможет удерживать в голове весь контекст происходящего. Единственный выход — делегировать ответственность. Об этом говорят все, но редко кто честно рассказывает, что начинается потом.

Пока в твоей команде 7–8 человек, процессы действительно выглядят управляемыми. Но где-то на 11-м появляется легкая паника: энтропия растет быстрее, чем успеваешь ее гасить, а ощущение порядка утекает сквозь пальцы. В какой-то момент ловишь себя на мысли: «Кажется, я вообще мало что контролирую».

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

В YADRO открыты вакансии:

— руководитель группы разработки,

— руководитель отдела разработки на Go,

— Agile Team Leader.

Прямое управление — не вариант

Когда поручаешь сотрудникам задачи, ты все еще участник процесса, своего рода контролирующий пилот. Но если ты отдаешь ответственность — формулируешь цель и границы, а способ, план и решения оставляешь за сотрудником — тебя в самолет уже не берут. Это абсолютно другой уровень доверия. Передав ответственность сотрудниками, ты подписываешь негласное соглашение о невмешательстве: «Теперь это твоя зона. Я не лезу. Максимум спрошу, на каком мы сейчас этапе и нужна ли помощь».

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

В какой-то момент я заметил, что играю в спасателя неудачно: прихожу с вопросами, предлагаю решения, прошу что-то ускорить. Потом выясняется: я предлагаю то, что уже попробовали и отклонили. А может, я не учел новые ограничения или просто сломал существующие договоренности, о которых мне закономерно не сообщали. В итоге вся моя якобы помощь для команды была дополнительным фактором хаоса. Прямой контроль без владения контекстом — жалкое зрелище. Я пробовал, не повторяйте.

Что с этим делать? Принять, что теперь твоя роль — не решать задачи, а обеспечивать условия, в которых их могут решать другие. Задавать правильные вопросы, вовремя убирать помехи и не пытаться вернуться в роль «главного решателя» при любом удобном случае.

Требования к процессам растут

10 человек могут худо-бедно договориться, как вести коммиты и какие изменения стоит «семь раз отмерить — один раз отрезать». Все находятся более-менее в одном инфополе и понимают, что происходит у соседей. Но на масштабе 30 человек даже самая конкретная договоренность продержится до первого пожара на одном из направлений. Ни у кого больше нет полной картины происходящего, а значит, нужны не договоренности, а процессы.

Внезапно в попытке выстроить процессы ты превращаешься сразу в нескольких специалистов:

• конфлюенс-программиста, который пытается задокументировать весь мир вокруг;

• девопса поневоле, отважно собирающего пайплайны, чтобы команда вообще могла двигаться вперед;

• горе-бизнес-аналитика, старающегося сопоставлять ожидания разных направлений;

• психолога, ведь нужно сделать так, чтобы все это работало без кровопролития.

Как по мне, чтобы сохранять управляемость, стоит держать в голове одну простую мысль: 

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

Например:

• вместо ручных договоренностей — автоматические проверки в репозиториях и пайплайнах; 

• вместо устных «не забывайте» — понятные правила, зашитые в инструменты; 

• вместо персональных точек контроля — механизмы, которые одинаково работают для всех. 

Еще важно помнить, что к большой команде все чаще обращаются люди извне — за статусами, решениями и контекстом. А значит, нужны процессы не только для того, чтобы хорошо работать самим, но и чтобы прозрачно рассказывать о своей работе наружу. В ход идут Jira-дашборды, метрики, пулы задач, понятные статусы и сигналы состояния — но не для тотального контроля, а чтобы руководитель или смежная команда могли быстро найти ответ на свой вопрос, не спускаясь по цепочке до конкретного инженера и не отвлекая его от работы.

Мы пока далеки от идеала, но именно в эту сторону сейчас и движемся.

Личная ответственность размывается

«Без Васиной галки мержа в мастер быть не может, это всем понятно», — отличный принцип, когда команда маленькая. После масштабирования он перестает работать. Завязывать задачи на одного человека в большой команде — значит получить почти не работающий процесс. 

Окей, логичный шаг: давайте дадим эту привилегию еще Пете и Коле. Больше ответственных — меньше задержек. Но на практике это работает не так. У вас получается процесс, за который лично не отвечает никто. Из «почти не работающего» он превращается в «вообще не работающий».

За процесс должен отвечать не человек, а другой процесс или механизм. Люди в этой схеме играют только поддерживающую роль. То есть если по процессу A для мержа нужно X апрувов от Y списка людей, проверять это должен не Вася вручную, а механизм B, которому все равно, горит у кого-то дедлайн или нет. Например, автоматизированные Code Owners или другая автоматизированная политика в репозитории.

Роль сотрудников в этой системе сильно смещается. Их задачи:

• обновлять правила;

• актуализировать списки;

• поддерживать механизм в рабочем состоянии;

• решать редкие исключения, когда автоматика не справляется.

Получается, люди — это уже не точка отказа. Процесс не останавливается, если кто-то ушел в отпуск, не успел вовремя отреагировать или просто решил, что сделает кто-то другой. 

Когда процесс держится на человеке — это ответственность. Когда только на человеке — это проблема.

И раз уж мы уже затронули эту тему, давайте продолжим говорить о самом сложном — о людях.

Работа с сильными инженерами — и их характерами

Когда команда растет, разница в характере, амбициях и рабочих привычках начинает ощущаться сильнее, чем любые технические проблемы. Если в маленькой группе «притирки» — это заметные, но управляемые 10–15 % времени руководителя, то в большой они становятся постоянным фоновым шумом. И самое неприятное — это работа с конфликтами, ожиданиями и коммуникацией, которую почти невозможно делегировать. Окей, возможно, но далеко не сразу.

У кого-то амбиции растут быстрее, чем компетенции. Кто-то переоценивает готовность коллег к самостоятельности, ответственности или изменениям. Кто-то уверен, что «правильно» — это так, как ему привычно, и он готов спорить до упора. Кто-то труден в общении, но при этом жутко эффективен технически.

То, что я описал выше, — абсолютно нормальная часть масштабирования. Но на уровне 30 человек здесь уже не помогут «поговорить по душам» или «вмешаться лично». Работает только системный подход: понятные правила, прозрачные ожидания, четкие зоны ответственности и зрелые процессы. А это никогда не появляется вовремя. Обычно оно нужно еще вчера, а строить приходится на бегу.

Помимо личных «притирок», которые, скорее, носят локальный и непостоянный характер, есть рабочие моменты, когда два и более человек просто не могут прийти к единому мнению. В этот момент процесс встает, а автоматика бессильна. 

Естественно, чем больше элементов в системе, тем больше риск, что где-то «закоротит». Пробовали когда-нибудь принять решение, которое будет приемлемым для коллектива размером с полный туристический автобус?

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

Поиск баланса между свободой и контролем

Как бы в требованиях к вакансиям ни расписывали «желание достигать» и прочие эпические качества, все люди разные. От «хочу, сдирая колени, покорять Олимп» до «дайте понятные алгоритмы и осязаемые критерии» — целый градиент. Но вот нюанс, все эти люди должны работать в одной системе. 

Если масштаб небольшой, это решается личным контролем. Ты знаешь, кто и как работает, с кем-то достаточно раз в неделю созвониться, а кому-то нужен понятный план и регулярные чекпоинты, иначе он просто теряется. Но с ростом команды этот подход перестает масштабироваться и начинается цирк с балансировкой. Тебе нужно учитывать множество факторов: темп работы, уровень самостоятельности, отношение к рискам, потребность в обратной связи, готовность брать на себя зону ответственности и вести ее от и до. Помню, как-то в пределах рабочего дня один инженер из моей команды говорил мне, что ему не хватает свободы, а другой — что ему не хватает четких правил. 

Вывод такой. Для эффективной работы нужны:

• понятные процедуры роста;

• возможность брать ответственность и инициативу — и, что важнее, механизм, как именно это происходит, ведь инженеры бывают стеснительными;

• регламентирование процессов и осязаемая картина будущего. 

Давайте честно: пока я не представляю, как стабильно и без перебоев совмещать эти пункты. Но мы стараемся к этому приблизиться — через прозрачные ожидания, разные уровни ответственности, понятные правила роста и регулярную обратную связь. Задача — не загонять людей в рамки, а аккуратно настраивать систему так, чтобы в ней могли работать самые разные люди.

Когда «все пропало»

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

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

Давайте пример. Тебе кажется, что в команде все идет по плану, день тянется к вечеру, а в районе пяти часов тебе звонит координатор тестирования и говорит, что есть срочный вопрос, который нужно было решить еще утром. С тех пор команда уже успела несколько раз упереться в ограничения, инженеры продолжают «инженерить», сроки горят — и ни у кого нет целостного понимания, что вообще происходит и чего ждать. Обсуждения были, попытки починить — тоже, но для тебя как руководителя все это время ситуация оставалась ниже радара. Ты появляешься в момент, когда времени на спокойное решение больше нет. И полного контекста происходящего у тебя при этом нет тоже.

Хорошо прописанные процессы, четкая структура и адекватное распределение зон ответственности сглаживают этот эффект, но все же не избавляют от него совсем. Я бы даже сказал, что чем лучше отлажена система, тем более внезапными и сюрреалистичными будут проблемы. Ну а теперь к мякотке.

Какие главные ошибки я допустил

А вот из-за каких действий мне было максимально больно:

Я держал ручное управление почти до комы. Пытался быть в курсе всего и сразу, пока в голове не образовалось пюре из случайных фактов. И я сейчас не про микроменеджмент, а про неутомимое желание знать все мельчайшие нюансы всего, за что отвечает моя команда. Нужно было смириться с тем, что я не обязан знать все. Мне достаточно понимать, где узкие места, какие есть риски и кто за что отвечает. Остальное — зона ответственности моей команды.

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

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

Наивно рассчитывал, что коллективная ответственность как-то заработает. Пока однажды не увидел очередь Pull Request, которая могла тянуться от двери до репозитория. Нужно было сразу принять, что коллективная ответственность без четких механизмов — это ее отсутствие. У важной задачи должен быть понятный владелец или автоматический контроль.

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

Что помогло выжить

Когда стало ясно, что старые подходы разваливаются, пришлось что-то менять. В этот момент на сцену вышли три правила жизни:

Ладно, шучу, не эти. Мне помогли:

Сильная команда. Со мной работают люди, которые не боятся давать честный фидбэк, спорить, предлагать варианты и говорить, когда что-то идет не так. Это огромная ценность. Помню, однажды ребята сами обратили мое внимание на то, что я продолжаю пытаться держать в голове слишком много контекста и вмешиваюсь в задачи, у которых уже есть владелец. Не всегда такой фидбек слышать приятно, но именно он помог вовремя остановиться и начать по-настоящему отпускать задачи.

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

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

В разговоре с одним коллегой я услышал простую мысль: 

«Если все важные решения и движения завязаны на тебе, значит, ты не усиливаешь систему, а становишься ее узким местом».

Это задело мое инженерное эго. Но именно тогда я окончательно понял, что теперь мне нужно не инженерить руками, а выстраивать процессы.

Делаем выводы

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

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

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

Чтобы удержаться на плаву:

• доверяйте своим инженерам;

• опирайтесь на процессы, а не на людей как на точки отказа;

• будьте готовы меняться и менять все вокруг;

• прислушивайтесь к людям и не игнорируйте их мысли, даже если ваше эго против.

На этом у меня все. Теперь приглашаю руководителей осудить обсудить мои выводы: что вам близко, а что нет, как это было у вас? Инженеров спрошу отдельно: насколько ваше представление о роли руководителя совпадает или расходится с тем, что я описал? И спасибо за внимание!