За что разработчик может уважать менеджера?
За то, что это — образ жизни.

Я попробую изложить тут свой опыт. Думаю, получится ОЧЕНЬ субъективно. Увы.

Последние три года мне приходится быть этаким Jack Of All Trades (к счастью, без продолжения “master of none“). Я начальник отдела автоматизации учебного процесса довольно большого, но весьма вялого до этой самой автоматизации ВУЗа. Жизнь сложилась так, что кроме этого я занимаюсь веб-разработкой (скорее фрилансом) и координацией нескольких полузакрытых проектов, выросших из аутсорса.

Соответственно, приходится заниматься административной работой, организационно-координационной и непосредственно разработческой. И рисовать, верстать, копирайтить, тестировать, составлять матмодели, заниматься статистической обработкой и немного паять.

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

До этого, примерно лет пять назад, когда я был чистым разработчиком, на работу менеджеров проекта/команды (да чего уж кривить душой — и на работу любого административного работника) смотрел с презрением, граничащим с этаким public riot. Скорее всего, мне просто не попадалось действительно хороших ПМов, которые бы умели поставить рабочий процесс так, чтобы разработчик понял, что о нём заботятся.

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

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

— Надо срочно сдать! Хватит тянуть резину, что у тебя там, почему нельзя сделать быстрее?

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

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

Потом было много разных событий, которые во мне окончательно убили веру в то, что менеджер — это друг, товарищ и практически брат. Эти люди не видели проблем коллектива, не хотели для достижения результата жертвовать своими ресурсами или вообще абстрагировались от проблем за мифическими скрамами, процессами, UML и прочей серебряной атрибутикой современного IT.

А потом я стал начальником.

Начальником болота, где не слышали про VCS, например. Вообще. И про проектирование.

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

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

С тех пор многое поменялось в голове: я научился жертвовать перфекционизмом в пользу выполнения поставленной задачи; научился делегировать работу; научился избавлять разработчиков от головной боли и смятений в выборе способа решения задач, выполняя роль своеобразной бритвы Оккама; научился… да научился много чему.

Теперь я понимаю, что основная работа менеджера — это, в первую очередь, аргументированное и действенное избавление разработчика (исполнителя, подрядчика и т.д.) от психологической «головной боли», которая вызывается тем, что тот выполняет несвойственную ему работу. Собственно, за это разработчик и может уважать менеджера, как человека, профессионально выполняющего свою работу.

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

Слава святому фон Нейману, такие люди, оказывается, есть и их достаточно много. В сравнении себя со многими из них я понимаю, что мне есть, куда стремиться. И это потихоньку топит лёд моего внутреннего разработчика, который потихоньку учится уважать менеджеров.
ок, это действительно важно. 
тут попалась статейка намедни — java.dzone.com/articles/fix-code-immediately

однако лояльность у менеджера, по рабочим вопросам, — отдельная тема.