The design and UX isn't done, Rob and Abbie, okkurrrr! 😌
malaprop's review
3.0
I'm mixed on this book.
On the plus side, it was a comprehensive book on management. It isn't a leadership book or a guide on how to work up to the next level. This book is exactly what it claims to be: a guide on how to manage software teams. It goes into every facet of management including hiring, managing day-to-day, 1:1's, motivation, project management, etc. What is nice about this book is that it is geared towards software professionals so it deals with problems specific to that domain. If you are new to management and don't know what all is involved, this book will be a good springboard.
On the negative side, I found Mickey and Ron to give advice that at times felt dated. Most of their experience harkens back to the way large companies in the late '90s and early '00s were run in the Valley. I also found their ego to sometimes get in the way of the material. Early in the book they have a section where they describe different types of developers. They were strongly biased that the "best" developers are Systems Developers, and then they expound upon how that is what they were. Or that only the best developers are great at playing musical instruments too and that those who don't play musical instruments are probably not going to be among your best. These kinds of biases and comments are frequent through the book which I found a bit cringe-worthy. For instance, one of the techniques they encouraged to gain credibility with a team is to have your business cards framed on your desk so those walking in can see the supposed high-profile places you've worked. I had to muster up a bit of resolve to keep reading after that point.
But if you can wade through the biases and occasional ego hits, most of the book is practical and useful for getting the job done.
If you really want to grow in your leadership, I recommend books such as "High Output Management", "The Manager's Path", "The Coaching Habit", and "Act Like a Leader, Think Like a Leader". If you read a handful of these books, I think it will put you in a good frame of mind for not only managing teams but being an effective leader.
On the plus side, it was a comprehensive book on management. It isn't a leadership book or a guide on how to work up to the next level. This book is exactly what it claims to be: a guide on how to manage software teams. It goes into every facet of management including hiring, managing day-to-day, 1:1's, motivation, project management, etc. What is nice about this book is that it is geared towards software professionals so it deals with problems specific to that domain. If you are new to management and don't know what all is involved, this book will be a good springboard.
On the negative side, I found Mickey and Ron to give advice that at times felt dated. Most of their experience harkens back to the way large companies in the late '90s and early '00s were run in the Valley. I also found their ego to sometimes get in the way of the material. Early in the book they have a section where they describe different types of developers. They were strongly biased that the "best" developers are Systems Developers, and then they expound upon how that is what they were. Or that only the best developers are great at playing musical instruments too and that those who don't play musical instruments are probably not going to be among your best. These kinds of biases and comments are frequent through the book which I found a bit cringe-worthy. For instance, one of the techniques they encouraged to gain credibility with a team is to have your business cards framed on your desk so those walking in can see the supposed high-profile places you've worked. I had to muster up a bit of resolve to keep reading after that point.
But if you can wade through the biases and occasional ego hits, most of the book is practical and useful for getting the job done.
If you really want to grow in your leadership, I recommend books such as "High Output Management", "The Manager's Path", "The Coaching Habit", and "Act Like a Leader, Think Like a Leader". If you read a handful of these books, I think it will put you in a good frame of mind for not only managing teams but being an effective leader.
joans's review against another edition
2.0
Hard pass on this. Outdated concepts, outdated language, and all around not awesome. This book has a couple of ideas worth thinking about and bringing into our own practices of software leadership... but...
1. Every pronoun in the whole book is he. There's a preface where they defend this choice, and explain that it would have been too hard to change.
2. Despite assertions to the contrary, this isn't really a book that advocates treating everyone with respect and kindness. (which maybe should have been obvious from the title). There's a bit of lip service to treating everyone like adults, but there's also a bunch of ugly stuff about sneaky motivators and how to micromanage without seeming like micromanaging.
3. Weird bad racism about overseas work and cultural differences between programmers from different countries.
1. Every pronoun in the whole book is he. There's a preface where they defend this choice, and explain that it would have been too hard to change.
2. Despite assertions to the contrary, this isn't really a book that advocates treating everyone with respect and kindness. (which maybe should have been obvious from the title). There's a bit of lip service to treating everyone like adults, but there's also a bunch of ugly stuff about sneaky motivators and how to micromanage without seeming like micromanaging.
3. Weird bad racism about overseas work and cultural differences between programmers from different countries.
qofdnz's review against another edition
4.0
Actually pretty useful book. I don't actually have unmanageable developers working for me, but they do have their quirks.
kapsar's review
5.0
If you are new to managing a team this is a must read for you. While the book is intended for managers of programmers (developers, software engineers, etc...) I believe this book applies to just about any sort of creative. Obviously, some sections will be less applicable to architects like the agile sections, but in general, creatives are creatives. The authors, to some extent, recognize this by continually comparing software developers to musicians. Arguing, in fact, that the best programmers are typically fantastic musicians. There's a similarity in the way the brain works between musicians and developers. I think this applies to other artists as well, especially ones that under went rigorous training to be an artist. There are processes you need to follow to enact your vision.
Anyway, the book itself offers very candid advice on everything hiring, firing, building local and remote teams, coaching, rewarding, and having fun.
The authors argue that hiring is the most important job of any manager. I think this is true from my experience interviewing people and managing people. Whenever you hire someone the work environment shifts. So you need to make sure that whatever change the person brings is a net positive for the team. To ensure that you get the right combination of fit and skill you must have a rigorous process for finding potential candidates, screening candidates, and interviewing candidates. If you do not you will pay for it later by losing your best people or being required to fire that hire in the future for lack of performance.
All this and templates are laid out in the book. The tools and rules of thumb are fantastic for first time managers and managers that have struggled to hire the right team.
The authors argue the most important functions of a manager are Hiring/Firing, Coaching, Developing individuals and teams. I think this is right. The manager should be technical enough to help with the team as needed, but shouldn't be expected to roll up their sleeves too much. Their skill is more important in investigating logical approaches than the specifics of coding. However, there are a lot of people that believe their manager should be able to do their job. Which i think has a lot of merit.
This book also has some great ideas of how to convert traditional managers into agile managers. Ironically, if you follow their advice through most of the book, you'll be well positioned to be an excelled agile manager positions to remove impediments.
I highly recommend this book for any one managing programmers, engineers, or creatives in general.
Anyway, the book itself offers very candid advice on everything hiring, firing, building local and remote teams, coaching, rewarding, and having fun.
The authors argue that hiring is the most important job of any manager. I think this is true from my experience interviewing people and managing people. Whenever you hire someone the work environment shifts. So you need to make sure that whatever change the person brings is a net positive for the team. To ensure that you get the right combination of fit and skill you must have a rigorous process for finding potential candidates, screening candidates, and interviewing candidates. If you do not you will pay for it later by losing your best people or being required to fire that hire in the future for lack of performance.
All this and templates are laid out in the book. The tools and rules of thumb are fantastic for first time managers and managers that have struggled to hire the right team.
The authors argue the most important functions of a manager are Hiring/Firing, Coaching, Developing individuals and teams. I think this is right. The manager should be technical enough to help with the team as needed, but shouldn't be expected to roll up their sleeves too much. Their skill is more important in investigating logical approaches than the specifics of coding. However, there are a lot of people that believe their manager should be able to do their job. Which i think has a lot of merit.
This book also has some great ideas of how to convert traditional managers into agile managers. Ironically, if you follow their advice through most of the book, you'll be well positioned to be an excelled agile manager positions to remove impediments.
I highly recommend this book for any one managing programmers, engineers, or creatives in general.
More...