Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
Most organizations of more than one person function with an established layer of process and policy. There is usually (somewhere) an organization chart that explains who reports to whom, and who’s responsible for what bits of the organization. These formal channels represent the chain of command. There’s usually (also somewhere) a series of duty statements that detail exactly what these people in these positions can and can’t do.
These formal channels of communication and structure evolved because organizations wanted to stop people from doing bad things — things that are detrimental to the business. They’re there to provide a reference for when somebody needs to be held accountable. Or, to put it in a more succinct way:
Formal channels are about risk management.
A friend of mine is preparing a management induction program for his company, and asked me what aspects of his company I thought warranted inclusion. After giving the idea careful thought, I suggested that he look at the organization from a risk analysis perspective, and spend time in those areas of the organization that are most exposed to risk, because any future manager is going to need to base decisions based on those things. Sales, Infrastructure, PR, — all of the high-risk things attract management. And then it dawned on me that
All Management is Risk Management.
Think about it. The only reason the person higher up the org chart is getting paid more than you is that they are supposedly accountable for more risk.
Assuming this is true, there are two ways that you can be an effective manager:
- Mitigate risk effectively,
- Keep as quiet as possible and hope that nothing goes wrong.
You’d be surprised how often managers go for Option 2. After all, if your boss don’t know what your team’s doing, how can your boss tell if you’re managing it right? Or wrong? (Or even managing it at all).
Secrecy is an extremely effective way to mitigate risk.
Most organizations mask this penchant for secrecy behind a veil of ‘security’. “How can we ensure that this document is only seen by the two people who are working with it?” I’ve worked with products in the ECM space that allow for so many layers of security that it becomes completely impossible for anyone to find anything. Managing access permissions to information ends up requiring multiple full-time staff members. Layer upon layer of formal, secure channels leave the organization extremely well insured against risk, but unable to execute effectively.
This is what the more glib among us might refer to as “1.0 thinking”.
The one thing to remember about risk mitigation, and consequently management in general, is the offset of Significance and Severity.
If Severity were a question, it would be “How bad is this if it happens?”
If Significance were a question, it would be “How likely is this to occur?”
People are good at evaluating consequences, but not so good at predicting the future. As such, we tend to spend a lot more time focusing on the severity of a risk. This explains why secrecy-by-default is so prevalent in today’s organizations.
“What happens if someone executes our business strategy better than us? We’d better just keep the whole thing quiet…” It’s an understandable reaction, regardless of how likely it is to occur. The problem is that this hampers the ability of the organization to get things done, because they are cagey about how much they tell, and to whom… excessive risk mitigation impairs the ability to execute.
The Enterprise 2.0 way to solve this problem is to accept risks of low Significance, despite their Severity, and instead focus on common outcomes. In order to execute in the most effective manner, replace the formal, structured channels with collaborative and transparent information sharing. Don’t withhold anything.
Rather than mitigate the risk of people knowing too much, mitigate the risk of people knowing too little. Shift the corporate culture to one that emphasizes sharing by default.
Yes, this allows the people in your organization more opportunities to do bad things. We’re making the assumption that your knowledge workers want to work for you, and that they want to do a good job, and that they want to contribute to the team’s success. Assume good intentions on behalf of your employees. Assume that “Don’t be evil” makes as good a personal motto as a corporate one. Expect that your staff will act with integrity, and assume the risk that someone, somewhere, might screw up sometime.
What’s better? Unmotivated drones working for you in a process-laden environment that allows them to be semi-productive despite their apathy or antagonism, or effective, trustworthy people working with all the necessary information and tools they need to get the job done?
The central hypothesis of Enterprise 2.0, or social media, or social productivity, or whatever-you-call-it is this:
Organizations are more effective in a transparent culture of information sharing.
No related posts.
4 Comments
Duncan longstafff
Most organizations mask this penchant for secrecy behind a veil of ’security’. “How can we ensure that this document is only seen by the two people who are working with it?” I’ve worked with products in the ECM space that allow for so many layers of security that it becomes completely impossible for anyone to find anything. Managing access permissions to information ends up requiring multiple full-time staff members. Layer upon layer of formal, secure channels leave the organization extremely well insured against risk, but unable to execute effectively.
Gordon I agree. Security is Hard .. BUT very important.. So what your telling us is that your product will allow us to have a document seen by the only needed partys but seting that up will be easy..
As you said before I call shenanigan
15 Feb 2008 11:02 pm
Gordon
lol! (alright then, it’s shenanigans! Eveyone grab a broom…)
No – I’m not saying that our product sets out to solve the problem, (although it might be able to help some) – what I’m saying is that there’s a difference between security and secrecy.
As you say, security is very important. Securing information from unwanted people outside your organization is definitely important. But, I think that in the majority of cases, securing it from people within your organization isn’t – and in practice, it might do you more harm than good…
16 Feb 2008 03:02 pm
Duncan longstafff
16 Feb 2008 10:02 pm
Ben Tremblay
Of course people who know the years I’ve put into tantra and vajrayana think me foolish at best and, more likely yet, deranged. And those people are quite likely to was lyrical about “holographic reality” and “fractilinear dynamically balanced non-linear systems” when it occurs to them.
But the don’t get it.
So (hence the “of course”) they don’t get me.
I wouldn’t say you get me, but from what you’ve written here’s it’s manifestly evident that you get it.
Specifically:
“If Severity were a question, it would be “How bad is this if it happens?”
If Significance were a question, it would be “How likely is this to occur?””
I don’t imagine google will show many results, but it might show some … if you search for “MIL-SPEC FMECA” you’ll find a huge expansion on what you sketched out so elementally.
“Failure Modes; Effects Criticality Analysis”. (An amazing coincidence: just this evening I was bringing to mind the graphing technique it uses … in case I get a gig with Odyssey X-Prize … it’s that sorta ball-busting heavy-lifting that calls for such as FMECA.)
A graph … on one axis? Ayup, probability (“likelihood”). The other axis? Right again … severity.
Break the system down into parts (“lowest-replacable module” is the convention) and figure out how it goes wrong … make a list … how likely … how nasty … graph the points.
*Hey Presto!* An immediate representation of
how much shit you’re inwhere you’d best concentrate your efforts.how glad I dropped by!
ben
23 Feb 2008 01:02 am
What do you think? Leave a comment