Q&A on the Book Managing the Unmanageable

The book Managing the Unmanageable by Mickey W. Mantle and Ron Lichty provides rules, tools, and insights to manage programmers and teams. It explores how to hire and develop programmers, onboard new hires quickly and successfully, and build and nurture highly effective and productive teams.

InfoQ readers can download an extract from Managing the Unmanageable.

InfoQ interviewed Mickey W. Mantle and Ron Lichty about managing programmers, how to recognize good programmers, getting programmers onboard, managing virtual teams, motivating programmers, protecting staff from disturbances, how a successful programming culture looks, solving impediments, and the role of managers in agile.

InfoQ: What made you decide to write this book?

Mickey Mantle: I’d had this idea for a book about managing programmers, and I even had a title for it: "Managing Programmers Is a Lot Like Herding Cats" (this was long before this became the cliché it is now). But I hadn’t made much progress writing it.

Ron and I had been talking through the challenges of managing programmers over weekend breakfasts for almost a decade already, and we seemed aligned in how we thought about programming and about managing programmers and teams. Plus, he’d already written four books. So at one of those breakfasts, I asked if he would consider writing a book with me.

Ron Lichty: It’s funny. I’d sworn off writing books after co-authoring two popular programming books under tight deadlines that both turned out to be death-march projects. While the knowledge-sharing is very gratifying, coming home from a challenging programming job only to spend every night and every weekend day for more than a year crafting words explaining how to program ...

But my last authoring had been 15 years before, about the time I’d started managing. I’d written about programming to share the insights I’d gained as a programmer. The last couple years, I’d been feeling a similar desire to share the insights I’d gained as a manager, as a director of engineering, and as a VP of engineering .. But it was still just an idea.

Then when Mickey brought up writing a book together ...

Mantle: … we found that we both had worked with an editor at Addison Wesley, Peter Gordon – myself when I managed the process of writing/publishing Pixar’s RenderMan Companion book and Ron had worked with Addison Wesley when he was at Apple and was later introduced to Peter by a tech friend.

Lichty: So we called Peter and discussed the possibility of writing a book about Managing Software People and Teams (and possibly a second book about Leading Technical People and Organizations). He was enthusiastic, so we began working with Peter and Addison Wesley to get the book written. We were both working full-time and I was determined not to burn out this time so it took several years before we completed it, but when we finished it we were both ecstatic with the result.

InfoQ: For whom is this book intended?

Mantle: We actually wrote the book that Ron and I wish we had when we first started managing programmers. We both found that general management books, while useful, really didn’t address the practical day-to-day issues you run into managing programmers and teams.

Lichty: And while there are a ton of general management books (and a ton of software project management books), we could find only a handful of books (in the history of computing!) dedicated to managing software people and teams!

Mantle: We targeted our book at front-line programming managers, designing it to be used in three different ways:

1. You can sit down and read it front to back, as it builds on topics we considered essential to programming managers.
2. You can use it as a reference, accessing it by topic via the thorough Table of Contents or the comprehensive Index, which we’re especially happy with. We tried hard to make sure you can find what you need when faced with a difficult topic or a challenging issue.
3. The book is filled with Rules of Thumb and Nuggets of Wisdom, which we had collected over the years from a wide variety of notable people. They’re not only scattered throughout the chapters to reinforce topics that are being discussed, but we also included over 300 of them, many of which we annotated, grouped by topic, in a separate section in the middle of the book. You can access them by topic or just browse the quotes. It’s great light reading anytime. And they never get old.

Additionally, we collected a variety of Tools that we used in managing our teams and made them available to readers of our book, available for download at Tools for Managing the Unmanageable.

We intended it to be an incredible resource for first-time managers, but also very useful for seasoned programming managers and others who have to interact with programmers and their teams (and who doesn’t these days?). Many readers have also mentioned that though it targets programming managers, any manager would benefit from reading our book.

InfoQ: What makes it so hard to manage programmers?

Mantle: There are several things that make it difficult to manage programmers. Because there are so many programmers who do not have formal computer science or engineering training, there are more diverse "characters" you need to manage than in other technical disciplines. That makes it hard.

