Infovark

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:

1. Mitigate risk effectively,
2. 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.

So how can web technology help address the problem of paper shuffling? To recap the previous post, the three key problems are:

1. Tracking documents.
2. Versioning documents.
3. Locating documents.

Let’s tackle these problems in reverse order. The web has a simple solution for locating documents: the Uniform Resource Identifier, or URI. You might have heard it called the Uniform Resource Locator, or URL. The two concepts are closely related, but the differences aren’t important for this discussion. Unique Ids are nothing new; record numbering or library classification schemes like the Dewey Decimal System have been around for a long time. But the URI standard supported by the W3C is the first such system to be truly global.

It’s more than a classification system, however. It’s an addressing system. In addition to assigning a unique Id, a URI tells you how to access the document. It also tells you where it lives and who owns it.

For instance, the URI http://www.microsoft.com/en/us/default.aspx tells us that a unique document named default.aspx lives at the domain named www.microsoft.com. If we look up the domain name, we’ll find it’s registered to Microsoft Corporation of Redmond, Washington, United States of America. It also tells us that we can interact with the document using Hypertext Transfer Protocol, or HTTP. That’s a lot of information in just a few characters. It’s a simple yet powerful system.

If we want to take advantage of this well understood and widely adopted international standard in the enterprise, we need a way to assign a URI to every block of information that has importance to the business. Many existing enterprise content management tools already do this, Microsoft SharePoint, EMC Documentum, and Oracle Stellent being the big three. But all three of these tools ask employees to do something very odd from a web perspective: They ask that the employee send their local files to a central server in order to get published with an addressable URI.

This is weird. We don’t email our public web pages to Google in order to have them appear in its index. Why do we send corporate documents to a centralized server? “To give it its unique number,” an organization’s records manager might reply. But this is old-school thinking; We’re not talking about a librarian stamping a number on a physical book.

It’s far easier to move a unique number from a central server to a workstation then to transfer an entire spreadsheet from a workstation to a server, only to pass it back again so that the employee can continue working on it. In other words, have the librarian send a sticker with the URI on it to the worker and let the worker slap it on the document. The label’s much easier to ship than a book.

But that approach is old-school thinking, too. We don’t need to move the book or the unique identifier: We’ll let the workstation create its own URI.

On the Internet, when you want a document from Microsoft, you type http://www.microsoft.com into your browser. Why not go to http://mary.mycompany.com when you want to get a document from Mary in Accounting? The same technology that makes the “big I” Internet work can make our “little i” intranets work, too.

All we need is a small program that assigns a URI to an employee’s documents and allows the employee’s workstation to act as its own webserver. Naturally this program needs to be secure, but we have two advantages. The first is that an organization knows its members. Nobody can log into the corporate network without a valid user account. On the public Internet, everyone is anonymous, but on your intranet, you can identify all of your coworkers. Second is that the same corporate firewall that prevents network attacks from the Internet can also prevent leaks coming from your intranet. (You do have a corporate firewall, don’t you?) With a few sensible precautions baked into this mini-webserver, you’ve neatly solved the addressability problem.

The system is remarkably intuitive. If you know Bill was tasked with coming up with the latest marketing presentation, you won’t have to search a vast corporate repository for it; You’ll find it on his machine. When Steve finishes work on his policy memo, he doesn’t have to upload it to headquarters and remember where to file it. He just asks this little program to publish it. Ding! Now it’s got a unique number and it’s available for all to see.

That’s how we’d solve the problem of locating information: It’s easiest to locate information if you never need to move it in the first place.

With my background in Enterprise Content Management, one of the blogs I’ve been subscribed to for a long time is Chuck Hollis, from EMC. EMC Documentum is a competitor for my former employer, TOWER Software, so back then, it was prudent to keep an ear out for those guys. As my focus moved away from ECM and towards Enterprise 2.0, I kind of stopped reading his posts regularly.

Which was dumb, because, as I found out from Jeremy, it turns out that he’s just as excited about emergence and social media in the enterprise as I am. So much so, that he’s started a dedicated blog detailing the deployment of Jive Software’s Clearspace within EMC.

The immediate question for me upon hearing this news, was, “Huh? EMC already own two products that claim to be able to do this stuff.”

Documentum Collaboration and eRoom were both touted to “enable distributed teams to work together more efficiently”, and yet EMC’s selected product was neither of those. They opted for a third party solution outside the ever-growing catalog of EMC Software.

After catching up on about half-a-years’ worth of posts, I found the answer, beautifully identified by Chuck himself in this post. After discussing Transactional Collaboration (workflow), and Document Collaboration (sharepoint, eroom) he goes on to discuss what he called “Social Collaboration”:

…Doing it in the margins between meetings isn’t efficient or productive, and having formal “brainstorming” sessions doesn’t always feel quite right. And if someone schedules another conference call, I’ll cringe.

