Короче говоря, work-life balance штука совсем не арифметическая и внутри структурно сложная. Хотите  драматически улучшить жизнь подчиненных -- найдите работу их жёнам. =)

Ой, а ссылка только у меня битая? :)

и немецкий VPN не лечит )

Оно хочет простой человеческой регистрации

Ой, нет) Не простой и не совсем человеческой

Ох, она какая-то хитрая, оказывается. Наверное, результат зависит от реферера. Через scolar у меня скачивается: https://scholar.google.ru/scholar?hl=ru&as_sdt=0%2C5&q=management+practices+work+life&oq=management+practices+work+li

Первый pdf

В чат телеграма можно загружать файлы

А количество детей как влияет?:) Не коррелирует ли занятость жены с данным фактором?

Коллеги, тут в кулуарах вот какой вопрос обсуждали, присоединяйтесь. Как по вашему, какова должна быть глубина технической компетенции менеджера IT-проекта по шкале от "ничего не знаю про ваши буквы, умею ставить таски в трекере и рисовать диаграмы Ганта" до "могу заменить любого разработчика или тестировщика на проекте"?

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

А мы говорим о PMе в матричной структуре или о руководителе проекта в древовидной иерархии?

Просто ответы от этого драматически зависят

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

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

Но это именно при условии, что качеством (и количеством) производимой разработчиками проекта работы занимается кто-то другой, кто обладает над ними властью, и на этого кого-то РМ может полностью положиться.

Бывают, правда, проекты, полноценно РМить которые без тех.экспертизы невозможно: инфраструктурные компоненты, библиотеки, тулзы разработки. Но это всё-таки отдельный мир.

IMHO это тогда не руковоитель проекта, а администратор-координатор. "Почему у вас поехал срок? — Ну, это мне тимлид разработки сказал".

А взвесить тех. долг против выигрыша срока? Без понимания существа и глубины долга?

Возможно, но я же безоценочно. Просто это full time job, и в организациях, где всё так устроено, этот job называется Project Manager. А так-то я вообще не фанат матричной структуры.