I am on the plane on my way to RSA Europe in London and my skill of being able to sleep on any flight seems to have abandoned me. I’ve finished my airplane book (Hundred-Dollar Baby by Robert B Parker) and I can’t bear to watch the animated movie about surfing penguins in Hawaii – and so I have pulled the laptop down from the overhead to log some more musings on why applications are people too.
Applications are people too because…
Process, Technology and Value are to applications as Mind, Body and Spirit are to people. The ultimate goal is to achieve and sustain a perfect balance.
For wellness (process/technology or mind/body), the same mix of preventative, detective, monitoring and treatment strategies must be applied. Finding your way (spiritual/value) requires a view that is bigger than oneself.
It takes village to raise us properly. While it only takes a programmer and a machine to produce an application (like two parents…) – without context, guidance and support from the broader community (product mgmt, sales, etc) – what chance does an application have?
Our strongest characteristics are not inherently strengths or weaknesses – it is the environment or context that makes them so. An outgoing social personality can be someone’s greatest strength or their undoing depending on whether they are in sales or working for the NSA. An application that grabs all available memory to speed its processing is wonderful for a video editor and will create havoc for your background search indexer.
…and with security on my mind for this week’s conference…There are no good guys or bad guys – only supervised and unsupervised (this is an exact quote from a FBI agent that I still recall from a meeting in 1984 when I worked for IBM in their internal security group). The point here is that when you are thinking about security – do not have a double standard – one for the bad guys and one for the good guys – have a consistent approach that includes monitoring, verification and auditing.
Each of these examples just scratch the surface of course – it's the drilling down into these parallels that I think can provide some interesting heuristics that can help make the most of application investments and/or dependencies…
…gotta go, my lasagna bolognaise is coming down the aisle – yum – love that airline food!
Sunday, October 21, 2007
Tuesday, October 16, 2007
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...
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...
- The amount of professional services required to install and configure the application is growing rather than shrinking
- The performance profile of your application is degrading rather than improving
- The ratio between the time between releases is increasing while the number of new features is decreasing
- Assure yourself that the application supplier's direction is aligned with, but not irrationally wed to, the application being proposed
- 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.
Hello world
I spend a lot of time thinking about software – and luckily it’s actually something I like to do. What’s being built out there? Who needs what? Why is this “the next big thing”? What is wrong with these people? …and, I spend a lot of time trying build stuff that has genuine value – which I can loosely define as stuff that changes behavior for the better (people, organizations, whatever). But just how do you move from the aha! moment in the shower to changing the way people work and live?
When most people think genius, they think Einstein. Not to take anything away from The Great One, but I like to fall back on a second class of genius - one inspired, not by Einstein, but by the spirit of Marco Polo. Imagine his wonderment when he first came face to face with Chinese culture -15,000 years of religion, philosophy, science, medicine, fashion, cuisine, etc. Most would have been overwhelmed, but not my imaginary Polo - I envision him thinking, "hmmm, paper money - my friends in Venice could do something with this" or "gee, gunpowder - not just for fireworks." Polo did not invent paper money, understand the principles behind gunpowder, or even appreciate the value that the Chinese placed on them - Polo cherry picked specific artifacts and dramatically increase their value by transferring them across cultures and I would argue that the ability to pluck concepts out of their original context and into new contexts to generate new insights and improved value propositions is truly a special kind of genius. I would also argue that this second class of genius is woefully absent in the commercial software industry.
If this last paragraph was too obtuse – let me summarize it all with a mantra I take with me everywhere – to be effective, your ideas don’t have to be original – they only have to be good.
But what makes an idea “good”? Where is the most fertile ground to harvest these ideas? Without going in to why (at least right now) – my premise is that virtually all interesting and game changing insight ultimately stems from the study of people – how do we interact? how to best manage us in the workplace? how to measure and increase our quality of life? how to teach us to be more self-reliant? etc.
I am not yet entirely comfortable with the blogging format (I am afraid that I will make this read like a column or something) – but for now – I just want to put it out there that if we think of applications as "being people too" – Application Resources instead of Human Resources – we won’t have to be an Einstein to improve both an application's quality of life or longevity – and this will ultimately drive the right kind of adoption of much much “better stuff.”
When most people think genius, they think Einstein. Not to take anything away from The Great One, but I like to fall back on a second class of genius - one inspired, not by Einstein, but by the spirit of Marco Polo. Imagine his wonderment when he first came face to face with Chinese culture -15,000 years of religion, philosophy, science, medicine, fashion, cuisine, etc. Most would have been overwhelmed, but not my imaginary Polo - I envision him thinking, "hmmm, paper money - my friends in Venice could do something with this" or "gee, gunpowder - not just for fireworks." Polo did not invent paper money, understand the principles behind gunpowder, or even appreciate the value that the Chinese placed on them - Polo cherry picked specific artifacts and dramatically increase their value by transferring them across cultures and I would argue that the ability to pluck concepts out of their original context and into new contexts to generate new insights and improved value propositions is truly a special kind of genius. I would also argue that this second class of genius is woefully absent in the commercial software industry.
If this last paragraph was too obtuse – let me summarize it all with a mantra I take with me everywhere – to be effective, your ideas don’t have to be original – they only have to be good.
But what makes an idea “good”? Where is the most fertile ground to harvest these ideas? Without going in to why (at least right now) – my premise is that virtually all interesting and game changing insight ultimately stems from the study of people – how do we interact? how to best manage us in the workplace? how to measure and increase our quality of life? how to teach us to be more self-reliant? etc.
I am not yet entirely comfortable with the blogging format (I am afraid that I will make this read like a column or something) – but for now – I just want to put it out there that if we think of applications as "being people too" – Application Resources instead of Human Resources – we won’t have to be an Einstein to improve both an application's quality of life or longevity – and this will ultimately drive the right kind of adoption of much much “better stuff.”
Subscribe to:
Posts (Atom)