Dave Snowden


RSS Feed

In 1943, an Engineer, Percy Spencer was building a magnetron when he noticed a candy/chocolate bar melt in his pocket.  He realised the connection and placed an egg in a kettle and directed the microwaves from the magnetron into a hole cut in the side of a kettle.  The egg exploded, but we had the first microwave.  Raytheon filed the patent in 1945 and made a fortune,  Percy as an employee got a $2 token payment; by the time I got my first patent in IBM it was $150 but same difference!

Now that story is a classic example of exaptation, something that started to be a significant part of my work post September 2009 after a conference in Italy. Although the early knowledge management articles make a difference between incremental and eureka innovation, so the basics were there, if not the language and the background science.   I described that conference in a series of posts that, in the main commence with the menu for the day; we were after all in Italy.  The first of those is here, and a search on the word will find a fair number of blog posts, at east one of which uses the same example.   Brian Arthur also uses it in The Nature of Technology where he talks about  the need to pay attention to the modularity of technology before exaptation is possible.  Its only when we have a magnetron that we can get the connections happening that are key to the innovation process.   Just for the record he does''t use the exaptation work extensively but its what he is talking about in terms of innovation. The whole radar is too big (or chunked in my terms); it has too much purpose for exaptation.  The cathodes and anode blocks, on the other hand would have too finely grained, too fragmented.

Getting the granularity right is key, and its one of my three heuristics of complex system management: use finely grained objects. Although I should maybe add the qualification, but not too finely grained.  In most presentations, I talk about organisational units (law of 5-15-150) and information units (micro-narratives), but it also applies to problem definition and solutions.  There is a lot of work still to do here both in theory and practice to work out what level of granularity works for different purposes.

I'm starting to think about a large group strategy event this Thursday where we need to get out specific actions at the end of the day.  A large part of that will be to get the problems defined in a manageable way.  No broad sweeping abstract ones will be allowed!  The whole idea is small, tangible, intractable maybe, but not impossible.  I'm reworking the actions forms ready for that event and also creating some heuristics.  I will post on that later in the week so consider this as a place holder, setting the context for what will come later.   Mind you I would be interested in any examples people have either through comments or email.