Author: JP

• Markets are conversations, as per Cluetrain.
• Markets contain risk.
• Conversations can help you manage that risk.
• Social software can help you extract what you need from those conversations and thereby help you manage the risk.

I was reading the latest issue of Risk and Regulation, published by the Centre for Analysis of Risk and Regulation (CARR) at the London School of Economics and Political Science (LSE). I’ve read the publication ever since I had lunch with Michael Power, the author of The Risk Management of Everything. If you haven’t read that pamphlet yet, I can do no more than recommend as strongly as possible that you do. It is as fundamental to Four Pillars as Cluetrain and Social Life of Information and Emergence.

An aside: Here’s the description of Risk Management of Everything:

We live in the age of the risk management of everything. Paradoxically this still leaves organisations that diligently engage in risk management exposed to what Donald Rumsfeld called ‘unknown unknowns’ which, by definition, are out of reach of risk management.

This warning about the escalation of the risk management of everything should be taken seriously. In his first Demos book, The Audit Explosion, Michael Power warned against that companies and governments preoccupation with measuring what is measurable – the now discredited ‘targets culture’.

Power traces the start of the risk management of everything back to 1995 – the year of the collapse Barings bank Shell’s Brent Spar PR disaster. Those events illustrated the two key aspects of the new obsession with risk management: internal control and reputation.

The ability of a rogue trader to bring down a bank has prompted organisations to redouble their efforts to use internal control systems to manage risk. But the danger is that the focus on internal controls to manage risks of ‘known unknowns’ leaves organisations vulnerable to ‘unknown unknowns’.

“Reputation has become a new source of anxiety where organisational identity and economic survival are at stake And if everything may impact on organisational reputation, then reputational risk management demands the risk management of everything.”

The anxiety about reputation means that experts and professional bodies are increasingly taking defensive steps to protect their own name, rather than managing risks on behalf of the public. One example of this the proliferation of ‘small print’ as professionals ranging from doctors to accountants attempt to hand risk back to customers, clients or society as a whole.

Now if that doesn’t get you to read the pamphlet, nothing else will. I will explain later why this is fundamental to Four Pillars.

Back to the magazine. As usual, there were a number of thought-provoking articles. All its authors should blog. Are you listening, LSE?

One of them, titled Harnessing Hindsight, looks at how, for example, near-miss incident reports are used to improve risk management in aviation.

I quote from the conclusion to the article:

What implications does this examination of practice hold for current theory? First, it suggests that current models of risk management, and methods of risk analysis, could be productively extended by more fully attending to the ‘positive’ face of operational risk – the organizational practices and social processes that underpin organisational resilience – so moving beyond the current focus on predicting and avoiding failures, errors and harm. Second, it emphasises the central place of knowledge – and its dark side, ignorance – in dealing with risk. Assessing small moments of operational failure is an interpretive process that draws on forms of knowledge that are not readily quantified or formalised, such as the particulars, specifics and details garnered from practical operational experience, or vicarious knowledge of similar events experienced by other organisations. And identifying signs of ignorance, in the form of suspicions that arise from subtle relations and mismatches between current knowledge and organisational events, equally appears to offer a useful proxy for identifying latent risks. Third, it points to the importance of institutional designs that balance the tensions between central oversight and local participation and action, and that establish organisational spaces for collective enquiry and sensemaking around risk events.

Emphases mine. I couldn’t have written a better rationale for the use of social software in risk management. Collective enquiry and sensemaking around risk events.

More later on this theme. Do read the article, even if you have zero interest in aviation. Consider how powerful social software and emergence and P2P models are in this context.

Part of the reason I blog is to improve my understanding of things, even change my opinion as and when I have reason to. This I cannot do unless I read blogs of people whose views are somewhat different from mine, natural selection applied to opensource thought.
Which is why I read Agile Management‘s comments on one of my posts with interest. David Anderson works for Microsoft and holds patents in the internet and telco spaces. So I could be pretty sure his DNA and mine would be somewhat different :-)
So I read. And learned. And I was enjoying it.
Until I saw this:

