Many analytics projects pass a pilot test with flying colors but fail to earn wide adoption. Here are five common culprits that doom projects – and advice for tackling them.
The Chatham House Rule: Your new collaboration tool?
A novel approach to sharing security data and expertise in an atmosphere of trust
Tackling bias between organizations
Another area of difficulty is expertise, or more specifically, trust in expertise. Most organizations aim for a meritocratic approach – or say they do – at least within that organization. But the world is full of bias, particularly between organizations. I may be biased against views held or expressed by a particular organization, just because of their past history and my interactions with that company, but it is quite possible that there are views held and expressed by individuals from that company which, if separated from their attribution, I might take seriously.
I may be biased against a particular person, based on my previous interactions with him/her, or just on my underlying prejudices. I only need one person who does not hold my biases to represent those views (as long as they personally trust the organization, or even just the person, expressing them) in order to process and value those views myself, gaining valuable insight from them. The Chatham House Rule can allow that to happen.
In fact, the same goes for intra-organization biases: Maybe product management isn’t interested in the views of marketing, but what if there are important things to learn from within that department, that product management can’t hear because of that bias? The Chatham House Rule allows an opportunity to get past that.
To return to open source, many contributors are employed by a particular organization, and it can be very difficult for them to express opinions around open source when that organization may not hold the same views, however carefully they try to separate themselves from the official line. Even more important, in terms of security, it very well be that they can bring insights which are relevant to a particular security issue which their company is not happy about being publicly known, but which could benefit one or more open source projects. To be clear: I’m not talking, here, about exposing information which is specifically confidential, but about sharing information with the permission of the organization, but within specific constraints.
There are all sorts of biases within society, and open source is, alas, not without its own. When a group of people gets to know each other well, however, it is often the case that members of that group can forge a respect for each other which goes beyond gender, age, academic expertise, sexuality, race, or the like. This is a perfect opportunity for meetings under the Chatham House Rule: It gives this group the chance to discuss and form opinions which can be represented to their peers – or the rest of the world – without having to worry so much about any prejudices or biases that might be aimed at particular members.
A final caution
The Chatham House Rule provides a great opportunity to share expertise and knowledge, but there is also a danger that it can allow undue weight to be expressed to anecdotes. Stories are a great way of imparting information, but without data to back them up, they are not as trustworthy as they might be. Because the Chatham House Rule inhibits external attribution, this does not mean that due diligence should not be applied within such a meeting to ensure that information is backed up by data.
[ How do containers help manage risk? Get the Red Hat whitepaper: Ten Layers of Container Security. ]