Про признание среди инженеров

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

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

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

Что может помочь техническому менеджеру получить это признание?
На этот счет у меня несколько мыслей:
0. Поработать с кодом проекта своими руками
Написать какую-нибудь полезную мелкую утилиту, до которой не доходили руки у команды; написать какие-нибудь скрипты, которые автоматизируют работу с тем, что напрашивается; вникнуть в архитектуру проекта и поспрашивать ребят о неочевидных моментах - все эти элементы объединяет работа с кодом собственным руками. Да, копание в коде это не то, зачем обычно нанимают технических менеджеров, но когда инженеры увидят, что вы реально шарите на уровне кода - вы получите 10 очков инженерного увожения. "Talk is cheap show me the code" (c) Линус Торвальдс

1. Пообщаться с каждым участником команды 1-1
Во всех менеджерских книжках говорят, что если ты не кризис-менеджер, то в первое время не нужно ничего менять - просто слушай и набирайся контекста. Когда опытные инженеры сталкивается с проблемой, они первым делом собирают о ней информацию, чтобы поставить верный диагноз (неопытные, кстати, пробуют первое попавшееся решение и там уж как повезет). Так и тут - собери инфу о проблемах, о важных процессах внутри команды, о том как инженеры видят продукт. Ключевой момент - действительно слушать и вникнуть, искренне и от души, а не просто делать вид, чтобы выглядеть "хорошим менеджером".
Ну и, пожалуй, самое главное.

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

Как считаете, нужно это признание техническому менеджеру или и без него норм?