Mickey Mantle and Ron Lichty have written a book about managing and employing programmers: "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams” . The book examines the characteristics of programmers and programming teams, drawing on their own experience, interviews and conversations with programmers, team leaders, managers, directors and CTOs. They provide a variety of tools along with many rules of thumb they’ve collected through the years. Recently they spoke to InfoQ about the book:
InfoQ: What is the underlying problem – why did you write the book?
As software professionals, we watched the software industry evolve for decades with emphasis on faster hardware, new and “better” computer languages, development frameworks, process improvement and certification (e.g., ISO 9000), and evolving project management methodologies – all great contributions to the software industry. But we found scant attention paid to the heart and soul of the software industry – namely, the legions of programmers who do the work of making great software products – and how to manage those programmers effectively.
Our experience as programmers, and the decades we spent managing programmers, taught us many valuable lessons about who programmers are, what motivates us, and how we can be managed effectively.
We found few books that addressed the challenges of managing programmers and programming teams, and those that did we found lacking many of the lessons we learned over the years. So we decided to write a book taking a very personal point of view by sharing many of the anecdotes, lessons, and tools we have learned, acquired or built over the years that we’ve used to manage programmers effectively.
InfoQ: What qualifies you to write about this topic – why should people listen to your points of view?
We are not academics; we have written code and managed teams that have delivered software products that have been used by a vast number of computer users. At one point, when Ron headed development of screen savers and games at Berkeley Systems and Mickey headed development of Broderbund Software’s renowned kids and entertainment titles, we may have had more eyeballs engaged with titles our teams wrote than almost any other two development managers in the world. We tell stories of creating these products and managing these and other teams, sharing insights we have learned the hard way in the hope that we can make the job of managing programmers easier for other managers.
But the book is not limited to our experience. The “creamy center section”, as one reader referred to the 80 pages in the book’s center, is filled with 300 Rules of Thumb and Nuggets of Wisdom from programming managers around the world (including many luminaries). These are pithy words of wisdom that we have heard, read, and used ourselves over the years. We share them knowing these Rules of Thumb and Nuggets of Wisdom will help others just as they helped us.
InfoQ: Who is the target audience for the book?
We wrote the book first and foremost for front-line programming managers, both new managers and seasoned ones as well. The book provides a lot of hands on advice as well as tools they can use to become more successful as managers of programmers and programming teams.
The secondary audience is managers of programming departments who are, for the most part, charged with mentoring a staff made up of or at least that includes programming managers. Our hope is that, through Managing the Unmanageable, they will be able to rely on us to be their partners in starting and growing their programming managers and nurturing their departments.
The third audience – and we’ve been told by a number of CEOs, COOs and CIOs that we’ve hit the mark – is C-level executives who rely upon software (and the programmers who make the software) for the success of their company and want to gain insights into what it takes to manage the seemingly unmanageable programmers they employ.
Finally, readers keep telling us that Managing the Unmanageable is enormously useful to anyone who wants to be a better manager of people. Much of the book contains insights and tools that can be applied to anyone who wants to be a great manager.
InfoQ: Isn’t managing programmers just like managing any other role in the knowledge economy? What’s special about programmers?
Anyone who has managed other groups – including other engineering disciplines – in addition to programmers will likely reach the conclusion that managing programmers is both very different and more difficult. That is in part because the results are much less tangible (and hence harder to measure progress) than disciplines like hardware design or mechanical engineering. It’s also in part because while there are elements of programming one might refer to as “engineering”, there are other elements more aptly called “craft” or “art” or “trade.” Engineering is, for the most part, predictable and repeatable in ways that programming just isn’t. (When was the last time you heard about a tall building or a highway or a sanitation plant that had to be abandoned just short of being complete because the constructors couldn’t figure out how to finish it?) While all knowledge workers have their challenges, we feel the challenges are generally greater with programmers.
InfoQ: What is the most challenging aspect that someone wanting to manage a programming team must be prepared for?
Many new programming managers were only a short time before a peer of those they are now managing. The transition from individual contributor to manager alone is a challenge. Making that transition with a team you were formerly part of can be especially challenging. And to make matters worse, most new managers are promoted into that role without any formal training or even coaching on how or what to do. For many, that is the most challenging aspect of the new job.
A secondary challenge is knowing exactly what to do: what is important and what is not important. In our book we have tried to indicate the areas we think are most important and areas we think are less important for a new manager to focus on.
A third is a dramatic change in demeanor. A great programmer (as many if not most of us were, before being tapped to be managers) excel at shutting out the world and climbing into the “zone” – that quiet space that as a programmer you inhabit with the microprocessor alone, as you write code to bend it to do your will. A great manager, on the other hand, must not only lay down a virtual welcome mat outside their door but literally issue an open invitation to their programmers to interrupt them at any time with any issue. The job is no longer about personal accomplishment but about enabling and supporting the programmers on their team to accomplish.
InfoQ: You view programmers through various “lenses” in the book – what are the aspects that make a difference when looking at programmers, and why do they matter?
Our “lenses” look at types of programmers (e.g., systems programmers, database developers, etc.), different personality types (e.g., morning people, night people, etc.), different generations (baby boomers, millennials, etc.), and others. The key take away here is that, to manage a programmer effectively, you have understand them on a very personal level and use every tool in your bag to do so. Then provide motivation that will work best for that individual. That motivation varies widely. We even give a formula to help you figure out what matters most to a programmer!
InfoQ: You present distinctly different types of information in the book – some sections seem to be “how to” with templates, guidelines and checklists where others are focused on softer aspects such as culture, motivation and relationships. Why this balance, and what areas are the most important?
The different types of information go back to the subtitle of the book: “Rules, Tools, and Insights for Managing Software People and Teams”. The vision for the book was to provide these three different basic types of information – rules, tools, and insights – all three of which we wish we had had when we started out managing our peers and other programmers. Which one is more important will be up to the individual reader to determine for themselves. We think they are all important.
InfoQ: In the section on management you provide a whole chapter on “managing up” – surely that is a skill that every manager needs to have, irrespective of the domain they work in, again what is special in the realm of managing programmers?
You are correct, managing up is a skill every successful manager must master to maximize any success they find in their job. And we understand the importance of it all too well, after all these years of managing our bosses. Yet we have seldom heard this ever talked about in any management course.
But while managing up may be universal, we’ve added some specifics relevant to programmers who have become managers. While programmers usually report to former programmers, sooner or later (and more often than not) we programmer managers find ourselves managing bosses (and their bosses) who may not understand (or care to understand) the culture or technology that goes into managing programmers successfully.
InfoQ: You devote a chapter to corporate cultures and creating a “development subculture for success even in the most toxic of corporate cultures” – what is needed to create this subculture of success?
This is an important chapter in the book since it shows how to leverage the positive aspects of the company culture you have while trying to wall off any negative aspects of your company culture and substituting those with values the team you manage can embrace.
InfoQ: There is a whole section of “rules of thumb and nuggets of wisdom” that you say have proven valuable to you over the years. How should readers use these?
We think these rules of thumb and nuggets of wisdom provide some of the best “take aways” from the book. Just reading through these can give a manager confidence in his convictions to do what he thinks is the right thing for developing software, supported by the wisdom of others who have boiled their experience down into bite-sized bits of insight. We have personally used these to defuse arguments, make a point to our programmers that might otherwise not be listened to, and steer a better course for development. For example, when faced with a complicated solution to a seemingly simple problem – and often surrounded by demanding business partners who don’t understand why developing every function at once isn’t easy – how can one ignore “don’t boil the ocean”?
One of the first that we discovered we had both collected was Brooks Law: “Adding manpower to a late software project makes it later.” Fred Brooks codified that rule in his software project management classic, The Mythical Man-Month, almost 40 years ago – yet we keep running into executives who haven’t heard it. It’s useful to have a rule of thumb like that in your pocket.
InfoQ: In the accompanying website you provide a list of tools – what are the types of things that readers of the book will have access to on the site?
We have included tools that we have built or collected over the years, including sample job descriptions, checklists for getting a new programmer started off right, a sample project workbook to help in managing projects, quarterly goals templates, and many other useful tools. Good managers will want to personalize these tools, but having something to start with will save them a lot of time. We think the tools alone are worth more than the price of the book!
InfoQ: Is there anything else you’d like to share with our readers?
We wrote this book primarily to create something that we wished we had had when we first started out managing other programmers. Both of us were programmers before we were “promoted” into a manager’s position – like most, with no training, little guidance, and not much feedback. We both made mistakes but learned along the way and (according to those who worked for us) are both good, perhaps even great, managers. We hope that this book can make that transition from peer to manager easier for others, and we hope it can serve as a mentor to those programming managers who cannot find a good mentor of their own. We’ve written it from the heart with that in mind.
The authors provided also a sample chapter – Chapter 8 of the book.
About the Authors
Ron Lichty has been developing software for thirty years, most of them as a programming manager, director of development, and vice president of products and engineering for companies that include Apple, Fujitsu, Razorfish, and Schwab. He has written four books and hundreds of articles. He consults with startups and companies large and small to unravel the knots in software development and make it hum.
Mickey Mantle has been developing software for more than forty years as a software and hardware product creator, manager, and executive for companies that include Evans & Sutherland, Pixar, Broderbund, and Gracenote. He currently develops mobile/tablet applications, writes, and consults.