Ross Mayfield's Weblog

Decoupling Decision Rights and Decentralization

Andrew McAfee has an interesting post that challenges the trend of decentralization in organizations.  Noting Tom Malone's work on how decreased communication costs enable more decentralized decision rights, he makes a distinction between information and knowledge.  You can now provide information to any potential decision maker at a low cost, but the best tacit knowledge for a given decision may reside in someone the core of an organization instead of the assumed edge.

Let’s say that a mortgage company realized that a few of its loan officers were just better at assessing credit risk than all the others. For whatever reasons (intelligence, experience, intuition, etc. ), they just had superior specific knowledge. In that situation, it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers. All the general knowledge (income statements, credit histories, etc.) would be sent to these few people, who would apply their specific knowledge to it and made decisions. In this example low information costs are still important; they allow all the general knowledge to be zipped to the few good officers. But the effect of low information costs isn’t decentralization and greater empowerment. Instead, it’s centralization of an important decision right and reduced autonomy for most loan officers.

Thought experiments like this one indicate to me that the net result of disappearing information costs won’t necessarily be decentralization. It will instead be the decoupling of information flows and decision rights. Organization designers will be able to allocate decision rights without worrying about how costly it will be to get required information to deciders. Leaders will be able to ask "Who should make this decision?" without adding "Keeping in mind that it’s going to be slow, difficult, and expensive to get them the general knowledge they’ll need."

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case. I agree with him that we’re at a very interesting point in the history of technology and the economics of information, but I’d label it a great decoupling (of information flow and decision rights) rather than a broad decentralization (as decision rights lateralize along with information flows).

Information has no value until it informs a decision that results in an outcome.  This is part of why it wants to be free and increasingly is.  The decider certainly plays a role in this equation.  But something concerns me about this Carr-esque classification of decision making capabilities based on tacit knowlege (what is it about theories from Harvard on expertise ;-P).  And I don't think it is enough to buck the trend of decentralization.

Decreasing communication costs and ubiquitous information begets transparency.  While the future impact of IT provides both the directions of strong crypto and transparent society, with uncharted privacy implications and policy -- I believe transparency is a greater force.  Especially when it comes to revealing bad decisions.

Lets take Andrew's mortgage company example.  First, celebrate that the organization can change structure from the decoupling of information and decision rights.  Then, note it can shift back.  If a group gains centralized decision making capabilities because of their, augmented by "general" information, it is in a good position to execute the decision making process. 

But my read of Malone's book is it is not just about decreasing communications costs that enable decentralization, but how decentralized organizations can scale.  I believe Andrew is suggesting that information systems that automate information processing enables this group to scale its capabilities.  At first glance, this is similar to how trading desks work.  But approving a mortgage for an individual is very different from institutional trading.  Markets are social and the actors in institutional trading actually rely on relationships, and by doing so improve their tacit knowledge and handle exceptions better.  By taking the social interaction out of the hands of the mortgage officer who is closer to the actual customer and in a position to assess different kinds of risks beyond the FICO score.  And perhaps worse in the long term, it dehumanizes the organization's capability to develop a relationship with the customer.

Perhaps I am being too prescriptive with the business model, and maybe sidestepped the issue by hypothesizing there is a different kind of tacit knowledge at the periphery of the organization.   But the point is some kinds of tacit knowledge and decision making capability, those best at detecting and handling exceptions to business processes, may not be scalable through automation and centralization.

What I really like about Andrew's idea is the ability to reassign decision rights because they are decoupled from information.  Good thing too, because corporations don't have deciding who is best to decide down to a science.  Given the potential transparency in an organization, we may get better at more broadly handling exceptions and learning from decisions made.  We may actually discover who influences makes decisions. But my long term belief in decentralized organization recognizes that it is the environment the organization exists within, not that inside the organization, that creates the greatest amount of exceptions.  And the organizations that put decision rights closer to exceptions are more likely to adapt and survive.

Perhaps a better structure is to encourage decoupling of decision rights

The Web 2.0 Learning Model

I've been dabbling with Yahoo! Pipes, an easy to use feed aggregator and manipulator.  I've made such silly things as a feed for anytime someone mentions Twitter on Twitter, viewing Twitter through Flickr, a Firehose feed of Socialtext public blogs, using a wiki page as a command line to gain additional context from the web within the page (Page Pipes), translated some stuff into German, and Techmeme through Flickr.  A couple of years ago I would have killed for something to splice feeds alone, although I can't remember why, and with Pipes I can do much more.  Which says a lot given that I am not a programmer and generally too busy.

I did most of this by stealing other people's ideas, through the view source method of learning.  Lots of people learned HTML this way, what you could call the Web 1.0 model of learning.  Since Andressen implemented a browser instead of the two-way web Berners-Lee envisioned, developing in HTML was effectively done in a disconnected way.  You learn by viewing source, copying and pasting occasionally, writing offline and pushing changes up by FTP.  Transparency of code accelerated learning, but with every copy and paste a hypertext angel dies.