Confused of Calcutta suggests that commodity features should always be developed as open source projects.
Again at Microsoft we wouldn’t completely agree with this. [And then this] Often open source projects are created as “spoilers” to spoil a profitable market for someone else.

Oh puh-leese. Does he really believe that? Does anyone? Is there something they put in the water (or some other shared utility) to make people think like that?
Opensource is not anticapitalist. It is anti-loss-of-freedom and anti-wasting-money-and-effort and anti-unnecessarily-sometimes-unfairly-constrained markets.

David says “spoiling”.

I say “disrupting”.

Big difference.

In my last post I mentioned how much I enjoyed reading what he had to say. I now find he has a blog as well, to be found here. A taster, taken from this post entitled Surprising Findings On Software Reuse:

Kevin DeSouza and his colleagues in a recent article in the Communications of the ACM published some surprising findings regarding software reuse: reuse happens more by novices rather than by experts, within projects rather than across them, and in transient teams rather than permanent ones. The statement regarding the higher propensity of rookies to reuse compared to older professionals rang particularly true to my ears.

…………………………………

I was surprised when Markos finished the project I considered a tarpit in record time and with resounding success. What he did was to follow a piece of advice I wrote in Code Reading and also give in my classes, but did not follow myself: when reuse at one level of granularity (method, class, package, system) fails, try to reuse at the next higher level.

I feel a need to link coming…..

A prefatory note: I am not ashamed of being called Utopian.

When I started full-time “work” nearly thirty years ago, straight out of university, I had no idea what to expect. So I imagined that work was a natural extension of university. And for me, university was a natural extension of school: I attended a Jesuit collegiate school, a model where you could stay with one institution from the age of five until you completed your first degree: primary school, secondary school and college were all on the same campus, and you moved around the quadrangles for sixteen years. It was a wonderful experience.

I continued to be blessed, and worked for some great companies. Burroughs in the early 1980s was a magical place to be. So, by the time I was 25, I felt I understood what a firm does, what a firm could be. And in my heart of hearts, I felt that every great firm should be modelled on a great university.

Why? Let me try and articulate the reasons:

• University is about results and outcomes and empowerment; about personal responsibility and empowerment; about discovering things and developing talent and potential; about fitting into society and working in groups and communities; about doing the right thing and not cheating; about realising that there is no substitute for hard work.
• University is about experimentation and about imitation; about access to historical research and the creation of original research; about personal accountability and the willingness to accept the consequences of your actions; about conversations and discussions almost independent of time and space; about long days and long nights and laughter and tears and successes and failures. And you celebrated them all, because you took what you did seriously, but you never took yourself seriously.
• University is about the selection and building of values and ethics and mores and norms, about peer pressure, about leading and being led, about respect for authority tempered with passion and curiosity, about discovering new ways of doing things. Some worked, some didn’t. A place where errors and mistakes were seen as opportunities to adapt and improve.
• University is about periods of almost-torpor and periods of intense activity, about solving problems, about creating new problems in order to find new ways of problem-solving.
• University is about no carrot and no stick, about people doing things because they are motivated and challenged; about small-group cellular interactions and occasional large congregations, not the other way around; university is about conversations and relationships and continuous improvement.
• University is about learning and about life.

And for the most part, I’ve stayed with that mindset ever since I’ve started working. And I’ve been allowed to stay with that mindset. [An aside: I find it ironic that while people like me strive to transport good-university experience into the workplace, some universities are doing their best to do the reverse, import the worst of the workplace into university. I wonder why that is. Sponsored research and patents and commercialisation of learning, perhaps? You might as well tell a ten-year-old she needs a regulated certificate of competence and an insurance policy to run a lemonade stand in the driveway. Which will probably happen soon in the regrettably increasingly litigious society we live in].

Now to the point of this post. As you can see I believe that firms should be places of learning as well, that it is the only thing to do. There may have been good reasons why this did not seem a necessity in the past, but now with social software we can help firms acquire the DNA and culture of learning. And thereby prepare for Generation M. Because they won’t put up with what we put up with, however hard we try. They will refuse to understand why things happen the way they do, push back and vote with their feet. It is happening now.

