🌱 Как техлиду перестать быть справочником и научить своих аналитиков самостоятельности

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

История началась с ошеломляющего вопроса

Меня зовут Вероника Газизова, я работаю техническим лидером системных аналитиков в Альфа-Банке. Когда я пришла техлидом в новое для себя направление, мне важно было быстро погрузиться в контекст. Команды уже работали, процессы существовали, продукт развивался. А я входила в систему, где многое нужно было понять с нуля.

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

Через некоторое время я заметила странную вещь: вопросы стали проще. Не глубже и не системнее, а именно проще.

Переломным моментом стал разговор с сеньор-аналитиком, который больше года работал в банке.

— Мы что, можем смотреть продовые логи? И они нам доступны? А покажи, как найти какие-нибудь логи?

Это было неожиданно. Ведь вопрос не сложный архитектурный, а про один из базовых инструментов работы... В этот момент я поняла: дело не в знаниях.

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

И тогда я впервые подумала: возможно, дело не в компетенциях? Возможно, дело в том, как устроено наше взаимодействие?

Дело оказалось не в компетенциях

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

Когда лидер регулярно даёт готовые решения, команда привыкает к короткому циклу «вопрос — ответ». Формулировать собственную позицию становится необязательно. Искать глубже – невыгодно. Быстрее и проще спросить.

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

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

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

Я начала с себя

Не вводила жёсткие регламенты и не перестраивала процессы одномоментно, а начала с разговоров.

На 1-1 я всё чаще поднимала тему самостоятельности. Говорила о том, что именно умение разобраться и проанализировать делает нас профессионалами. Что аналитик — это не тот, кто аккуратно оформляет задачу, а тот, кто умеет исследовать, сопоставлять, видеть связи и формулировать гипотезы.

Иногда я прямо формулировала: «Ты — аналитик. Твоя сила не в том, чтобы задать правильный вопрос. Твоя сила в том, чтобы попробовать на него ответить».

Я стала мягко возвращать ответственность. Если ко мне приходили с вопросом, спрашивала: «Как ты сам это видишь?» или «Какие варианты ты уже рассмотрел?». Не для того чтобы проверить, а чтобы включить мышление.

Поначалу это вызывало паузы, но постепенно формат диалога начал меняться. Аналитики стали приходить не с вопросом «Как правильно?», а с формулировкой: «Я посмотрел логи, изучил документацию, вижу два варианта. У первого такие риски и преимущества, у второго – такие. Склоняюсь к первому варианту. Что думаешь?»

Это уже профессиональный разговор.

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

Самостоятельность как норма

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

Интересно, что изменения по-разному повлияли на команду.

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

Не всем оказалось комфортно в этих изменениях. И со временем состав команды частично обновился.

Для меня это был непростой этап. Но он показал, что культура это не только про правила, а про готовность принимать ответственность.

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

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

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

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

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

Но именно в этих микрорешениях и формируется культура команды.

Что сработало на практике?

За это время я сформулировала для себя несколько принципов, которые помогли изменить модель взаимодействия в команде.

1. Сначала позиция, потом обсуждение. Если аналитик приходит с вопросом, он формулирует своё решение или гипотезу. Даже если оно не идеально.

2. Разделять «не знает» и «не думал».

  • Если человек не знает — помогаем найти источник.
  • Если не думал – возвращаем вопрос и даём время.

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

4. Фиксировать правила, чтобы знания не жили в голове техлида. Повторяющиеся объяснения мы переводим в инструкции и договорённости.

5. Обсуждать рост через принятые решения. На 1-1 мы говорим не только о задачах, но и о том, где человек проявил самостоятельность и системное мышление, что ему было бы интересно изучать, и что нового он узнал.

Ни один из этих шагов не работает мгновенно. Но вместе они постепенно смещают фокус с «Быстро решить» на «Понять и принять решение».

Со временем я поняла: помощь — это тоже управленческий инструмент. И, как любой инструмент, он требует меры.

  1. Если использовать его слишком часто, команда начинает опираться не на собственное мышление, а на лидера.
  2. Если использовать осознанно — он становится точкой роста.

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

И, пожалуй, именно в этом переходе, от помощи к развитию — и начинается настоящая работа лидера.

💻 Библиотека программиста
Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

eFusion
29 сентября 2019

20 рабочих советов от Junior Front-end developer

В начале изучения важна каждая крупица знаний. Для статьи мы отобрали спис...