Tribal Knowledge - Thomas Watson Sr., The Peter Principle, and Sebastian's Corollary

Thomas Watson, Sr.

Some of you youngsters may find this hard to believe, but in prehistory (before the Internet), IBM was not only king of the technology mountain - they were heralded as the archetypal American business. This was due in large part to their financial success, but also to their near-mythic founder, Thomas Watson, Sr.

Mr. Watson took great pains to document and evangelize a code of business ethics and practices that he swore were the secret to IBM's incomparable success. With the bubble come and gone, some of his early credos are worth revisiting. For example, IBM had (has?) 3 basic beliefs, which, it is important to note, make no mention of computers or technology. Further, he stressed that every company - no matter what the industry - must have its own set of basic beliefs, and that a company must be prepared to change anything and everything other than these basic beliefs (for a nice collection of these basic beliefs, see www-1.ibm.com/ibm/history/documents/pdf/management.pdf)

The essence of this particular principle is that companies should not become wedded to their products - in fact, just the opposite. Companies should take every precaution to ensure that they do not hook their wagon too closely with a particular product or even a specific line of business. Needless to say, along with every other mistake possible, very few hi tech firms have put this very basic principle into practice.

The Peter Principle

I am sure many readers are familiar with The Peter Principle. The Peter Principle reads:

In a hierarchy every employee tends to rise to his (or her) level of incompetence.

What does this have to do with Thomas Watson, Sr., enterprise software, or tribal knowledge? I thought you'd never ask.

Software companies package, promote and sell their products in the same way they promote their employees - to their level of incompetence! This is, by no small coincidence, the direct result of becoming too wedded to product lines.

Sebastian's Corollary

In enterprise software markets, every vendor tends to market and license its existing products to their level of incompetence.

Of course, product incompetence manifests itself differently than the human kind. It starts out with reduced customer satisfaction, longer sales cycles, increased cost of sale, slimmer margins, and ultimately acquisition or liquidation.

The Peter Principle has many of its own corollaries, all of which have analogs in the enterprise software world.

Case One:

Peter Principle: According to Dr. Peter Drucker, work is accomplished by those employees who have not reached their level of incompetence. Thus organizations are able to function even as the Peter Principle causes some employees to accept one too many promotions.

Sebastian's Corollary: New revenue is generated primarily by lookalike customers, new products, custom code and workflow work arounds rather than the expansion of existing products into new markets. This does not prevent corporations from pushing outwards from core successes into new markets. In fact, the marketing guru, Geoffrey A. Moore calls this the "Bowling Pin" strategy and it is an essential step in "Crossing the Chasm." In other words, from a hi tech marketing perspective, it is an imperative to carefully push a product to increasingly broad applications.

Case Two:

Peter Principle: Employees, as Dr. Drucker points out, do not want to be incompetent, but when management offers promotions that put the employees into their level of incompetence, the employees have no way of knowing that ahead of time. After all, if the offer is made it is because management knows the employee can do the job competently.

Sebastian's Corollary: In today's economy, with the IT market flat and the expectations set back in the late 90's long since abandoned, the few successful product lines (and the product managers that shepherd them) are under increasing pressure to milk the cash cow to the very last drop. They can rationalize this because they have no way of knowing for sure that the technology has reached its level of incompetence (this is how document management became web content management became content management became enterprise content management!).

Case Three:

Peter Principle: If struggling with incompetence is a way of learning, then from an organizational or a personal standpoint, it's just a matter of equilibrium between learning and performing. Struggling with outright debilitating incompetence is not the best environment for learning. Getting just the right degree out of a comfort zone to promote growth while avoiding incompetence is the ideal.

Sebastian's Corollary: Applying existing technology into new solutions should create the same kind of tension and calls for the same kind of equilibrium. The tension is between the marketing imperative to drive toward the bowling pin strategy and the suitability of a given product for a new or revised application. How can you tell if you have pushed a product too far?

A few yardsticks include:

• If the professional services required to install and configure the product is greater than 3X the cost of the software.
• If the performance profile of the new applications is <70% of its historical performance.
• If the adoption rate of <80% of its historical norm.

In summary, I would recommend the following essential ingredients be included in any vendor selection process: Assure yourself that their corporate direction is aligned with, but not irrationally wed to, the product they are proposing. Success is not necessarily transitive. Just because a product or company has done well with once class of solution does not mean that the very same technology might not fail miserably in a new application. Figure out your own basic beliefs, be true to them and be prepared to change anything and everything but those basic beliefs.

Next month we will have more fun at your vendor's expense. Coming soon - Meaningful Ambiguity: Reading Corporate Press Releases 101

Care to share some of your tribal knowledge? We'd love to hear it - send comments and insights to sebastian@gilbane.com