Lichty: We all tend to refer to programmers as "engineers." But excelling as a programmer is quite different from excelling as a hardware engineer or a civil engineer or an aeronautical engineer. Exceptional programming is as much art and craft as it is engineering – as much right-brained as left-brained. That makes nurturing programmers much different from nurturing other kinds of engineers.

Mantle: Because software is so abstract, many executives don’t really understand it and have false expectations for how long something will take to be coded. It doesn’t help that most programmers are optimists by nature, and tend to underestimate the work to be done. So as a manager you find yourself managing expectations up, even as you’re managing programmers and teams to actually get the work done. Both are challenging tasks.

Also, one of the things that makes managing programmers harder than other technical disciplines is that the work is "intangible". That is, it’s "thought stuff". You can’t look at it the way you can a printed circuit board and see that you’re making progress. Finding ways to make the software more tangible, and progress more visible, is very important.

InfoQ: What is it that makes a great programmer? How can we recognize them?

Mantle: How do you know a great performer, artist, or athlete? You look at their work and it speaks for itself. If you watch Roger Federer or Rafael Nadal play tennis, the things they do on the court and their preparation and mastery speak for themselves. Similarly, the work of a great programmer will be elegant, with a clear design that is as simple as possible. Great programmers are master craftspeople and demonstrate mastery of the tools, from programming languages to debuggers, and even logic analyzers if necessary to debug complex timing related problems. They will always be on the lookout for the best tools and frameworks to help them do a great job.  

Lichty: I should add that great programmers not only write clear, simple, elegant code, but write code that delights customers.

Mantle: In Managing the Unmanageable, we talk about some of the great programmers we have known, and how their contributions have been foundational for the companies they worked for. We’ve seen it time and time again – great programmers stand above the rest by their clear contributions.

Note, great programmers are often not the most likeable or easy to get along with. They have high standards and don’t suffer fools easily. But provided they’re not out-and-out jerks, the care needed to manage them successfully is usually more than worth the extra effort it takes.

InfoQ: What are your suggestions for getting programmers quickly onboard and productive?

Mantle: We think that this is such an important part of the hiring process that we dedicated Chapter 4 to the topic of getting new programmers started off right. Given you really only get one chance to make a great impression on someone who joins your company, it’s tragic that more attention isn’t devoted to do it well. We emphasize how important it is to keep in touch with the new hire after they’ve accepted your offer until they start. In today’s competitive job market, losing someone who has accepted your offer before they start isn’t uncommon. So you have to make sure they don’t waiver before you actually get them started.

It’s also important to prepare for their first day, making sure that all equipment and office space is set and that any network and server accounts are created and email lists are updated appropriately. These are but a few of the many items on the sample "First-day preparation checklist" we provide as one of the many tools you can download from the book’s website Managing the Unmanageable. We also provide a sample first-day agenda, which we strongly suggest you customize and hand to your new employee when you greet them when they walk in the door. This agenda provides a schedule with meeting topics and names of the people whom they will meet with during the day.

We also recommend you assign a "buddy" to help answer any questions, make introductions, show them around, and take them to lunch (on the company of course).

An important part of introductions is having the manager send out an email introduction to the company (or department, as appropriate) welcoming the new hire, introducing them, and including a personal note of self-introduction from the new employee. A sample introduction is included as one of the tools that can be downloaded.

To ensure their success, a manager must also continue the process of integrating the new hire into their team in the following days and weeks after they start.

Lichty: Those are just a few of a ton of suggestions from our chapter on getting programmers started off right.

I think it’s worth saying a few words about why onboarding effectively is important. I think if we did a poll right now, we’d find that 95% of managers would say effective onboarding is important. And yet…

I’m also a co-author of the periodic Study of Product Team Performance, in which we survey product team members all over the world about the performance of their teams and look for the practices that correlate with performance. Let me share two stunning insights. The first Study we ran in fact identified effective onboarding as one of five practices that correlated with the highest performance teams.