It is one thing to look at a block of HTML and understand how it works.  It is another thing to be able to see how it was made.  Good coders document for others within the code, something essential when working within teams, but invaluable for working with strangers.  And strange code.  And letting strangers learn from you.  You get the idea.

Seeing how it is made ideally incorporates attribution and memory.  Attributing sources of code that was built upon.  Memory meaning seeing how the code was written over time.

So back to Pipes.  You learn how to use it by viewing, cloning and editing the source of different pipes.  There is a good collection of popular pipes to start with and you can search deeper.  But I've noticed that since launch there hasn't been that much in the way of new Pipes rising to prominence.  I hacked the URL to browse by number of clones, but noticed most of the core pipes (granular bits good for reuse, cloned more than run) are still created by the staff.  In other words, the community isn't learning fast enough, or there is little community to learn. 

The first thing Pipes should do is make it more of a social tool.  Add Comments below each Pipe to enable a feedback loop and let us browse people to reveal active contributors.

The second thing Pipes should do is make it more of a wiki.  I'm not suggesting they need a wiki for user generated documentation, that's the third thing and a no-brainer.  When someone clones a Pipe, attribute and link back to where it was cloned.  Inheritance is not a death tax.  Further, I'm pretty sure most users don't recognize that you can mashup multiple Pipes.  It took me a little while to discover that while editing I can search for other pipes and drag them in (note that dragging doesn't kill hypertext angels) or drag in my own pipes.  This should almost be the most prominent feature of the editing interface, to encourage more re-use, attribution and granular abstraction.  In other words, I'm looking for the attribution/backlinks and revision history inherent in a wiki.

Oh, and that third thing.  I'm really impressed by what the Pipes team invented and think it could become a vital component of the web.  But this thing needs documentation across the web.  Put it in the wiki because you couldn't possible write it all yourself.  Let people like Rod Boothby document how to hook Pipes up to Teqlo, not just because he can spell Teqlo ;-).  Let me know if you need help installing Socialtext Open ;-).

Now let me fire up my buzzword engine.  I think the Web 2.0 Learning Model incorporates key traits of how wikis work.  Notably permission to participate, transparency, identity, discourse, attribution and memory.  We learn not only through copying others, but by watching how others copy others over time.

The Wikinomics Playbook

UPDATE: An interesting related project by Penguin Books is A Million Penguins, letting anyone edit a book to be published.  The wiki is down at the moment, but PaidContent notes it began with “It had snowed, and was now raining. Gritty slush covered the pavement. Sharp crystals of snow decorated grass.”  Reuters notes the challenge is finding “believable fictional voice” within the mass collaboration.  This was a big challenge for group editing of the Wired Wiki story.

The last chapter of Don Tapscott's new book, Wikinomics, invites readers to write it: “Join us in peer producing the definitive guide to the twenty-first-century corporation on www.wikinomics.com.”  Today we launched a Socialtext wiki for the Wikinomics Playbook, where people can not only learn about the power of mass collaboration, but participate in it.  The book is already one of the fastest selling business titles and is an excellent primer on how models of collaboration are unfolding from open source to blogging to wikis in the enterprise to enable people to participate in the economy like never before.

The second to last chapter is about enterprise wikis.  Half of it discusses how Best Buy is using a wiki knowledge-base for the Geek Squad.  The other half is an interview with yours truly and shares some of Socialtext's success stories. The first chapter is available online as a pdf.

 

This is a great example of how a book can be augmented with a wiki, as most books are out of date by the time they are published, never quite finished and have the potential for participation. Last month we helped Larry Lessig share the entire Code 2.0 book in a wiki.  I expect that soon such commons-peer production, a wiki for every book, will be common.

Learning in the Shower

Eugene starts to shift towards an emphasis in learning in LearningCommunity, realizing he isn't learning enough, and shares this:

DougEngelbart often says that high-performance communities are experts at CoDIAK -- collectively developing, integrating, and applying knowledge.  I hate the acronym, because I think it's unnecessarily esoteric.  What CoDIAK boils down to is:    (LJ9)

• Learn.    (LJA)
• Share and apply what you know.    (LJB)
• Repeat early and often.    (LJC)

Do you ever find yourself in the captive audience of your shower, reading shampoo labels?  You know you aren't learning anything by reading them.  Yet you are trying to do more than kill time.  And there it is: Lather, rinse and repeat.  How many times have you thought of these instructions?  Not just because they are part of popular culture.  I personally think it is a scam to use more shampoo than is necessary to get the job done.

If there ever was a problem confronting eLearning, I think it is that enterprise users view their solutions in the same way people do instructions on shampoo bottles.

The fix, and this is where the shower metaphor breaks down for some people, is that 80% of learning is social.