Indeed. And this is a well understood concept. To the point that Tom DeMarco wrote an entire book about the importance of "slack" - over 20 years ago.[1]
From the description:
[1]: https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...
Let me be clear: I later realized that this project would have been a soul-draining death march at many other places I'd worked in my career. Exhausted just a few weeks in, with management hounding the team for schedule estimates that can't possibly exist because management failed to fund maintenance for years.[2] (There were actually rational reasons for this, in this case. tl;dr the project got renewed interest and investment due to a new business case.)
To those who lament on this topic about "devs (in country X) just aren't motivated these days" or whatever, let me suggest something. If you have poor clarity of purpose, poor giving-a-fsck about humans, or a number of other culture failings then yes, you may encounter problems. Your solution is still not to tie your knowledge workers to their desks. You need to fix the root causes of your underlying productivity debt, not pave over them with an overwork-butts-in-seats mentality which just makes things worse in the long run (<--- read DeMarco).
[1]: https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...
[2]: Pro tip: "evergreen" ecosystems, especially young and rapidly changing ones like early-mid Ruby/Rails and a lot of current npm/JS-based stuff, often have a wickedly non-linear cost curve if/when maintenance and dependency updates fall off. Some of the most expensive I've encountered of this ilk is when /test infrastructure/ incurred a lot of past churn that wasn't tracked, but suddenly (cough) needs to be updated.
https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...
https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...
If you've read and liked Peopleware, you should read Slack as well. If you haven't read either one then you should.
At the top of the list is "Managing Humans: Biting and Humorous Tales of a Software Engineering Manager" by Michael Lopp[1], which was recommended to me by a manager who helped me get my start in engineering management. This book touches on a lot of the nuances in dealing with people and, as an introvert, I found this really helpful. The same author blogs under "Rands in Repose[2]" which has much of the content from the aforementioned book available for free.
While in the people category you'll also get a lot of recommendations for "Drive!" by Daniel Pink[2], which is a book about intrinsic motivators (autonomy, mastery, purpose) and how they are more important and effective than extrinsic motivators (e.g. money), particularly for knowledge workers. My personal advice, however, is to watch his TED talk[3] which is a great summary of basically the entire book. In this same category I could also recommend "The Great Jackass Fallacy" by Harry Levinson[5].
Now on the wall between people management and engineering/project management is "Slack" by Tom DeMarco[6], which is about how organizations and managers tend to run their staff at 100% capacity. As the book points out, however, this is a good way to not only burn people out, but it also sends response times through the roof (from queuing theory), and stifles change ("too busy to improve"). You can read this one on a plane. For some shameless self promotion, I've also written a tiny blog post relating Slack and the need for upkeep (software operations and maintenance)[7].
Next, fully in engineering/project management, I have to recommend "Waltzing with Bears" by Tom DeMarco and Anthony Lister[8], which is specifically about managing risk on software projects. The authors highlight the common practice of project/engineering managers communicating their "nano date", which they point out is typically the lowest point on the uncertainty curve. In other words, the project has the lowest possible chance of shipping by this date when you look at the possible timeline as a probability distribution. This book changed the way I talk about projects and the way I manage my team's various risks and I have been more successful as a result.
One final recommendation I'll make, since you're in the midst of a transition, is "The First 90 Days" by Michael Watkins[9]. It's a wonderful book that outlines how and why one should develop a transition plan in order to hit the ground running - and in the right direction. For my last engineering management opportunity, developing a preliminary 90 day plan as part of a "starter project," was a major factor in being given the job.
I believe that a subset of these will give you a great start. After that, you should read on the areas you feel the need for the most amount of help with or the areas that interest you. If you are avidly interested in project management, for example, you should read books on various methodologies, particularly the one that you or your organization practice.
[1]: http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...
[2]: http://randsinrepose.com/
[3]: http://www.amazon.com/Drive-Surprising-Truth-About-Motivates...
[4]: http://www.ted.com/talks/dan_pink_on_motivation?language=en
[5]: http://www.amazon.com/Great-Jackass-Fallacy-Harry-Levinson/d...
[6]: http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...
[7]: http://www.charleshooper.net/blog/on-slack-and-upkeep/
[8]: http://www.amazon.com/Waltzing-Bears-Managing-Software-Proje...
[9]: http://www.amazon.com/The-First-90-Days-Strategies/dp/159139...
Slack, by Tom DeMarco https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...