Uniqueness and coincidensity
Coincidensity – a really nice neologism that I first saw in a Tweet by social-business specialist David Cushman:
- davidcushman: RT @stoweboyd: the right word isn’t serendipity, it’s coincidensity: the likelihood of serendipity
- jonhusband: @tetradian @davidcushman @stoweboyd … I much enjoy the #neologism coincidensity .. bravo !
From the Tweet, I’d assumed that the term had come from Stowe Boyd: but being the gentleman that he is, he was quick to assign the credit elsewhere:
- stoweboyd: Coincidensity was coined by Matt Biddulph, though. I’m just a user/thief @jonhusband @tetradian @davidcushman
The link between serendipitous ‘coincidences’ and innovation has a very long history. For example, one of my favourite books, Beveridge’s The Art of Scientific Investigation, includes a whole chapter on the role of chance in science, and points outs that it’s nothing like as ‘random’ as it might seem:
If these discoveries were made by chance or accident alone, as many discoveries of this type would be made by any inexperienced scientist starting to dabble in research as by Bernard or Pasteur. The truth of the matter lies in Pasteur’s famous saying: “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance observation which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.
For me, in enterprise-architecture, two distinct themes come to mind from this.
One is the crucial role of uniqueness: the ‘one-off’ that stands out just enough to make itself distinct and noticeable – much as in Common Ground‘s concept of ‘particularity’ or local distinctiveness – yet is also in some way useful. I’ve explored uniqueness in enterprise-architecture from quite a few different directions over the past few years, so I’ll just mention again that it’s important, and that we need to take note of it, and leave it at that for now.
The other theme is about how, in an architecture, we can design for coincidensity – or design against it. Coincidensity can indeed be left to chance: but exactly as in that quote of Pasteur’s, “chance favours the prepared mind” – or, in this case, the prepared architecture.
So, for example, in a high-innovation environment, we can design for high coincidensity. In a physical building, we can ensure that the natural pathways encourage ‘accidental’ meeting between disparate groups. In social networks, this is a key part of the role of the ‘super-node’, he brings together people in ‘unexpected’, seemingly-serendipitous ways. We can do much the same in virtual-spaces, either by structures that are designed to create ‘accidental’ cross-connections between different groups, or through simple ‘randomisers’ such as Google‘s archetypal ‘I’m feeling lucky’ button.
And in some cases, where we need to break out of too-entrained thinking, we might even sort-of trick people into a high coincidensity of ideas, using a flood of deliberate mismatch and cognitive-dissonance – much as described in Raymond F Jones‘ classic science-fiction short-story Noise Level. Some aspects of the context-space mapping sensemaking-methodology, of which SCAN is a simplified version, are structured to support that kind of intentional not-quite-mismatch.
We can also design to reduce the coincidensity of a context. That’s not as strange as it might sound, because random variation or random interruption is the one thing we don’t want in a high-control or high-repeatability context. We want some types of business-processes to be as predictable as possible: for example, to put it the other way round, we probably don’t want strange surprises in our lunchtime salad.
Some low-coincidensity contexts are rather less pleasant: the design of a high-security prison, for example, will aim to minimise uncontrolled or unplanned connections between individual prisoners. One of the fundamentals of 18th-19th large-house design in Britain and elsewhere was the notion of the ‘invisible servant’, that the house should be structured to prevent – or at least minimise – any contact between servants and owners: house-plans show hidden passageways and stairways and service-areas that servants and maintenance-staff would be required to use, to scurry literally between the walls without being seen or heard. And some present-day executives are infamous for enforcing complete separation between themselves and their staff, hiding away in the top-floor suite – and then expressing surprise when the business fails because the structure had ‘successfully’ blocked out key information that they needed to know. 😐
So coincidensity is a design-choice: we can design for high-coincidensity, low-coincidensity, or anywhere in between. (Or we can just ignore it and hope for the best – which is rarely a good design-strategy…) To do this in enterprise-architecture and the like:
- identify the types and levels of coincidensities that we need
- identify tactics and design-features that will support the required coincidensities
- work with others to develop and implement the required features
I’ve summarised some example-tactics above, though there are plenty more, of course: it’s up to us what we do, really. The key point is to recognise the principle of coincidensity – its nature as the density of ‘unplanned-for coincidences’ in any form – and design our structures to promote or dissuade such coincidences according to the need.
Again, will leave it there for now, though do let me know if you want me to explore this further here.
As usual, comments or suggestions, anyone?