That result led us to ask, the next year, if respondents would characterize their onboarding as a best practice. Only 4% said their organizations onboarded product team members well enough to claim best practice!

Despite our thinking, it’s important that most organizations apply a sink-or-swim approach to bringing new members onto their teams!

Based on our own experience, Mickey and I considered onboarding so important that, as we developed the outline for Managing the Unmanageable, we realized we needed not only to devote a chapter to recruiting and hiring, but one to onboarding, or as we put it in the chapter title, "Getting New Programmers Started Off Right."

Many readers have told us that it's one of the most valuable chapters in the book - in part, because it's a topic so seldomly addressed.

Mantle: This is important not only for programmers – but for every new employee you hire, regardless of their position in your company. Get them started off right the first day. Make great onboarding a key part of any hiring plan!

InfoQ: What's your advice for managing virtual teams?

Mantle: Managing virtual teams has become easier with high-bandwidth access that provides (effectively) the same access to code, tools, etc. However, even with Skype and Zoom and other great video conferencing services - plus Slack and other instant communication tools - there still is no substitute for having a co-located team to be most effective. So my advice is to avoid virtual teams, if at all possible, but if you can’t, be prepared to work hard to make the virtual teams effective.

You also should budget for travel to bring the teams together, ideally at least quarterly. There is no substitute for being eye-to-eye with someone else. Body language and subtle clues often contribute more to communication than the words.

Lichty: I think it’s a testament to how hard it is to manage virtual teams that of the 300 rules of thumb and nuggets of wisdom we collected in the center section of Managing the Unmanageable, a substantial number offer tips and techniques to address the challenges of managing virtual teams of every kind. Managing virtual teams is a challenge that we all need as much help as we can get.

InfoQ: What are the factors that motivate programmers?

Lichty: One of my early "aha" moments as a manager was reading a reprinted Harvard Business Review article One More Time: How Do You Motivate Employees? by Frederick Herzberg. In it, Herzberg posited that we need to consider two lists of motivational factors: while there are factors that motivate, there’s a parallel list of factors that de-motivate, factors like unethical management, unfair compensation, insane company politics, and [drumroll] lack of respect for one’s boss. Attempting to motivate will be pretty ineffectual until the de-motivators are handled.

Herzberg’s article is well worth a read, even today – written in 1968, it’s the most reprinted HBR article ever – millions of copies sold! Summarizing Herzberg’s points in a couple pages in Managing the Unmanageable, we went one step further. While Herzberg was addressing people working in all sorts of jobs, given the uniqueness of managing programmers we made a few refinements to the lists based on our experience. You can decide, but we believe – provided programmers respect their supervisor, can have fun on the job, experience learning and growing and good working conditions in a company that has sane policies and ethical management, and feel fairly compensated – that programmers are motivated by the opportunity to make a difference/make an impact, followed by opportunities to learn and grow, play with toys and technology, experience recognition and praise for jobs well done, and have fun. Only then do they tend to be motivated by additional monetary upside.

I should point out that Herzberg is one of three thought leaders who addresses motivation, and to whom we devote a few pages each, before we explore the motivational and demotivational factors specific to software people and teams.

Mantle: Following Herzberg’s lead, we revised his list of demotivators and motivators to match our experience in managing programmers. But the key idea that there are demotivators that must be addressed before you can begin to motivate has been a hallmark of our managing styles over the years.  We devoted all of Chapter 7 to the topic of Motivating Programmers.

InfoQ: What can managers do to protect their staff from organizational disturbances?

Mantle: Good managers must work hard to protect their people from the torrent of problems, issues, and "opportunities" that wash over their organizations on a daily basis. They may be the only defense against the flood of sales-driven opportunities, customer-driven issues, and management-driven ideas that challenge your teams.

To be productive, a programming team must be buffered from the flood. A manager must take charge – understanding, evaluating, discussing, negotiating, deferring, documenting, and finally agreeing to or refusing to deal with these issues.

