Preface
All too Often, Software Development is Deemed Unmanageable. The news abounds with stories of software projects that have run ridiculously over schedule and budget. While strides made in formalizing the practice of software development have improved the situation, they have not solved the problem. Given that our craft has amassed over 60 years of experience and our industry has spent enormous numbers of hours and dollars/yen/won/yuan/rupees/euros trying to bring this discipline under control, how can it be that software development remains so unmanageable?
In this book we answer that persistent question with a simple observation: You first must learn the craft of managing programmers and software teams. That is, you must learn to understand your people—how to hire them, motivate them, and lead them to develop and deliver great products. Based on our own experience, and that of effective managers we have known in virtually every type of software business, we aim here to show you how. Combined, we have spent over 80 years working on and delivering a wide spectrum of software programs and projects—over 65 of those years managing the programmers and teams that delivered them. We hope that this book will help you avoid many of the mistakes we have made, as well as leverage for your own success the insights and skills we have learned.
Early in our careers as programmers, we both read Fred Brooks’s 1975 book The Mythical Man-Month. An instant classic among programmers, it is full of wisdom still relevant today and is widely regarded as a definitive work in the art of software management. Like many others who read it, we found the most memorable parts to be Brooks’s one-line nuggets of wisdom, such as “Adding manpower to a late software project makes it later.” We can’t recall the number of times we’ve used this quote when managing software projects. The desire to find other such memorable rules of thumb1 was the inspiration and driving force behind the writing of this book.
1. See the 300 Rules of Thumb and Nuggets of Wisdom in what one reviewer called the “soft, creamy center” of this book.
We were already seasoned managers when, as friends, we began meeting regularly to compare notes on our current work and software development challenges. We found ourselves getting help from each other and sharing an occasional nugget of wisdom or rule of thumb, which we would then take back to our jobs, integrate into our management approach, and share with our teams. We gleaned rules and nuggets from the books we read and the Web sites we surfed, but we never found a collection of them specific to managing programmers and teams developing software. Eventually our own desire to have such a collection led to our decision to write this book.
A broader perspective emerged as we began writing and talked to managers, directors, and CTOs. It became clear that we could draw from the breadth of our industry experience to offer considerably more than the rules of thumb we’d collected. We could also share the tools2 we’d developed and the insights we’d gleaned from working in start-ups and in organizations of every size.
2. See the tools for each chapter in the Tools section at the end of the book.
There are certainly areas we haven’t touched in our careers—domains such as large-scale government contracting and defense systems. But our experience is relevant to most companies developing software today, including those companies whose managers are working on the edge of innovation. That latter group tends to be young and is seldom offered any formal management training or organizational support—or has time for it anyway. Unfortunately, that’s how all too many managers learn today: on the job.
We wanted to write a book that could be a mentor of sorts for programming managers—a book filled with insights, stories, and guidance gained from years of learning the hard way how to do it successfully.
We realized we could also share the tools we have developed over the years that make managing easier—tools such as job descriptions, rankings spreadsheets, project workbooks, team technology inventories, programmer first-day schedule templates, and hiring checklists. They can save managers many hours developing tools from scratch when they find themselves working in organizations that are too immature to provide their people with the tools they need (all too common, unfortunately, in the fast-moving world of software development). These are the tools we wished we’d had when we first started managing.
We wondered if there needed to be another book about software development. Surely—with no end of books, articles, and Web sites about engineering software, managing process, and managing projects—some number of gifted engineering managers must have shared their secrets. Yet we found scant more examples focused on managing programmers and software development teams than we had when we began our careers.
There is no methodology for newly anointed development managers charged with managing, leading, guiding, and reviewing the performance of a team of programmers—often, the teams they were on just days before. There are no off-the-shelf approaches. Unlike project managers, who devote hours and hours of study toward certification in their chosen career path, development managers often win their management roles primarily from having been stellar coders while displaying a modicum of people skills.
Among the books we did find, none contained the kinds of behind-thescenes stories and anecdotes we have incorporated into this book—stories and anecdotes that speak directly to how to handle specific situations that managers face.
Organization of the Book
In the chapters of this book we share our hard-won experience gained from programming, managing, and delivering software spanning two managerial lifetimes of companies and situations. We have distilled our insights into ten chapters sprinkled with anecdotes from our experience, as well as Rules of Thumb and Nuggets of Wisdom collected from others.
Chapter 1 reviews why programmers are special when it comes to managing them as individuals and managing them as teams. It’s thinking about the qualities that characterize programmers that makes it obvious why you can’t just pick up any book on management to start managing a team of programmers.
Chapter 2 provides a number of lenses through which to view the programmers on your teams that will help you see the individuality each of them brings—and inform your managing each of them uniquely.
Chapter 3 is a step-by-step guide to finding, recruiting, and hiring great programmers. Early readers of this chapter found themselves tearing it out of the manuscript to use separately. You may, too, but you’ll leverage it best from the context of the prior two chapters—knowing just who it is you’re hiring—and from incorporating culture and motivation from Chapters 7 and 8.
Chapter 4 counsels how to keep candidates’ enthusiasm between “yes” and start; prevent “buyer’s remorse”; and, when they do arrive, integrate them quickly, effectively, and productively into your processes and practices. New managers tend to think their recruiting role is finished when a candidate accepts an offer, but too many have learned otherwise when a candidate failed to show up for their first day, floundered in fusing with the team, or never became productive.
Chapter 5 walks through the core of management—managing down. These are the mechanics and how-to of the day-to-day with your team, the tasks and interactions to successfully manage programmers.
Chapter 6 addresses the fact that success as a programming manager also demands that you become skillful at managing up—managing your boss (and possibly his boss); managing out—managing your relationships with your peers, leveraging other departments or folks within your company, and marshaling external resources and relationships; and finally managing yourself—your priorities, your style, your time, your growth, your life.
In an interlude called Rules of Thumb and Nuggets of Wisdom, inserted between Chapters 6 and 7, we’ve collected hundreds of, well, rules of thumb and nuggets of wisdom that have proven valuable to us over the years, denoted by lightly shaded pages for ease of access. We collected them from a broad cross section of programmers, development managers, and software luminaries.3 The wisdom drawn from these adages, used judiciously, can help you make a point, win an argument, reframe a conversation, or defuse a tense discussion with a bit of humor that still drives your position home.
3. If we have misattributed a rule of thumb or quote, we apologize in advance (and please let us know). Some of them are available only through word of mouth or indirect sources, making completely accurate attribution almost impossible. The titles given in the attributions are those for which the person is best known or, in many cases, their title when we knew them and heard their insights directly.
Chapter 7 turns the focus back to the team and the critical task of motivating programmers to accomplish great feats and deliver difficult projects. The chapter opens with grounding in the motivational theories of Maslow, McGregor, and Herzberg. The differentiation of motivators from demotivators— they are very different, contrary to popular thinking—was essential to our own managerial growth. Given that each programmer is unique, there’s no motivational silver bullet, but our framework can help you think about ways to motivate—and how to recognize and avoid the potholes that demotivate—your team.
Chapter 8 provides context to think about your corporate culture and about how you can create the development subculture you need for success within even the most toxic of corporate cultures. Too few managers realize their critical role in creating a team culture that supports success. Chapters 5 and 6 cover the mechanics basic to managing, but Chapters 7 and 8 cover the two subtle sets of soft skills that can differentiate your management and help pave your way to success.
Chapter 9 returns to basics. The eight preceding chapters ultimately point to this objective: delivering software successfully. This chapter is not about project management but about the role seldom addressed: the team manager’s essential role in delivery, even in agile environments. Success depends on synthesizing all the skills and efforts outlined in the previous chapters, as well as a mindset that is all its own.
Chapter 10 expands on the topic of agile development that is sprinkled throughout the book and answers the important question of what the role of a manager is when a company transitions to self-directed agile teams.
The Tools section provides a collection of useful tools, among them checklists, forms, reports, and so on, that we devised to aid our efforts to recruit, hire, and effectively manage and motivate programmers to deliver quality software successfully. We’re certain they will aid your efforts as well and save you the time of having to create them anew. These tools are available online at www.managingtheunmanageable.net/tools.html.
Use This Book as a Reference
Many of the readers of the first edition of this book told us that they not only read the book but, more importantly, also used it as a reference that they turned to whenever they found themselves confronted with a management problem. We originally intended it for exactly this purpose, so we are glad to see that some have embraced it as we intended. We encourage you to pull it off your bookshelf when you wonder, What would Mickey or Ron do now?, and look in the detailed table of contents or in the carefully constructed index to find the section or sections that might apply to your problem. It’s like having a personal mentor, always available to help.
Lessons Learned
Programmers and software teams need not be unmanageable, but it takes talented managers who are dedicated to doing the hard work of managing seemingly unmanageable personalities to succeed. We can certainly affirm that writing this—and the rules, tools, and conversations we shared as we transformed our thinking into words—made both of us better managers, made our jobs easier, made our teams happier, and made our projects more successful. We hope the rules, tools, and insights we have provided in this book will make your jobs easier, as well.
Remember: Managing the Unmanageable comes in three parts. You can forge straight ahead into the chapters. Or you can dip into the Rules of Thumb and Nuggets of Wisdom, which appear as an interlude between Chapters 6 and 7. And at any time you can look through the tools, summarized in the Tools section at the back of the book, for extra resources.
Acknowledgments
There are many people to thank who have helped us write this book. First and foremost, we want to thank our wives for encouraging us in our efforts to draft, redraft, and craft this book. Without their patience, help, and advice this book would not have been possible. Second, we want to thank Peter Gordon and Kim (Boedigheimer) Spenceley of Addison-Wesley for their continued support and advice over the years and for having faith that the work we would create was worth their time and energy to help make it happen. Peter’s advice on organizing the book was especially helpful in the late stages. Kim bravely brought us into the multimedia world, signing us up to, in 2017, transform these words into video training as LiveLessons: Managing Software People and Teams.4 And many thanks to Haze Humbert, editor for this second edition.
4. www.managingtheunmanageable.net/video.html.
Next, we must thank the many originators of the rules of thumb that we have included in this work. The sage wisdom that they repeatedly imparted was the primary motivation for this book, and we marvel at the depth of insight that can be conveyed in so few words.
We must also thank the many reviewers who spent considerable time and effort to provide detailed feedback that helped guide us to revise and improve our writing over the years. Among them were Brad Appleton, Carol Hoover, Carrie Butler, Clark Dodsworth, Daniel J. Paulish, David Vydra, Dr. Dinesh Kulkarni, George Ludwig, Harinath V. Thummalapalli, Jean Doyle, Joe Kleinschmidt, Kinnar Vora, Margo Kannenberg, Mark Friedman, Michael Maitland, Patrick Bailey, Rama Chetlapalli, Stefano Pacifico, Steve Johnson, Steven Flannes, and others who remained anonymous to us. We are grateful to Niel Nickolaisen, Rich Mironov, Cathy Simpson, Ed Burnett, Travis Klinker, Rob Parker, John Colton, Scott Henderson, Matthew Leeds, Anthony Moisant, and Thomas Barton for their insights into the new material in this second edition. Thanks to Marty Brounstein for clarity on his intervention technique. Special thanks to Georgia McNamara, who showed us the way through the vagaries of the English language to rid this writing of unintended male-gender references and make it as friendly to all as we had originally wanted; we are so, so appreciative. This work is definitely better because of all of their thoughtful feedback.
Figure 10.1 was created using the people artwork designed by rawpixel. com/Freepik. Figures 10.7 and 10.8 are courtesy of agilemanifesto.org.
Finally, we would like to thank the legions of programmers, managers, and executives with whom we have worked in all the various companies throughout our careers. It is because of them, and the experiences we gained working with them, that this book is possible.
Mickey W. Mantle
Ron Lichty
October 2019
Register your copy of Managing the Unmanageable, Second Edition, on the InformIT site for convenient access to updates and/or corrections as they become available. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN (9780135667361) and click Submit. Look on the Registered Products tab for an Access Bonus Content link next to this product, and follow that link to access any available bonus materials. If you would like to be notified of exclusive offers on new editions and updates, please check the box to receive email from us.