It’s not predefined interaction. It’s not a structured workflow. It’s something entirely different than the other two collaboration models. It’s people talking with each other about what’s interesting — hopefully in a work context.

Brilliant! That’s exactly what it is. It’s about knowledge workers being able to share, discuss and distribute the things that they know and care about, without being shoehorned into a process box, or a pre-defined meeting space.

The most productive information enterprise is the one with the smartest, best connected people that can adapt and make the best decisions. Not the one with the biggest, most perfectly enforced quality procedure manual.

Chuck, welcome back to my collection of must-read feeds.

Oh, and speaking of those, Sam Lawrence from Jive Software also shares his experience with the EMC deployment over on his blog, Go Big Always.

We’ve mentioned before that computers don’t think the way people do. A simple example of this is that your PC doesn’t understand how to move something. For a typical operating system, a “move file” operation is actually composed of two steps: copy and delete. The original file is copied from one location to another and then the original is deleted, leaving only the new file in a different place.

That’s all the computer knows. If you ask for the original file, the computer tells you it doesn’t exist. As far as it’s concerned, it might never have existed. Maybe you got the name wrong. Maybe you got the folder wrong. Maybe you imagined it. All you’ll get in response from the computer is Bad Command or Filename, the computer equivalent of saying “Dunno, boss” and shrugging.

Keep in mind that the computer’s not trying to be unhelpful; it just doesn’t know what happened. It sees the world differently than we do. The way it moves things is not how things move in the real world.

It went that-a-way…

If this sort of thing happened in real life, the document lying on your desk might suddenly vanish in a flash of light, and a new document might materialize out of thin air in the conference room.

Are they the same? If you walked into the conference room and picked up the new document, how could you tell if it was the same as the one that vanished?

You’d have to search your memory to figure out whether this new document matches up to what you remember of the document that left your office under mysterious circumstances.

This is exactly the problem that computers face all the time. Without going through the system logs, or comparing a system backup to the current state of the system, there’s really no way for your computer to know whether the document in the conference room was the same as the one on the desktop, whether it was a different version of the same document, or whether it was a different document altogether.

Now imagine that you’d told Sally, a coworker, about the document on your desk. After the mysterious document transfer operation, she walks into your office to have a look at it. But it’s not there anymore. It vanished without a trace. She’s got three options: First, she can assume you threw it out and the file is no longer available. Second, she can assume you moved it somewhere. She could begin searching the entire building for it. Third, she can wait until you get back to your office and then ask you what happened to it.

The third option is what most organizations rely on today. Sally might have a peek into your office to see if the file’s there, and if it isn’t, she’d send you an email to ask about it. Most of the time, though, she saves herself a walk down the hall and just sends the email. Since you’re the only person on the planet that knows the file mysteriously reappeared in the conference room, she’ll have to wait until you get back to your computer to find out what happened. Then you can reply to her email with this amazing story of the disappearing-reappearing weekly sales report.

You can almost hear her voice on the other end of the phone now, “Uh huh. Magic. Really. That’s great. Look, just send me the figures, OK? I need them right away.”

But again, how do you know — and how will Sally know — that the document you found in the conference room is the right one, or the right version of the right one? You don’t. You’ll both just have to hope that it’s the same.

The next day, when Pete reviews the numbers in the team meeting, he looks at the paper Sally handed to him. He shakes his head. “I’m pretty sure I updated these yesterday.” You’re just about to tell him this absolutely amazing story when Sally glares at you and kicks you from under the table. Another lousy day at the office…

Three real-world problems

The story highlights three critical information management problems:

1. Tracking documents.
2. Versioning documents.
3. Locating documents.

Since computers aren’t doing these things for us, we have to figure out ways of doing them by hand. As most of us discovered decades ago, email solves the second problem fairly well. Every email is date-stamped with the time it was sent and the time it was received, so you’ve got a good idea of how recent the attached documents are.

Email partially answers the third problem; if you can remember to whom you sent a document, they might be able to retrieve it for you using whatever memory aids they find effective. Sure, using email for this purpose is slow and annoying for both you and your coworkers –

“Hey, uh, could you send me that presentation again? I can’t seem to find it…” –

“Oh - I think it’s in my Sent Items…”

…but it seems to work a fair amount of the time.

That leaves the first problem, for which email is almost totally ineffective. Once you send a document out, there’s no telling who it could be forwarded to, or when you’d get a reply back, or whether you’ve actually gotten a reply back to an older message with an out-of-date copy of an attachment, and so on.

All three problems can be summed up in one short phrase: paper shuffling. Paper shuffling is the bane of the knowledge worker’s existence: It’s tedious, boring, tiresome drudge-work. This is not what your well-educated, well-paid creative staff were hired to do. It’s not what knowledge workers want to do. Yet lots of their time is spent doing it.

Recent studies claim that knowledge workers spend more than a quarter of their time in email applications. How much of that time is spent on fixing the three problems above?

And all because our current computer operating systems don’t understand basic operations like move.