When we think about and plan our KM activities, it can be tempting to imagine a marvellous future wherein all our firm’s know-how is carefully nurtured, categorised, exposed for all to see, tagged, analysed, or whatever it is we think would be the best outcome. However, as the Bard of Ayrshire put it: “The best laid schemes o’ mice an’ men/ Gang aft agley.” Why is this?
One good reason is pointed out in Gall’s Law:
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
I am indebted to John Gruber for the pointer to this formulation. He uses it to explain how to understand Apple’s strategy with regard to the iPhone.
If there’s a formula to Apple’s success over the past 10 years, that’s it. Start with something simple and build it, grow it, improve it, steadily over time. Evolve it.
The iPhone exemplifies this strategy. There’s a long list of features many experts and pundits claimed the original 1.0 iPhone needed but lacked. Ends up it didn’t need any of them. Nice to have is not the same thing as necessary. But things the iPhone did have, which other phones lacked, truly were necessary in terms of providing the sort of great leap forward in the overall experience that Apple was shooting for.
At this point, it is worth noting an essential qualifier to Gall’s Law: “A simple system may or may not work.” In the case of the iPhone it clearly did work. In other cases, Apple decided that it did not work.
What Gruber brings over and above a simple assertion of Gall’s Law is an insight about how to choose the original simple system: “It’s not enough just to start simple, you have to start simple with a framework designed for future evolution and growth.” When the iPhone was first launched, it was not particularly full-featured as a phone: it was not 3G; it did not support MMS. It even fell short on the music front, as it cost significantly more per gigabyte than any of the iPod range. However, as Gruber points out:
Apple started instead with the idea of a general-purpose pocket-sized networked computer. It no more has a single main purpose than a desktop PC has a single main purpose. Telephony is simply one feature among many, whereas on most other phones, the features are attached to the side of the telephone. They sold 30 million iPhone OS devices in the first 18 months after 29 June 2007, but 13 million of those were non-phone iPod Touches — proving that the platform is clearly appealing even when the “phone” is entirely removed. (Consider too that the iPhone’s two strongest competitors are BlackBerry and Android, neither of which started as phones.)
The iPhone was not conceived merely as a single device or a one-time creation. It’s a platform. A framework engineered for the long-run. The iPhone didn’t and doesn’t need MMS or a better camera or a video camera or more storage or cut/copy/paste or GPS mapping or note syncing, because the framework was in place so that Apple could add these things, and much more, later — either through software updates or through new hardware designs. The way to build a complex device with all the features you want is not to start by trying to build a device with all those features, but rather to start with the fundamentals, and then iterate and evolve.
We should learn the same lesson with our knowledge systems. Not to try and predict all the features that might be useful in the future — that way lies excessive complexity coupled with early obsolescence and failure. Instead we should imagine and create the best platform for future possibilities — as simple as possible, but as open to development as necessary.