Managing the Unmanageable: An Interview with Mickey Mantle and Ron Lichty on Managing Programmers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
There's a ring of truth to the line, "Managing programmers is like herding cats." The problem domain of software is both challenging and unpredictable, making to-the-minute estimates nearly impossible. Aside from a few specific kinds of software (mainly NASA spaceware), "nailing down the specifications" is better done agilely, iteratively, incrementally: when requirements are "nailed down", they are more often than not full of ambiguities, too extensive to grasp, and even at hundreds of pages, inevitably incomplete. Add to the mix customers who don't think symbolically, a little bit of pressure, bring to boil, and stir, and managing programmers and programming teams can be a real challenge.
Then again, perhaps not.
Once in a while you run across software leaders who, instead of trying to lay down the law, have pulled together Rules of Thumb and Nuggets of Wisdom that they leverage as guidelines, applying their own insights drawn from decades of experience. Mickey Mantle and Ron Lichty fall into that category. With seventy years of software management experience between them, they have written Managing The Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams.
Matthew Heusser interviews Ron and Mickey about why they felt compelled to assemble their insights and their collected Rules of Thumb and Nuggets of Wisdom into a book, and what it might mean.
)
Figure 1 Mickey Mantle and Ron Lichty
Matt Heusser: I notice that part of your book’s subtitle is "Software People and Teams," not "Software Projects and Teams," and that you draw a distinction between people management and project management. Tell me a little about that.
Ron Lichty: “Manager” is a term that gets used in a lot of ways. “Project managers” manage projects and “product managers” are responsible for products, for example. But neither is a manager in the organizational sense—neither is responsible for managing people. When you draw the org chart, programmers report to “managers”—they’re sometimes given titles like “programming managers” or “software development managers” or “software engineering managers.” They may have responsibility for shipping products, but every one of them is a people manager. They’re responsible for hiring, growing, managing and, if they make a bad hire or inherit one, firing people.
In our experience, project managers and product managers get a fair amount of training to do jobs that are very focused. Programming managers, on the other hand, were trained to write code. Whether in school or on the job (or both), they were trained to program and became programmers.
And then one day, the organization had a need for a programming manager. The current one quit or was promoted, or the team grew too large for one manager to manage, and someone pointed at one of the programmers and said, “You—yeah, you there—you know how to write good code and you seem to have some people skills—you be the manager.” In the span of a moment, a programmer became a manager—with no training in school, no prior training on the job, and, except in the largest companies, no training to come.
Managers are expected to hire, fire, mentor, coach, grow, encourage, and motivate teams of programmers; their role has changed from spending much of their time shutting out other people, as a programmer, to needing to welcome every interaction and every interruption from their team and peers and boss. Their peers are suddenly not other programmers, but other managers, many of whom don’t speak “programmer”. Their peers may be in product management or marketing or sales; their boss may not have been a programmer, so they may now report to someone who doesn’t speak “programmer,” either. Their new reports were their peers yesterday. Those reports may all develop the same thing or may be assigned out to various project teams over which the manager has little control or even visibility. And for all that, what qualified them to become managers was that they programmed well and maybe had some people skills!
Programming managers may or may not have the help of a project manager. Their developers may be assigned to teams with scrum masters who are focused on ensuring delivery. They almost certainly have responsibility to remove impediments and ensure their programmers have the motivation and morale to be successful getting products completed. But it is fundamentally an organizational role. Project management, hard as it is, is straightforward to describe and accomplish. Managing people and teams is much more nebulous.
Mickey Mantle: Ron and I were both programmers before we became programming managers. And we were both thrust into a position as manager of other programmers, more because there was a vacuum that we agreed to help fill than our demonstrated ability to manage people. As such, we both remembered painfully that transition from peer to supervisor; programmer to programming manager. It wasn’t easy, and we both made a lot of mistakes. For some mistakes, when I remember the experience, I visibly wince, it is so painful to remember. I think part of our motivation for this book is to try to make that transition less painful for others than it was for us.
I know that I often wished there were an “owner’s manual” for my job when I first became CTO and VP of Engineering at Broderbund Software. I suddenly had nine Directors or Managers reporting to me and a development organization that was 250+ overall. I had to work hard to keep up with them all and actively manage the people, help manage the teams, as well as participate in key product designs. I wish I had this book then; it would have made things easier for me.
Matt: Who is the audience for your book—and why is the existing literature insufficient?
Mickey: Our audience is first and foremost the new (or seasoned) programming manager who spends his days, nights, and weekends directly managing programmers working on software development projects. However, we feel the information we have provided would also be of value to those who must manage these programming managers—Directors of Development, Vice Presidents of Product and Engineering and such— to help them better understand and appreciate those who may not be direct reports, but do report indirectly up to them.
Additionally, we also feel there is real value in many of the insights we have provided in the nine chapters—as well as the Rules of Thumb and Nuggets of Wisdom—for “C level” executives (the CEO, COO and even CFO). All too often the success of their companies is in the hands of an unruly collection of programmers whom they don’t understand, having never been programmers, or whom they are now too removed from to appreciate. Execs make demands for schedules and deliverables, without understanding the complexity of their requests or what motivates programmers and how to make them more effective. It is not as simple as the “either carrot or stick” that far too many CEOs or CFOs would like to believe.
We are not aware of a book that tries to address this topic in the same manner; we have tried to provide the insights gained from decades of experience much as a mentor would, sprinkled with Nuggets of Wisdom and Rules of Thumb from many others to accentuate and highlight our observations.
Ron: As we began to write the book, we surveyed the existing literature and found stacks and stacks of books on project management, process improvement, and product development, but hardly any dealing with actually managing programmers and teams. Even after all these years writing the book, we can still count the number of books about managing programmers and programming teams on one hand.
Matt: Do you think that the Agile movement de-emphasizes traditional 'line' management? What impact do you think that has had?
Ron: The fact that you characterized Agile as a movement acknowledges that there’s no one voice of Agile. Scrum is focused on providing a framework for how project and product teams work. XP is focused on practices to make programming more effective. All of Agile proposes to work from a set of values and principles.
Agile done well reaches into and affects and changes every part of a company and how it works, but Agile is not about the structure of the larger organization.
As a result, if you go looking through all the literature and across all the web sites, you’ll be challenged to find a single scrum team drawing that has a programming manager in the picture. There will be programmers and a scrum master and a product owner in virtually all of them, there may be testers and interface designers and writers called out as part of the team, there may be product managers and stakeholders and customers—but functional management is never drawn in.
It’s understandable—Agile is grass-roots—it bubbled up from and through programmers and teams—but the approach has left programming managers scratching their heads as to their roles. Part of the challenge programming managers have is that their roles change significantly, but change differently within every company.
What I believe to be true is that programming managers, in part because they have a bit more visibility and influence than individual contributors, have a crucial role to play in helping their companies transition to Agile successfully. Mentoring and coaching their developers is certainly a part of that, including recognizing and bolstering success patterns and recognizing and countering anti-patterns. So is helping their peers to understand how Agile works and the business case to be made for supporting the transition, including dispelling myths that often run rampant through the organization—myths like “Agile doesn’t use requirements” or “Agile has no rigor” or “you can’t plan or estimate if you’re doing Agile” or “Agile is what our developers do—our part of the organization is unaffected by this Agile stuff.”
Mickey: Where Ron is bought in, I’m personally skeptical about the wisdom of companies embracing Agile completely. While I have seen Agile teams perform exceedingly well, I have also observed the same teams struggle to actually meet overall company needs effectively. I am wholeheartedly behind any movement that promises to improve the process of developing software, and the Agile movement has much it can offer there. But all too often, I’ve seen the “religious right” of the movement take strident stands that seem to place “form over function.” I personally believe, and this has been collaborated by acquaintances of mine in other companies, that Agile is more effective when it is a blend of some of the rigor of waterfall requirements and final system testing with the nimbleness of agile development sprints.
But regardless, there remains a strong need for capable programming managers who actually manage people and teams, not just process.
Matt: Where do most new managers struggle, and why? Are there common problems all managers seem to have?
Mickey: Many new managers don’t know how to tell the important from the unimportant; the urgent from the not so urgent; the good communications from the bad; or that they must create their own software development culture that leverages the good of their organization while filtering out the bad. We provide examples of what has worked for us and what we have done that we hope will help others find their own way more easily than the “trial and error” methods that we employed.
A majority of programming managers share the same problem—how to find, hire, bring up to speed, motivate, and manage great programmers. If you hire the right people, everything else is easier. If you hire the wrong people, you’ll spend way too much time focused on the wrong programmers—those who are not great and struggling to do their job. If you hire the right programmers (including some great programmers) you will be freed to focus on making the projects and products run better and hiring more and better people. We provide insights that should let you “cut bait” on the bad programmers more quickly and feel good about it. We also provide insights that should allow you to hire the right people up front, and to keep them working productively.
Ron: New managers are also saddled with thinking that what will bring them success as managers is what brought them success as programmers and got them promoted to be managers. But what makes a great programmer is owning solutions to the tough requirements, while what makes a great manager is delegating them. What makes a great programmer is the ability to close out distractions, while what makes a great manager is welcoming interruptions from your programmers and recognizing that what’s important to your team can never be a distraction. As a programmer you’re rewarded for doing. As a manager you’re valued for mentoring and coaching others to do the designing and programming and do it as a team.
In addition, programmers tend to think the role of manager consists of the interactions they have had with their managers. Those are certainly important, and they may not be easy, but they’re a fraction of what it takes to manage in an organization. Programmers may never see the extent to which good managers protect them from organizational politics; the effort that good managers put to forging relationships with and collaborating with other parts of the organization on behalf of their teams and their teams’ projects and products; the challenges of troubleshooting organizational dysfunction; or grappling with the need to manage not only your people but your boss. And then there’s the point Mickey made about hiring. Programmers may have had opportunity to interview a few candidates, and may even have given thumbs-up or thumbs-down to a few, but most have no idea how hard it is to un-make a bad hire decision. Those are all insights we hope to share, challenges we hope to ease.
Matt: What kinds of problems does your book solve? I understand you organized it in a unique way.
Ron: The book solves the kinds of problems that we faced when we were first given managerial roles, as well as when we moved up in our organizations, the challenges that the managers we hired and promoted faced. Mickey and I have now known each other for 16 years. Over the course of the first eight, we were getting together for Saturday breakfasts every couple months and discovered that we shared common understanding about the problems we faced as engineering managers, and we grew to value each other’s insights into how to solve them.
It was the problems and challenges that led us, eight years ago, to imagine crafting a book together and to realize it might have three parts: what we called “rules, tools and insights.”
Mickey: We’re both collectors of quotes, and we began to realize they fall into two groups: Rules of Thumb—the pithy, concise, short statements that form the instruction set for managing people and teams; and Nuggets of Wisdom—short, crafty insights into our jobs and into organizations and people and tools. We also found them immensely useful in managing our people and teams day-by-day. It’s funny how you can talk to programmers at length about what they should be doing, how to improve, or what they should not be doing, but how hard it is to get them to listen. But a well crafted quote or rule of thumb can stop them dead in their tracks—and they’ll remember it.
Likewise, I’ve seen Rules of Thumb and Nuggets of Wisdom completely disarm participants in a heated executive battle, turning the situation from adversarial to team-building. Such is the power of the right saying at the right time.
It was experiences like those that got me thinking that we should collect and publish a book of Rules of Thumb and Nuggets of Wisdom that speak to managing software people and teams.
Ron: Mickey inspired me with the notion that Rules of Thumb would form the core of the book. We’d traded plenty of those over breakfast, and helped each other on occasion distill our thoughts into Rules of Thumb of our own—we both valued them highly.
But years of sharing our careers with each other combined with my having written four books previously—two general nonfiction, two programming texts—made me certain that we had insights to share above and beyond our collections of Rules of Thumb and Nuggets of Wisdom.
As we sat down together to think through our own insights, what would become nine chapters fell into focus before us. We realized we wanted to start from who we had been as programmers—why we ourselves had been a challenge to manage, how we had wanted our own managers to understand us, and how we had grown to understand the other kinds of programmers out there. We wanted to share our hard-won insights about recruiting and hiring programmers. We realized a crucial time period almost never addressed is the time between when a programmer accepts your offer and the day they start. We realized, as well, how crucial it is to get right the first day and the next few days and weeks that follow. (Both led us to flesh out some great Rules of Thumb and Nuggets of Wisdom from our peers that we’d never seen shared anywhere). We felt we had insights into the nuts and bolts of managing that would also be worthy of sharing. And then there are the parts that benefit our teams immeasurably but that they get, at most, glimpses of—managing out and managing up. In addition, we had taken up the expectation of our organizations to motivate our folks only to discover much later the truths and wisdom that could be gleaned from general management theory. We realized the importance we both hold for creating culture and how much we had learned through our careers about the interaction between programming culture and larger corporate cultures, whether aligned or at odds with each other. And finally, we knew we needed to write about working with project managers to deliver the stuff for which we and our teams were hired: software products and services.
Mickey: Once the book began to take shape with gathering the Rules of Thumb and recording our personal insights in the chapters of the book, the notion of including some of the Tools we have created and collected over the years emerged. Ron and I had been collecting forms, spreadsheets, documents, and all sorts of tools for managing people and teams during much of our careers. It seemed natural to share these with the readers of the book—those new managers who could benefit from having something that worked for us that they could easily personalize for themselves.
Included are sample job descriptions, a company ranking and roles chart to help understand where and how programmers fit into a company organization, a sample welcome message, an objectives spreadsheet for managing personnel quarterly and yearly objectives, and many more that are relevant for almost any programming manager and that they can personalize and leverage.
Ron: Ours is an unusual book, in having those three parts: rules, tools and insights. What we didn’t know was how to present them—how to make a book honor all three parts equally, even though they were different in size and makeup. We credit our editor at Addison-Wesley, Peter Gordon, with strokes of design genius: that we could shade the three sections differently; insert the 80-plus pages of rules in the middle of the book, printed on a different paper background, where they could be thumbed and bookmarked and easily returned to over and over; and insert descriptions of and pointers to the tools in a short section after the chapters, before the index, delineated with edge-markings. That design makes the book enormously usable.
Mickey: Rather than burden the book with the Tools on CD-ROM or printed out on paper, we decided to put them up on our website (www.managingtheunmanageable.net) so that anyone who owned the book could freely download them. The tools are organized by chapter, so that a programming manager can reference a chapter for needed insight, then go directly to the website and download any cited tools that might be of help. It represents a head start for managers that we both wish we had had when we started out managing programmers!
Matt: How did you decide on the structure for Rules of Thumb and Nuggets of Wisdom? Or, to ask it a different way, if you take a step back from the Rules of Thumb, turn your head and squint, how do you know that the list is complete?
Ron: The structure for organizing the Rules of Thumb and Nuggets of Wisdom fell out from the areas of managing that we focus on in the book: 1) the challenges inherent in managing people, 2) the challenges unique to managing programmers, and 3) the challenges peculiar to delivering software successfully. That was the easy part.
Then we realized that for many of them, we additionally wanted to share observations about their applicability - sometimes our own observations about using a rule, sometimes additional reflections from the rule's source.
Mickey: The hard part, of course, was collecting and selecting the Rules of Thumb to include. We asked our friends and colleagues, read books and articles, searched websites, and basically tried to find as many relevant Rules of Thumb and incisive Nuggets of Wisdom as possible. But in no way is our collection complete. Our collection will never be complete. I’m certain there are many more out there—truly important Rules of Thumb—that we haven’t read, seen, or heard—or have forgotten if we did—plus Nuggets of Wisdom that have yet to be spoken and others that have not yet been shared. Our plan is to solicit more via our author website (www.managingtheunmanageable.net) and include them in a 2nd edition, assuming there is one. In the meantime, we'll post the best ones that are submitted or we otherwise run across on our website until there is a 2nd edition.
Matt: What is your favorite Rule of Thumb or Nugget of Wisdom?
Mickey: My personal favorite is “Change equals Opportunity,” which I learned from Doug Carlston, the founder and CEO of Broderbund Software. We were in the midst of the transition from MS-DOS to Windows 95, and as we began strategizing what to do with our products he mentioned this Rule of Thumb to me in planning that transition. Of course, Doug didn’t really invent this Rule of Thumb. The Chinese character for Danger is the same as for Opportunity…so of course this idea probably goes back millennia. But Doug drove it home to me in the technical world, and I’ve embraced it ever since. Whenever there are “sea change” events, I look for the opportunities that can arise from them. I founded my current company, Wanderful, Inc., to take advantage of the sea change happening with the transition of Apps from computers to devices. It reminded me of how much I like Doug's quote—we refer to it in Chapter 6, but it deserves to loom large in the core Rules of Thumb section. So it—and this commentary—is the first of those "emerging" Rules of Thumb we've posted to the website page I mentioned (www.managingtheunmanageable.net). Of course, finding the right opportunity to take advantage of when there is change is always the hard part. In my case, I think I have done that in spite of the hundreds of thousands of Apps that are being produced for tablets and smart phones.
Ron: The Rule of Thumb that I return to over and over is "Trust but Verify." For me, I think it expresses both the imperative not to micromanage and the essence of delegation. It's often attributed to Ronald Reagan, who used it during the Cold War to refer to the Soviets, but he was quoting a Russian proverb that had been equally frequently quoted by Soviet founding father Vladimir Lenin. Alan Lefkof, president and CEO of Netopia for many years, expressed the same thought another way I like, "I inspect what I expect." He told me he'd learned it from Lou Gerstner when he was at McKinsey. Like Mickey's favorite, we reference this one in one of the chapters (Chapter 8), but it deserves to be part of the core Rules of Thumb section, so it's up on the web page, too. I find myself doing more and more mentoring of managers at all levels (via Ron Lichty Consulting), and these are a couple Rules of Thumb I often share as a pair.
Matt: If you only had five minutes of advice to give to a new manager, what would it be?
Mickey: I would probably quote two Nuggets of Wisdom (both of which are early on in the Rules of Thumb section in the book) that I have used innumerable times over the past 20 years from two captains of industry who were both incredible leaders of their respective companies:
Andy Grove, Intel: Managers must manage.
Lee Iacocca, Chrysler: People, products, and profits (in that order).
These simple messages have guided me through many hard times at different companies. My take away from these messages is that as a manager I have to rely upon myself to make the right things happen. In the end you and you alone are responsible to do the right things. And to do them, pay attention to your people first, your products second, and if you get those two things right the profits can follow. Hire the right people and make sure you make great products.
Ron: I would urge new managers to question their previous strengths—to think of them as tool chests to draw from, but to recognize that what the new job values is something related but very different. It’s not programming. It’s not being technical. Those abilities got you here, but they’re not what will make you successful here. What will make you successful here is applying the key thought from each of the two Nuggets of Wisdom Mickey quoted: “managing” and “people.” Learn everything you can about valuing managing and about valuing the people you’re managing—valuing programmers—as fast as you can.
Matt: Thank you for participating. Where can we go to hear more about your ideas?
Ron: We have pointers to the book and what readers have said about it, to conference talks we'll be giving, and to other interviews and work we've shared, as well as a sample excerpt to download on our author website at www.managingtheunmanageable.net.