Bob Frankston: The Economist, the Internet, Telecom and the Dow. The July 20th cover story on the Telecom Crash draws no distinction between the business of providing commodity Internet connectivity with the business of providing telecommunications-based services. Of course The Economist is not alone in this fundamental error but "Crash" story is a useful foil for addressing this misunderstanding. [Tomalak's Realm]

The Internet itself is not a business nor a marketplace or even a particular technology. It is simply a way of providing connectivity by simply packaging bits in uniform packets and then delivering them anywhere else in the world.

That's not very interesting. But then paper money isn't very interesting to most people; printing money is just a way to simplify business transactions by having a simple way to transport value. Printing money and carrying packets are interesting businesses in their own right. We don't confuse the business of printing money with using the money for financial transactions.

More insight from Bob Frankston on the Internet.

1:02:25 PM •  • comment  

It's the stupid network, stupid!. Lloyd Wood has posted the slides from his "The First 31 Years of the Internet -- An Insider's View" talk. The first 24 screens are just net.history, but things get pretty juicy round-about slide 25:

Deep philosphical gap between Computer Scientists who developed Internet architecture, and telecommunication engineers:

* Engineers: The Internet is under-engineered --

it does not solve all current problems in the most optimal and controllable manner.

Besides, we LOVE virtual circuits and complexity.

* Internet Researchers: Optimal is NOT the point.

The future adaptability of the Internet to new technologies and to provide new services depends on NOT over-engineering the Internet! Uncertainty: live with it.

Besides, we LOVE datagrams and simplicity.

---

Internet Architecture Melting...

* Orgy of tunnel-vision engineering taking place in IETF to meet these problems, and others.

* A shortage of wisdom; continual need for damage control.

* Easily forget the cost of [over-] engineering; remember: generality, heterogeneity, robustness, extensibility?

* Maybe we need to pay people NOT to develop new protocols.

* But perhaps, it is also time to rethink the architecture.

Note to self: Use the word "orgy" in next talk. Link (356k PDF) Discuss (via Oblomovka) [Boing Boing Blog]

More on understanding the underlying design thinking that produced the internet as we know it.

12:55:25 PM •  • comment  

Blogtree: the lineage of blogs.... The newest addition to the nav bar on the left side of this site is my Blogtree link. You can see the blogs that inspired me to start blogging; blogs that were inspired by the same “parents”; and blogs that I’ve inspired there. Kind of a cool idea—and when I checked about 1100 blogs had registered. [jarretthousenorth News]

I've added my BlogTree as well. It's over on the left side.

12:50:30 PM •  • comment  

Is Knowledge Sharing Natural?. "The most direct approach isn't always the best." So says the Chinese-cookie fortune that I've got taped to my display. It jumps out at me this morning as I browse the weblogs of two gentlemen for whom information flow is a normal course of nature.

"...as I entered the business world, it simply made no sense to me that computers were being used solely for computing and "data processing"; the collaborative online work environment that I'd taken for granted, that I'd used day in and day out, was simply missing in action. Our work lives are all about interpersonal connections, our businesses processes are structured into connections amongst people and systems that must be coordinated. What better use of technology than to help people to connect?" [Ray Ozzie] Ya see, Ray's one who "gets it" when the topic turns to sharing information. He sees blogs, Groove and other tools as enabling individuals, allowing them to working together. As such, he doesn't see a need for defined process changes to take advantage of all this wonderful stuff, it should just come naturally.

We've got our set of sharing technologies here, being added to an long-existing workflow. Given the entrenchment of "the old way" of doing things and the day-to-day pressure of metric-driven managers, "what comes natural" for many people is "what we've always done." As Jon Udell puts it, "you can't swim upstream against what people naturally want to do." Jon sees more and more people discovering the wonderful world of sharing - and perhaps that's what it needs to be, discovered instead of having it forced upon them. Maybe some of us have been trying too hard to take the direct approach, holding classes and running reports while "implementing" a new "methodology."

Have you had more success with "formal" methods of rolling out a set of KM practices and technologies or by simply showing those who appear eager and letting them evangelize it as they go along? [Steven Vore: KM]

My hypothesis is that many of the failures in rolling out KM practices and technologies follows from a workflow model that incorrectly tries to cram knowledge work into some kind of assembly line model of the work. The flaw is that this approach focuses on the visible and least important 10% of the process and is blind to the 90% that matters. This 90% contains both the individual mental processes that go into creating new knowledge work products and the social interactions in context that move too quickly to be seen without careful observation and attention.

10:21:09 AM •  • comment  

Ray Ozzie: Why?
As usual, Ray nails it.  I think he's dead-on that decentralized tools for collaborative work (what I provisionaly call postmodern knowledge management) will be the next great category of enterprise software applications.  This piece gives some background on how he got there.
(via Scripting News)

[Werblog]

A superb piece by Ray Ozzie on the relationship between tool designs and effective knowledge work. Not just worth reading, but worth spending time re-reading and thinking through.

One key observation:

Of course, blogs are (and the theory behind klogs is, I believe) at the complete opposite end of the spectrum - being "make public by default". By choosing to work "in the open", others surely can benefit from work that "should" be published.  And let there be no doubt: if you can get people to work in the open, it can be quite valuable to others so long as people broadly understand what should be shared and what shouldn't.

But therein lies the rub: getting people to do it.  We spent years and years at Lotus trying to convince people of the "higher order" value of collaborative processes, sharing, and KM.  And I learned the hard way that fighting what appear to be natural organizational and social dynamics is very tough.  Which is why eMail is the most popular collaboration tool on the planet: it works the way that people naturally want to work.  And which is why Groove is built upon a client-side, personally empowering "email model" than an "app server" model.  Mobile, instant, ad hoc, private.  Effective collaboration tools strike a balance between personal need/behavior and collective/organizational need.

The one place where I differ here is to be cautious about drawing conclusions about the way that people "naturally want to work." I don't think we understand knowledge work or collaboration on knowledge work well enough to draw strong conclusions about "natural." I'm more inclined to Doug Engelbart's conclusion that you need to be prepared to invest considerable time in learning how to work with new tools (his analogy being the difference between tricycles and bicyles, but go see what he had to say).

We're willing to invest considerable time to become financial analysts, or programmers, or chemists in terms of learning how to use a complex set of intellectual tools. On the other hand, we don't seem to be willing to invest more than 15 minutes in learning how to use general purpose knowledge tools like Groove, Radio, or Traction. We're not even willing to invest much time in learning simpler tools like outliners, or mindmaps. This continues to be a puzzle to me.

10:15:03 AM •  • comment  

Giving in order to receive. This item "Understanding and using scoped zones of discussion" - by Jon Udel on discussion on the web is well worth reading in its own right but the reason I am posting it here is for one particular piece entitled Giving in order to receive . Here is a little of what Jon says:

It's always tempting to post a message that asks: "Does anybody know how HTTP authentication works?" But you owe your intranet colleagues (and yourself) more consideration than that. And in wider contexts, this kind of naive plea will be ignored if not actively ridiculed. Instead, summarize what you know already, cite supporting evidence, frame the issues at stake clearly, and ask specific questions. Here's an example of what I mean:

"I've been researching HTTP authentication in order to solve the following problem: . Along the way, I've learned some useful things: . Based on this information, it seems to me that this plan will work: . Comments and clarifications are welcome and appreciated."

In my opinion, although seemingly obvious - it is something we tend to overlook and is a stunning example of how to encourage knowledge sharing. I get dozens of e-mails each month asking for help - most of them I do not have the time to answer and many of them are of the 'one-liner - straight to the point' variety as in Jon's example above. Others give more detail - they tell me something I did not know, they offer me information in return - such as a final report - and they are personal so that I can relate to the sender. Guess which ones I am more inclined to reply to? []

We should think twice when we complain that other people do not want to share and reflect on how our own behavior may be part of the problem. Actually that's a pretty good rule for many of the problems we face in life! [Gurteen Knowledge-Log] [emphasis added]

Amen to that! How many failures in knowledge management can be laid at the feet of one-sided notions of knowledge sharing? Do you ever wonder how many people in positions of power were lunchroom bullies who never read Fulghum's All I Really Need to Know I Learned in Kindergarten

9:55:55 AM •  • comment  

Sharing: It's a Good Thing.

Joy nails it.

P.S.: Joy, can you please, please please fix your RSS feed? I've missed you!

[tins ::: Rick Klau's weblog]

Key insight for me:

the sharing of knowledge, and the cooperative application of new technologies are part of the responsibility of belonging to a community of practice.

First time I've seen the notion of knowledge sharing articulated as a responsibility of community membership.

9:09:41 AM •  • comment