Throws out a new perspective on what motivates people.
I haven't read it, but at least for me it seems like common sense that these 3 things have positive effect on motivation.
If you have autonomy over how you complete your tasks for example, you will do it in, according to you, most efficient way, and that will make you feel satisfied. Mastery is from the same desire to be as efficient as you can. Purpose is something different, but you can clearly imagine how much more willing to do your best you are when you know that the thing you do will be seen and used by other people and how it will make people's life easier, for a primitive and simple example.
Compare it to my job - software is bloated, something I myself would never use, our customers are actually forced to used, almost nobody, except the people who earn money from it at the management, likes it, and often you find out that some bug that existed for a year and that completely disabled some functionality was never noticed because no one, not even testers bothered to check those parts of the system. Combine that with heavy restrictions on what can be done, both by time restraints on tasks and by accumulated technical debt that makes any improvements economically not viable, and add the natural tendency of such systems to resist to anything new and you get individuals with gradual decline in motivation over time.
I understand why there's such an ageism "problem" in the industry - the only way to make these companies with these systems afloat is to hire only young people who aren't worn out from these things yet to keep it alive. From my experience, I don't know how it was a couple of decades ago, but it seems like younger and younger people are getting their motivation destroyed by such environments.
You don't often see occupations where people are already sick of their job in general by late twenties to the point of considering switching profession that would pay considerably less.
At the top of the list is "Managing Humans: Biting and Humorous Tales of a Software Engineering Manager" by Michael Lopp, 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" 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, 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 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.
Now on the wall between people management and engineering/project management is "Slack" by Tom DeMarco, 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).
Next, fully in engineering/project management, I have to recommend "Waltzing with Bears" by Tom DeMarco and Anthony Lister, 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. 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.
In any case, the book is worth a read. I had a copy forced on me years and didn't crack it open for ages - I wish I'd started reading it sooner.
Agile/XP practices are a good starting place in-between cowboy programming and micro-management hell -- as long as you don't take them as a recipe book. They're simply best practices that you can and should learn. Then prune/modify as necessary. There are really too many books to list separately. I'd advise joining a local Agile User's Group and noticing who has their shit in one sock. Then find out what they're doing. You can also bring in external coaches.
You need a couple of good books on the people part of things. I can guarantee you that the people part of things is where you'll screw up. "Drive" is really good. http://amzn.to/1qtZdEd So is PeopleWare http://amzn.to/1iBnasO
For strategic stuff, especially in a growing company, you're going to have to master large work queues without having them eat you alive. If you'll allow me to self-promote, my Backlogs series is geared exactly towards this problem. http://tiny-giant-books.com/backlogs.htm
One observation: as you grow, it's not enough that you pay extremely careful attention to whom you hire. You also need to create an on-boarding system where new hires can learn and adopt the culture -- things like pair programming, how the build works, good coding etiquette, and so on. Setting the table for strategy to work is actually more important than whatever the strategy is.
Second observation: I imagine you're going to be swimming in business book recommendations. Business books are like dieting books: everybody has a few favorites. (I imagine this is because the material inside matches how they already feel). Better to identify specific areas, like Agile Requirements Modeling, and find books targeting those areas. Then look for practical advice. Otherwise you'll just have a ton of books that you'll spend hundreds of hours reading and not really have much to show for it at the end of the process.
With over a decade of experience in my field, I can certainly relate but cannot offer any advice.
I'm currently reading the book below to understand more about this (it's a bit too verbose but it's a decent book I recommend).
The reward scheme is dubious though: I love working on open source because it's intrinsically rewarding. But if you try to pay me a few bucks, chances are I'll lose interest because my day job pays better.
Extrinsic motivation killing intrinsic motivation is a known phenomenon in psychology: http://en.wikipedia.org/wiki/Motivation_crowding_theory
It means that splashing money around to get people to do stuff can have the opposite effect.
Also see the book Drive by Daniel Pink: http://www.amazon.com/Drive-Surprising-Truth-About-Motivates...
 Also a book http://www.amazon.com/Drive-Surprising-Truth-About-Motivates...
Instead of paying employees the wages that supply and demand would have predicted, they gave their workers a little more. It wasn't because they were stupid. It was because they were savvy. Paying great people a little more than the market demands, Akerlof and Yellen found, could attract better talent, reduce turnover and boost productivity and morale.
Highly recommend reading Pink's book.
 - http://www.amazon.com/Drive-Surprising-Truth-About-Motivates...
One source showed that:
- For highly creative jobs, respect and autonomy to function and just enough $ to cover comfortable living expenses produced the best results.
- As you add more money, the performance for these jobs decreased.
- For highly repetitive jobs, performance increased with pay almost linearly.
- Offering more autonomy for lower pay in these types of jobs lowered performance.
Programming is a highly creative job. While you are making very logical assumptions (more $ == more work) I would argue that after the first month or so, that would no longer be the case.
You would then just be equating (more $ == more HOURS working) but not necessarily producing.
The findings of the study did hinge on the person seeking autonomy to make enough to cover their living expenses such that the concern for money was off the table.
Really interesting stuff.
I think from my own experience, after the honeymoon period of the giant paycheck wears off, this tends to be absolutely true.
As for passion, it has to come from the top down.
Thanks to yengz for the reminder where this study came from!
Drive: The Surprising Truth About What Motivates Us -- Dan Pink
Linchpin: Are You Indispensable? -- Seth Godin
The Laws of Simplicity -- John Maeda
Zen and the Art of Motorcycle Maintenance -- Robert M. Persig
Invisible Man -- Ralph Ellison
How to Win Friends and Influence People -- Dale Carnegie
The Kindle app has really got me buying a lot of books that I now need to finish...
Get dozens of book recommendations delivered straight to your inbox every Thursday.