Lichty: On a slightly different note, we’ve both found it helpful, managing in various places, to devote a few minutes in staff meetings to rumor-sharing. We ask our staff, "What are you hearing?" In some environments more than others, particularly ones where rumors are rife, getting them out on the table lets us address them directly (and sometimes gives us a heads-up to disturbances about which we were unaware!).

InfoQ: How does a successful programming culture look?

Lichty: This is a question that initially seems hard, but ask the question slightly differently, and virtually every member of a programming team with much tenure – and so that includes virtually all managers – can come up with good answers.

The question? "Think about the best team you’ve ever been part of, and write down a few words that describe what characterized it as the best team you’ve been part of."

Mantle: We suggest you first understand your company’s culture and then try to either leverage the best parts of the company culture or attempt to wall off the company culture and create your own successful programming culture. Among the key aspects of such a culture are mutual respect, innovation, standards, delivery, communication, fairness, empowerment, professionalism, excellence, passion, collaboration, learning, and customer focus.

InfoQ: How can managers support teams when it comes to solving impediments?

Mantle: A manager’s job is to be "delegated" problems and issues by their team, be they resources, communications, unknowns, need for clarifications, etc. This is one of the most important parts of being a good manager!

Lichty: Ask any set of agilists who removes impediments and you’re likely to hear a single answer in unison: Scrum masters. But then ask who they escalate to, and you’ll also almost universally hear a single answer: managers. It turns out managers are uniquely positioned, organizationally, in most organizations, to solve the gnarliest impediment problems.

InfoQ: What role do managers have in organizations that adopt agile? What should they do and what should they stop doing?

Lichty: Answering that question is one of the reasons that Addison Wesley wanted a 2nd Edition to our book – it’s a question that a lot of managers have been stumped by, understandably. Agile adoption tends to focus on teams.

We added an entire chapter to answer the question, starting with what to stop doing from a pure agile standpoint – as well as what to start doing (and what to continue doing!).

If managers are working in a company that has truly embraced agile, managers’ reports are now scattered across self-organizing feature teams that have been reorganized cross-functionally to own delivery of customer-delighting features.

Managers are no longer responsible for delivery, but rather for setting standards and expectations and equally for creating a culture that supports and enables self-organization and the trust and respect and psychological safety within and across teams that makes self-organization and proactive teamwork flourish.

With a staff of technologists who share an area of expertise but are scattered across teams, managers need to bring them together for the purpose of growing the expertise within their technology domain as well as sharing learnings and practices. Managers need to create forums for team-building as well as individually growing and mentoring the skillsets and the careers of each of their reports.

With teams empowered with the responsibility for delivery, former manager responsibilities like load-balancing developer tasks and maintaining project schedules go away, freeing managers to take on not only greater roles in leading their part of the organization’s technical growth, and setting standards and expectations for that growth, but also to reach upward and outward to help the rest of the organization to understand the intricacies of agile and to help them to become supportive in useful ways.

And managers continue to be responsible for traditional responsibilities like taking point on hiring activities, handling employees and employee issues that teams and the organization find difficult, and being significant points of escalation for rapid-fire impediment removal.

About the Book Authors

Mickey W. Mantle has been developing software for over 50 years, creating hardware and software products and managing development teams. Mantle’s experience includes directing R&D teams around the world and managing multidisciplinary teams working 24/7 to deliver many landmark software products like Pixar RenderMan, and Gracenote music recognition. He currently runs Wanderful, an animated children’s books company that publishes apps for iOS, Android, macOS, and Windows, and writes, speaks, and consults on leadership, management, and software development practices.

Ron Lichty has been managing software development and product organizations for 30 years at companies like Apple Computer, Fujitsu, Charles Schwab, Avenue A | Razorfish, Forensic Logic, Stanford, Check Point, and startups of all sizes, primarily focused on untangling the knots in software development and transforming chaos to clarity. Eight years ago, he pivoted to take on fractional Interim VP Engineering roles, train teams and executives in making their agile more effective, mentor engineering leaders, and coach leaders and teams to make their software development "hum". Lichty also co-authors the periodic Study of Product Team Performance.