Here's a quick example - the Peter Principle

The Peter Principle

Many of you will be familiar with The Peter Principle. The Peter Principle reads:

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

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.

My 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 of the company (which is ultimately the same ending as with the original Peter Principle).

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 and/or custom code 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, 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.

My 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. For example, I would argue that 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.

My 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 (or some other management construct - can you say "hedgehog"?) 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? There are lots of signs, but two yardsticks that have worked for me in the past sound something like this...

You know your application has been promoted beyond its competence when...

1. The amount of professional services required to install and configure the application is growing rather than shrinking
2. The performance profile of your application is degrading rather than improving
3. The ratio between the time between releases is increasing while the number of new features is decreasing

This approach can be extended to application consumers as well - just like you would want to see resumes for consultants assigned to a mission critical project - I would recommend the following be included in an application selection process (in addition to basic functional requirements of course):

1. Assure yourself that the application supplier's direction is aligned with, but not irrationally wed to, the application being proposed
2. Recall the Peter Principle for applications - success is not necessarily transitive. Check references like you would a prospective employee - don't just ask about their satisfaction - verify skills and organizational fit.

I have to confess that in my rush to get at least one post out - i borrowed heavily from an earlier column I had authored for The Gilbane Report way back in 2002. The material here is fundimentally different, but if I had not been the original author - this would have qualified as plagerism.

I have not contributed to the site for sometime - but it is an awesome site - check it out at http://www.gilbane.com/. My old columns can be found at http://gilbane.com/columns.pl.