Три года в Bereke Bank: всё ещё учусь быть менеджером

Сегодня, 25 сентября 2026 года, три года, как я работаю в Bereke Bank

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

На второй год я почему-то ничего не написал. Наверное, потому что тогда всё как-то выравнивалось: и мои ожидания от роли, и ожидания от меня.

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

Если первый год для меня был про то, как перестать всё делать самому, то третий оказался скорее про то, как вообще перестать мыслить отдельными задачами.

Чем дальше, тем меньше результата можно потрогать руками

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

Есть задача → ты написал код → код поехал к пользователям

Когда управляешь одной командой, эта связь становится длиннее, но всё ещё хорошо прослеживается. В конце концов ты руководитель команды.

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

В какой-то момент становится физически невозможно находиться внутри всего.

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

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

Это звучит довольно очевидно, но мне понадобилось время, чтобы это принять.

AI оказался очень похожей историей

Наверное, самый большой сюжет моего последнего года в Bereke — AI.

Начиналось всё достаточно просто.

Как дать разработчикам хорошие AI-инструменты? Что использовать для разработки? Какие внутренние данные можно подключить? Какие сценарии можно автоматизировать?

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

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

Поэтому разговор постепенно переехал из «AI для разработчиков» в AI внутри всего PDLC.

А потом ещё на уровень выше — к разговору про трансформацию IT в целом.

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

PoC — это ещё не изменение

При этом за последний год я стал гораздо осторожнее относиться к слову «внедрили».

Сейчас сделать PoC/MVP относительно легко (почти бесплатно).

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

Но между работающим PoC и реальным изменением способа работы огромная пропасть.

И иногда нужно просто признать, что идея не работает так, как мы ожидали.

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

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

Люди всё ещё важнее процессов

При всём этом я не думаю, что менеджмент в итоге сводится к проектированию красивых систем.

Можно нарисовать идеальную оргструктуру, RACI и процесс принятия решений, и ничего не заработает.

Потому что в центре всё равно остаются люди.

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

Давать людям совершать свои ошибки.

И главное — перестать быть обязательной частью каждого важного решения.

Наверное, это одна из самых сложных вещей при переходе из инженерной роли.

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

Я всё ещё учусь быть менеджером

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

Планировать действительно приходится намного больше.

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

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

И ещё достаточно долго продолжать двигать изменение, когда первоначальный энтузиазм уже закончился.

Если попытаться собрать мои текущие выводы совсем коротко, получится примерно так:

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

Через три года я точно намного лучше понимаю свою работу, чем в начале, но ощущения «теперь я наконец понял менеджмент на 100%» так и не появилось.

Скорее наоборот, просто вопросы стали больше.