With this in mind, I was really intrigued by Clay Shirky’s piece on View Source, a 1998 article I happened to re-read recently and post about.

What intrigued me? Some part of my DNA is infected with beliefs that learning-by-doing is a good thing, that learning by observation and inspection and imitation is also a good thing. So when Clay inferred that View Source gave us the ability to say “A-ha. So that’s how it is done”, there was something of value for me there.

So I mulled over the need for a large body of evidence of how people do things, so that you could learn from their successes and failures. So that you could learn from stories and anecdotes taken from real life rather than theories written by people whose experience was primarily in writing theories.

And it made me think of the opensource movement, that we now have a wealth of open transparent inspectable learnable-from material about how software should be written. That we could absorb all this learning, and then merge it with our analogies and allegories about architects and artists and creators and makers and fixers and breakers. And make new things and make old things better.
So I started looking for people who used opensource repositories as a source of learning how to write software. And found this pair of books by Diomidis Spinellis.

Code Reading: The Open Source Perspective

and

Code Quality: The Open Source Perspective

I think anyone and everyone interested in ICT should read the books, even if they have no intention of ever writing code. I’m not going to try and summarise them, suffice it to say that Mr Spinellis knows how to write, has a vocational calling and is passionate about his subject matter.

A taster from the book, in my own words. Everyone knows about cost-time-quality tradeoffs. Everyone understands that cost and time can be varied by what Mr Spinellis calls “management fiat”. Quality is a different matter. So we should take time out to understand quality in the context of what actually happens in the opensource world, using real-life examples.

I promised I wouldn’t try and summarise it, so I’ll stop there.

I can’t help but think there is value here for educational institutions as well, and for creating and embedding a learning culture in firms. Non-trivial worked examples that port well across industry and sector and culture and timezone; real errors made by real people, and what they did as a result. How Not To is as powerful a lesson as How To, maybe more so.

A focus on inspectable quality attributes that endorses, and is endorsed by, opensource principles.

The kernel for this particular snowball was a conversation over dinner, where someone asked me how I dealt with all the flames against my blog.

My answer to him was pretty much off-the-cuff, I didn’t spend time trying to figure it out. I told him that the number of flames was negligible. He then followed up with a question on whether I had any idea why that would be the case. And I told him, flamers tend to be attention-seekers, so they tend to spend time only where they knew they were going to get attention. It’s like hijacking a bicycle, why would anyone do that? No attention, no media coverage, so no bicycle hijacks.

We took this line of conversation all over the place after that, it really doesn’t matter. But on the way home I started to think, why is it that people think that blogs are all about flaming? Don’t they get it?

And that made me think about what it is that people don’t get. And I realised that when I speak to people as peculiar as I am, we often refer to others as “She gets it” and “He doesn’t get it”.

Get what?

This it, that people get or not-get, this it exists in many spheres. It is why people equate opensource with freeware and with security lapses; it is why people equate blogs with flaming; it is why people equate social software with being communist or pinko; it is why people equate downloads and uploads with piracy; it is why people equate work with not-fun.

So what does it take to Get It? To be one of the Got Its?

I think you need to believe you don’t have all the answers. You need to believe you could be wrong. You need to believe that others could help you be right. That others could help you learn. That there is power in community. That people can be unselfish. That you can trust people. That it’s OK to be wrong, provided you learn. That relationships matter. That covenant is good. That Doing the Right Thing is something to strive for. That it’s OK to be vulnerable, to express opinions, to share. That you don’t have to have an axe to grind in order to live. That you can Pay It Forward. That not everyone seeks to monetise each and every action.

That you need to believe in humanity and in humility.

The people who don’t get it can’t understand altruism, think every gift horse is a toothless Trojan. Can’t understand openness and sharing and community. Can’t understand trust. The people who don’t get it live in this weird bondage of isolation and distrust. I couldn’t do it. Just couldn’t.