3 ms·

Why do you think that 'the establishment' is so hard to innovate within?

by Simorgh 11y ago

eries 11y ago
It's actually very simple: most established organizations adopt processes designed to eradicate innovation. If you study management history it's pretty easy to see why they did this, since there were huge gains in the 20th century to be had by eliminating variability in both manufacturing and human resources. Consistency, standardization, and commodification all paid huge dividends. Unfortunately, not all sources of variability are bad. Think about the antibiotic craze as an analogy. It was a major discovery that bacteria cause disease. But it was also a major discovery that certain bacteria are beneficial. Loading up your system with antibiotics 24/7 is actually detrimental to long-term health, even though it's awfully helpful during an appendectomy.
- boomzilla 11y ago
  Is it the same as the 'Agile' approach that is so prevalent in software industry these days that aims to deliver software reliably on time? How do you differentiate good variability from bad ones in software development?
  - eries 11y ago
    Now _that_ is a good question. Most agile systems are designed to insulate management from the volatility inherent in software development (and to tamp it down a little bit). They aren't really designed to exploit the positive variability. Here's a classic example: let's say I have a story card that says "build a feature that lets 10000 customers buy a widget from our store." In most classic agile systems, the engineering team will do their best to understand the customer requirement and see that it's built appropriately. Now let's say that 0 customers show and buy the widget. Who's fault is this? In traditional agile, it's the Product Owner's fault, not the engineering team. But exploiting positive variability would say: the effort required to build this feature requires knowing in advance how many customers want to buy the widget. The engineering effort is totally different if the answer is 0, 10, 100, 10000, or 1000000 customers. So rather than build the feature as specified, let's do an experiment to try and assess customer demand first, then build in response to that demand. That means that sometimes a story will take 10X longer than you originally planned and sometimes it will take 1/10th as long. But in the end, you'll get a better business result. That's positive variability.

Why do you think that 'the establishment' is so hard to innovate within?

by Simorgh 11y ago

Why do you think that 'the establishment' is so hard to innovate within?

eries 11y ago

It's actually very simple: most established organizations adopt processes designed to eradicate innovation. If you study management history it's pretty easy to see why they did this, since there were huge gains in the 20th century to be had by eliminating variability in both manufacturing and human resources. Consistency, standardization, and commodification all paid huge dividends. Unfortunately, not all sources of variability are bad. Think about the antibiotic craze as an analogy. It was a major discovery that bacteria cause disease. But it was also a major discovery that certain bacteria are beneficial. Loading up your system with antibiotics 24/7 is actually detrimental to long-term health, even though it's awfully helpful during an appendectomy.

boomzilla 11y ago
Is it the same as the 'Agile' approach that is so prevalent in software industry these days that aims to deliver software reliably on time? How do you differentiate good variability from bad ones in software development?
- eries 11y ago
  Now _that_ is a good question. Most agile systems are designed to insulate management from the volatility inherent in software development (and to tamp it down a little bit). They aren't really designed to exploit the positive variability. Here's a classic example: let's say I have a story card that says "build a feature that lets 10000 customers buy a widget from our store." In most classic agile systems, the engineering team will do their best to understand the customer requirement and see that it's built appropriately. Now let's say that 0 customers show and buy the widget. Who's fault is this? In traditional agile, it's the Product Owner's fault, not the engineering team. But exploiting positive variability would say: the effort required to build this feature requires knowing in advance how many customers want to buy the widget. The engineering effort is totally different if the answer is 0, 10, 100, 10000, or 1000000 customers. So rather than build the feature as specified, let's do an experiment to try and assess customer demand first, then build in response to that demand. That means that sometimes a story will take 10X longer than you originally planned and sometimes it will take 1/10th as long. But in the end, you'll get a better business result. That's positive variability.