&;Mantle and Lichty have assembled a guide that will help you hire, motivate, and mentor a software development team that functions at the highest level. Their rules of thumb and coaching advice are great blueprints for new and experienced software engineering managers alike.&; &;Tom Conrad, CTO, Pandora &;I wish I&;d had this material available years ago. I see lots and lots of &;meat&; in here that I&;ll use over and over again as I try to become a better manager. The writing style is right on, and I love the personal anecdotes.&; &;Steve Johnson, VP, Custom Solutions, DigitalFish All too often, software development is deemed unmanageable. The news is filled with stories of projects that have run catastrophically over schedule and budget. Although adding some formal discipline to the development process has improved the situation, it has by no means solved the problem. How can it be, with so much time and money spent to get software development under control, that it remains so unmanageable? In Managing the Rules, Tools, and Insights for Managing Software People and Teams , Mickey W. Mantle and Ron Lichty answer that persistent question with a simple You first must make programmers and software teams manageable. That is, you need to begin by understanding your people&;how to hire them, motivate them, and lead them to develop and deliver great products. Drawing on their combined seventy years of software development and management experience, and highlighting the insights and wisdom of other successful managers, Mantle and Lichty provide the guidance you need to manage people and teams in order to deliver software successfully. Whether you are new to software management, or have already been working in that role, you will appreciate the real-world knowledge and practical tools packed into this guide.
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.
It was an interesting book, since I am a developer and I could identify with some of the topics. What caught my attention was how we (developers) are perceived by our managers, and that's exactly what I was looking for in this book.
I quite disagree with some of the things mentioned in this books, for instance:
* Remote teams don't work (and later on, they talk about some ways of "Controlling" and "checking" if they are really working) * They consider contractors as mercenaries, and later on, they say they should be treated differently from your onsite team - I particularly disagree with that, because I believe these contractors could perform better and give better input when they feel part of the team. * The most important person for you in the organization is your supervisor - I don't have anything to add here, as I believe this is nonsense. * If you have a boss with an inflated ego, you have to accept the behavior and basically do what the boss tells you to do - I strongly disagree with that. I believe that's completely dysfunctional and could create a lot of issues as it blocks a certain type of communication. * Participate in stand-ups to get a notion of progress - I think that could be very likely perceived as micromanagement. Instead, I would propose to proactively go to the team, during the day, and check out with developers what are they are working now, if they have any issues you could help and so on. Make this check-in very informal and friendly, and the developers will start naturally talking to you for future updates on the projects.
But as much as I don't agree with a lot of other things, this book could be a good resource for managers in a more "traditional" company, where they could be doing the famous command-control style of management.
I gave 2 stars to the book, because it doesn't deserve to be as good rating as other books in this field.
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.
It helped me think about the right topics, though I disagreed with the content at times. I was at least able to use the book to think about these different subjects and form my own opinions. The most interesting part of the book to me was the comically accurate software development stereotypes at times.
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.
A good book for better managers, but not great managers.
Almost all people I know having “manager” in their job title have learnt management "on the job." Even if there is nothing fundamentally wrong with learning from our mistakes (we all do it), for managers, mistakes always affect other persons. There must be a better way.
Through this book, co-authors succeeded in sharing their vast experiences, in a highly practical book, full of anecdotes, stories, quotations, and words of wisdom. The book clearly favors breadth over depth and you will get a really good overview of what it means to manage programmers in the real world. A quick look at the table of contents will show you that no topic was left out. Having this book on your desk is like having a mentor to answer (almost) all of your questions. This is a good book for better managers, but not necessarily for great managers.
Indeed, I think great managers need something that is absent from this book. The best management books I’ve read don't try to be so exhaustive, or to be so practical. They focus on making the reader think, delivering principles for him to be better prepared for the unexpected. The contrast is very apparent if I compare with my following reading, _Principles_ by Ray Dalio. It’s not one of my favorite books but nonetheless, it challenges several of my assumptions. I could also cite Trillion Dollar Coach, Creativy Inc., or Simon Sinek’s books. These books may appear less relevant in practice, but they are the books that taught me so much.
The truth is, to be the manager your team deserves, you probably need both kinds of books. I do not agree with everything that is presented in this book, but I still think it’s a valuable resource for newly-appointed managers.
I was probably not the best audience for this book, but I saw a recommendation and wanted to give it a try. It moved along like a user manual for how to manage programmers, with some natural progression, and the flow worked better in some places but not others. Listened to it as an audiobook, and as much leeway as I wanted to give the narrator, I found it not the best performance either. There are areas that have good tips, especially for new leaders, but could also work for seasoned ones. This was definitely directed at early supervisors though. It also felt like it contained many of the stereotypical tropes about programmers and programming culture, which true or not, felt a bit off-putting in some places both on behalf of programmers and those managing them. It was hard to get through. I found some earlier stuff interesting, and the later chapters felt a bit repetitive and dry.
It's a thick book which is supposed to be an engineering management manual that has all the answers. But it's a book written by baby boomers for baby boomers (don't worry, authors use this cliche themselves, it's not mine). It's based on how traditional, large, pre-digital enterprises approach the practice of software development and tries to give advice for that environment. Authors thrive in this environment and also, hey, they found Agile and are in love with it now. A lots of the contents may be a solid advice but half of it is trivial and another half irrelevant for the world of purely-software born-in-the-cloud startups that I'm interested in. The book is not engaging. When I left it for a couple of days and then got back opening on a page, it was hard to tell whether I've already read that page before or it's just looks the same. YMMV.
I have mixed feelings about this book, but overall it had a lot of good content.
Similar to a book I read prior to this, Managing Humans, there was a lot of repeated material... but it felt a bit more noticeable here.
Also, there's a fairly large section that's just filled with quotes and sayings that apply to software, management, etc. that seemed just sort of thrown in to add bulk. Not that some of it wasn't insightful, but many of them were also included in other areas of the book... so I didn't really get much value out of having a dedicated section for it.
That all being said... there was some really good advice in here, largely from the lessons-learned from both authors over the years, that I feel makes it worth the read.
My firsr book on such topics. I found it very insightful. Some topics presented were surprising (such as the comparison of different regional programming cultures), others were in tune with general moral intuitions (repeated suggestions for creating a fair culture). Still other topics were - I feel - better applicable in the US ( for instance the salary comparison sites cited didn't have data for eastern Europe). Overall, I recommend this book for people with not much prior knowledge in the field of management.
Above average source of knowledge for anyone interesting in learning the ropes of leading a software development team / delivery. Sadly rather verbose, lacking clear structure and whilst based on experiences shared by several developers, PMs and tech-leads somehow won't leave you much smarter if you have done your time as an apprentice at fairly reasonable shop. Recommended for these looking for a book that they just know theirs managers should read. ;-)
The book covers all the areas in IT software development management, which is informative for someone new to such role but not necessary a bible for the experienced. It also seems that the practices are more appropriate for large shops. For others, there are always time and occasions where management of people in this domain have to depend on the individual person, shop or company setup, business environment and culture ... which ends up to be pragmatic when required.
- Stereotyped personality types of programmers based on the type of work they do (database vs. systems vs. frontend, etc.) and used that as a way of understanding how to manage each type. - Stereotyped values of people based on the generation they were born into - Advised giving "gifted systems engineers" huge amounts of leeway and not forcing them to abide by standard process that everyone else needs to abide by
After finishing this book i now have a more complete picture of my responsibilities as a engineers manager. Ample tools are provided to solve common problems. Many tips for the day to day are shared. I’ll keep this book as a reference close to me and check it often when facing challenges described in it. It will be my paper mentor.
Wish I had read this book years ago, true words on software delivery and management
Pretty good book on managing software teams. Some wise words on customer centricity it that I wish I had read before. Does get a bit verbose on certain points. However, some very inspiring ideas and practices are laid out and easy to put into practice.
I recieved this book for free from Goodreads First Reads. While I am not in the programming field nor have any interest in this career field I did find this book very informative. It gives a lot of insight into software develepment, writing job descriptions and how much college education you would need to go into this field.
Summarizes managing a software team / software product in detail fit for newly appointed manager, very applicable also for team leader status, and beneficial read for anyone managing anybody in the programming field of work