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

Как обычно, возьмем двух чуваков.

Первый вырос из разработки. Десять лет пахал простым работягой программистом. Потом ушел менеджерить (верхнеуровнево) какой-нибудь продукт. И теперь отвечает там за деньги. Он вам расскажет и за деплой, и за архитектуру, за производительность и за че-нибудь еще глубокотехническое.

Второй вырос из менеджера. Сначала был проджектом и двигал тикеты в джире (или любом другом такс-трекере), потом стал руководителем таких проджектов, а потом пошел менеджерить тот же продукт и тоже отвечать там за деньги. Он вам может рассказать за управление ресурсами, правильную приоритизацию задачек, скрам, канбан и еще дофига всего.

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

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

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

Если менеджер полезет в около-разработку и скажет что-то типа:

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

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

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

В обоих этих примерах чувак будет забирать не свою зону ответственности на себя. А значит, свою зону ответственности он слегка проебет. И бэкграунд будет не во благо, а во вред всему продукту.

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

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