Как эффективный тимлид разработки становится бесполезным

Когда я пришел в Иннотех, на проект ВТБ, стрим назывался залоги. Состоял из 7 команд. Проблема была в том что рост функционала сопровождался ростом команд. И у ребят был монолит на фронте.    Они на собесе мне объяснили проблемы и вероятные пути решения. В процессе работы выяснилось что пути были не верными, немного сломанных копий, несколько десятков длинных созвонов, аргументация и вектор был сменен. Не обошлось без криков, пены у некоторых людей которые были буквально убеждены что я заблуждаюсь.    После смены курса, изменений в процессах и подходах. Выделения зон ответственности среди разработчиков, взаимозаменяемость стала нормой. Появилась мотивация делать хорошо у всех. Но со временем стало меньше потребности на фронте, а потом и бэкеде.    И вместо 7 команд стало нужно 3. И многие ребята которые настаивали на старом курсе, стали выглядеть бледно. Хотя цели их улечить не было. Большая часть ушла с проекта на новый, звали с собой, но это выглядело странно.    Вновь пришедшие руководители команд, обесценили работу. Мол оно и так работало, скорее всего. Ничего полезного ты не сделал. Оттуда иногда видя системных людей, говорю что они однажды станут бесполезными.    У Генри Форда наладчики конвейера получали зарплату только тогда когда конвейер работает, а наладчики отдыхают. Отсюда делаю вывод, быть бесполезным полезнее для владельца, но не для менеджмента.