Чем больше метрик, тем меньше контроля

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

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

"После этого я написал руководителю большой отчёт, где описал, что происходит, и перечислил проблемы. Реакция была странной. Мне сказали, что я всё равно должен как-то повлиять на ситуацию и ещё немного поработать с процессом." - ничего странного, ты фактически попросил руководителя, чтобы он поделился с тобой властью, чтобы ты имел возможность влиять на ситуацию. Кто ж на такое согласится? Начнешь копать глубже, и вдруг выяснится, что этот руководитель и есть то самое слабое звено, и его уволят. А так - все проблемы он списал на тебя, и сидит на своем месте дальше, ЗП и бонусы получает...

Когда мера становится целью, она перестает быть хорошей мерой

Закон Гудхарта

Я отчасти соглашусь с выводами. Но вам не кажется, что все же основная проблема - руководство? Вам дают задачи, но не дают полномочий. Вы приносите результат, но его игнорируют. Руководство нанимает специалиста в нужной сфере, но потом его же не слушает - это же максимально глупо. Скорей всего, будь руководство разумней и адекватней, давно могло разобраться в проблемах и исправить процессы. Ну или это была имитация деятельности, и всех всё устраивало.

Я в разработке много раз видел, когда принимаются странные решения, когда ты приносишь обоснованную критику процессов, а ее игнорируют, когда предлагаешь задачи, а они никому, начиная с тимлидов и выше, не нужны. А потом сидим с костылями, тратим заметную часть времени не на разработку задач, страдаем от плохого мониторинга, задачи делаются медленней, люди выгорают. Но никто из руководства ничего (или почти ничего) не делает. А ты, как обычный разработчик, никак не можешь ни на что повлиять, кроме как очередной раз донести информацию о проблеме, потому что у тебя ни полномочий, ни свободного времени. Зато метрики красивые! Потому что твой тимлид в основном на них и работает.

Статья интересная, спасибо.
Но много спорного или моментов, где причины не до конца исследованы.

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

У менеджера среднего звена вообще мало возможностей влиять на такие решения. 

Это не совсем так. Зависит от культуры организации и от самого менеджера. При слабой культуре (в частности, не прислушивается к сотрудникам) сложнее, при сильной - легче. Аналогично с силой и опытом менеджера.

"Я сразу обозначил риски, но решение уже приняли ещё до меня и компания собиралась так работать независимо от моих возражений. "

И

Ответственность должна совпадать с полномочиями.

Это "база" (про ответственность и полномочия). Надо было сразу начинать искать работу, как только проигнорировали риски автора - не надо соглашаться руководить, не имея полномочий. Результат был предсказуем - и всё равно работу искать пришлось, но в худшей ситуации.

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

Не обязательно нужны первичные данные. Если метрика продумана верно, а расчёт её автоматизирован (т.е. фальсификация невозможна), то первичные данные нужны лишь для детального анализа причин в отдельных случаях. А вот правила про автоматизацию и систему управления проектами я у автора не вижу:-)

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

Не очень понятен смысл фразы "саботировать данные". Если речь про их искажение, то искажать будут и в случае, если будут знать "зачем". Даже ещё и активнее.
Правила фиксировать нужно, чтобы все на одном языке говорили и чтобы прозрачность была в команде и доверие было.
А чтобы данные не искажали нужны другие методы (автоматизация внесения; внесение теми, кто не зависит от результатов и т.д.).