Home > Articles > Programming

Managing the Unmanageable: An Interview with Mickey Mantle and Ron Lichty on Managing Programmers

  • Print
  • + Share This
From hiring to tools to culture, building a long-term, successful software group is no trivial task. Matt Heusser interviews Mickey Mantle and Ron Lichty, authors of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams for the secrets to their success—and a few nuggets of insight—about this most challenging of software development tasks.
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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020