I thought this blog entry was worth "retweeting" here:

Here's a scenario worth considering:
Let’s say you’re a mid-level executive. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers.
and also an interesting comparison between a large company and a start-up:
Large organizations generally aim to “get it right” from the get-go — an unreasonable requirement that leads to fear, posturing and endless delays. Startups, on the other hand, are just trying to get it right before they run out of money.
Read more... http://gigaom.com/2009/08/30/the-power-of-continuous-improvement/

Great article. Thanks for sharing, Le Chiffre.

"Continuous improvement" in management is analogous to "agile development" in software and "evolution" in nature. Make small adaptive changes and eventually, but sooner than you'd expect, the system is noticeably better.

I thought this blog entry was worth "retweeting" here:

Here's a scenario worth considering:Let’s say you’re a mid-level executive. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers.and also an interesting comparison between a large company and a start-up:Large organizations generally aim to “get it right” from the get-go — an unreasonable requirement that leads to fear, posturing and endless delays. Startups, on the other hand, are just trying to get it right before they run out of money.Read more... http://gigaom.com/2009/08/30/the-power-of-continuous-improvement/

I read the article twice and still don't know what point the author was trying to make, other than "feedback is good."

The author says,
...in business you often find people who have been doing something for a long time and just aren’t very good at it. Why? Lack of feedback. There's an erroneous assumption here that incompetence is always curable. In many cases, the Peter Principle is at work and a person has been promoted into a position where competence probably isn't possible. The main problem in those cases isn't lack of feedback; it's that the people who promote individuals into positions of incompetence are loath to admit the mistake (or incorrect judgment) and the new incumbent is allowed to thrive in making things worse.
The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.Well, duh.
Large organizations generally aim to “get it right” from the get-go — an unreasonable requirement that leads to fear, posturing and endless delays. Startups, on the other hand, are just trying to get it right before they run out of money.The author believes that attempting to "'get it right' from the get-go" is a bad idea, and that such a strategy will lead to bad things, including not getting it right, presumably. Startups, on the other hand, try to get it right while the money lasts, and their haste is more likely to result in getting it right from the get-go. What? This article doesn't make sense on any level.

I read the article twice and still don't know what point the author was trying to make, other than "feedback is good."

Jim,

The point of the article is that successful continuous improvement in a system depends on frequent, small changes, instead of infrequent large ones. The author states "The more granular and frequent the improvements, the better."

In my experience, this point is far from obvious. Many folks and organizations set overly ambitious goals for development projects only to miss deadlines, overrun costs and otherwise fail.

With "agile development", "continuous improvement", or "Climbing Mount Improbable" a tight and efficient "feedback loop", "CAPA cycle", or "natural selection" produces a better result than large, discontinuous attempts at improvement.

A QMS is a great example of a system ideally suited for frequent and granular tweaking. The more accessible the documentation is to the users/editors, the better it will get. The more empowered your user/editors are in making small improvements to your QMS, the better it will get too.

The author of the article observed agile development in startups, and used that to illustrate his point. Been there, and it is a good example indeed.