"I can't say that I agree with Don Park on this one.  In every organization in which I've been a manager, hierarchy becomes unavoidable because of course it's essential to utilize organizational network forms to cope with complexity.  But hierarchy by its very nature causes filtering and interpretation, and in order to truly keep a continuous "feel" for what's going on in the organization and in the market, I strive for more sophisticated network forms that inject more than a bit of the "edge" into my thinking.

Don says that "the CEO is not likely to know about, let alone subscribe to, a lowly QA engineer's blog."  Perhaps.  But I seek out and truly relish interaction with people at the edge of my organization.  When I find a hairy bug (e.g. a deadlock, or a comms or memory issue in the product), I love having the developer come in and debug it face-to-face.  It gives me a chance not only to understand more about the product's internals, but also you have NO idea what I learn while chit-chatting while waiting for debug files to copy, etc.  Design & implementation issues, stuff that people have been building off to the side, things about the organization, rumors, etc.  And of course they also milk me for what's going on in my travels, in my official role as Overhead at the organization.

I love listening to an individual sales rep or SE when we're on a sales call, because I get a better feel for what's actually going on with customers or prospects.  I try to pattern-match across reps so that I can see what might be improved in the sales process, rather than just listening to my VP of Sales.  I love interacting with designers and developers when doing my Thursday detailed feature design reviews.  I suppose this is just classic "walking the halls", etc., but I feel as though without this kind of direct nonhierarchical contact I would lose touch with my organization, and people throughout would know I was disconnected and would lose respect for me.

With regard to blogs, I do agree that we need to figure out some kind of structure, but I don't think it should be strictly hierarchical.  I've got nearly 150 feeds that I monitor in one way or another - some employee, some not - and of course it's way too much to consume everything.  I've asked myself "if you could only read 10, which would you read?"  But I've found that this is the wrong question.  Reading those 10 would be like only having meetings with my direct reports.  I look to blogs for serendipity, and I won't truly understand what's going on "out there" unless I mix it up a bit.

So rather than hierarchical blogs, maybe the answer is a mix of some close (recurring) and some far (random)?  Maybe I should constantly read my 10 favorite feeds, and have the reader spit a bunch of randomness at me from the remaining 140?  All I know is that I need to mix some "practice" with the "process", to force some chaos into the system rather than just treating it as merely complex and manageable - which it most certainly is not. [Ray Ozzie's Weblog]"

Surrounded by new opportunities.

Ray Ozzie on ZDNet : Surrounded by new opportunities

Even though our current use of PCs, productivity tools, e-mail and the Web seems quite sophisticated, we've only just begun to understand how to apply them and effectively realize their benefits. The next 10 years will find us moving decidedly from an era of personal productivity to one of joint productivity and social software. That will involve a move from tightly coupled systems to more loosely coupled interconnections. It will be an era of highly interdependent systems and relationships, with technology continuing to reshape the nature of organizations, economy, society and personal lives.

[Jeroen Bekkers' Groove Weblog]

Ray Ozzie is busy thinking about the kinds of problems we'll want computers to help with five to ten years from now. Groove, or something like it, may well be part of that answer. Certainly, the focus on collaboration and social software will be a major element of what's next.  That's certainly what I expect someone like Ozzie to be thinking about.

At the same time, I think it's an overstatement to claim that many of us are realizing the personal productivity promise of today's technology. While I might not go as far as Alan Kay's claim that the computer revolution hasn't happened yet, I do think that both individual knowledge workers and organizations could be doing a lot more to take advantage of the tools we have.

In the mid-1980s, the Harvard Business School was one of the first MBA programs to require incoming students to buy PCs. One of the things I got to participate in as a doctoral student at the time was to help deliver the training to incoming MBAs. We spent three days teaching them the basics of the IBM PC and how to use Lotus 123.

How much training does the average organization offer new hires about the technology environment? An hour? Thirty minutes? Some of that is a testament to the overall improvements in usability and in general knowledge of technology. But I can't think of anyplace that invests any time in how to use the tools effectively. One interesting item (by way of Sebastien Paquet) is a white paper by Tommaso Toffoli at Boston University titled "A Knowledge Home: Personal knowledge structuring in a computer world." (pdf version)

The fundamental challenge, and opportunity, is that we've been content to focus on increasing the power and flexibility of our technology tools while assuming that knowledge workers will figure out how to take advantage fo that power. As knowledge workers it's our responsibility to do more of that figuring out. We need to stop counting on the marketing promises of technology vendors and start learning how to use the tools we've already got.

[McGee's Musings]

(SOURCE:"rayo")-So what about Groove makes this project better? The only differentiator that I can see is Groove's built in high quality security. Does this team really need that level of security? Other than the military and the government, who really needs the security of Groove? And also why couldn't this team have used internal blogs? Someday I am going to really have to try Groove and figure this out.
<quote>
An interesting cross-border use of Groove I just found out about: The International Crane Foundation - headquartered in Wisconsin - uses Groove to help a multi-national team address threats to key wetlands used by Siberian Cranes during breeding, wintering and migration. During the past three years, the ICF has worked intensively with the United Nations Environment Program and colleagues in Russia, China, Kazakhstan and Iran on this project, which addresses threats to key wetlands used by this crane species (the third rarest) during breeding and migration through these parts of the world.
</quote> [Roland Tanglao: KLogs]

Groove is more than a blog.  Groove allows a team to collaborate at a finer level - sharing files, sharing a calendar, sharing notes, participating in a discussion forum or a chat, editing a document, sharing websites, managing project tasks - in a secure and project-specific setting.  Only the team members share the Groove Workspace.  With the GrooveInterOp Radio Tool, you can have both - the secure team environment of Groove and a weblog.

 

Mitchell Kapor steps down as a director to focus on nonprofit activities--and also reportedly because he's troubled that Groove's software may be used in domestic surveillance. [CNET News.com]

Mike Bedan (Home):
So, let's see... I am working on two weblogs (http://radio.weblogs.com/0107107) and (http://www.mikebedan.net/blogger.html).

I can post to the Radio blog using the Radio desktop application. I can post to the Blogger blog using online using the web browser interface. And both I can post to using Groove 2.5. Using the Groove InterOp Tool for Radio (http://radio.weblogs.com/0107414/stories/2003/01/14/grooveInteropToolForRadio.html) and the GrooveBlogger tool (look at http://radio.weblogs.com/0107414/ under the free tools section [you need Groove]). To this point, I have not truly used the weblogs as they are designed - flinging up content on a regular (almost daily) basis. I mostly have toyed with the concept and worked on the design of the weblogs. I am not a full-fledged blogger at this point. Now, I think I will Blog On!...

I was so busy coding the grooveInterop Tool for Radio, that I almost missed the impact the tool had on several people. All those kind and inspriring words makes me blush! Thank you all!
Some highlights below: [Tim Knip's Groovey Weblog]

(SOURCE:Scripting News)-Still processing this. Is the hype justified? Guess I need to break down and put Groove on a Windows box and use web services to interact with it from the non Windows world! Eines Tages!

Is Groove the stealth killer app of the early 21st century that companies are using to quietly gain a competitive advantage like the CIA many other organizations quietly used NeXT to build their internal killer apps? I doubt it, but you never know! Malsehen! <quote> Groove founder Ray Ozzie and his teams have always pretended to build application software. But what they have actually delivered are the operating systems of the future — years ahead of schedule. The XML business Web is only now achieving the architecture that Lotus Notes laid down 15 years ago: message-oriented exchange of semistructured documents. As today's operating systems catch up with that paradigm, Ozzie is tackling the next set of challenges in Groove: drop-dead simple, secure collaboration, presence management, coordination of user and device identities, and ad-hoc group formation. To make an omelet, you have to break eggs, and what Groove broke was compatibility with the e-mail infrastructure that serves (poorly) as our medium for team communication and as our distributed storage system. Groove also broke compatibility with the Web. Documents and messages in Groove's shared spaces had what looked like URLs, but those URLs didn't mean anything outside of Groove; they couldn't be bookmarked, shared, nor posted to the Web. Finally, Groove planted deep roots in Win32/COM, all but foreclosing non-Windows platform options. They were hard choices with serious consequences, but there was no other way to make the omelet. What the Groove Workspace has delivered since Version 1.0, and steadily refined through Version 2.5 released last week, is a seamless and comprehensive environment for collaboration. It defines what Microsoft and Apple will be lucky to achieve by 2006. When they get there, of course, they'll bring along everything Groove had to jettison in order to sprint to the finish line. Meanwhile, Groove's challenge is to reel in what was thrown overboard. The 2.5 release confronts that challenge. </quote> [Roland Tanglao: KLogs]

Team blogging

Groove founder Ray Ozzie and his teams have always pretended to build application software. But what they have actually delivered are the operating systems of the future -- years ahead of schedule. The XML business Web is only now achieving the architecture that Lotus Notes laid down 15 years ago: message-oriented exchange of semi-structured documents. As today's operating systems catch up with that paradigm, Ozzie is tackling the next set of challenges in Groove: drop-dead simple secure collaboration, presence management, coordination of user and device identities, and ad-hoc group group formation. [Full story at InfoWorld.com.]

The scenario shown in the screenshot uses Tim Knip's Groove interop tool -- a Radio UserLand add-in based on Groove Web Services -- to create a genuinely new experience of team blogging. Until now, team blogging has meant that a group of folks post to a common weblog. This setup does that too, but it also does something I find much more powerful -- it synchronizes the inputs to the collaborative process, as well as the output. In this case, the input is the combined set of RSS feeds subscribed to by the members of the shared space. Everyone knows that everyone else is seeing the same feeds. Discussion can grow around items in those feeds, and can take various forms: replies to the forum that receives the feeds, IM-style text chat, Roger Wilco-style voice chat. ... [Jon's Radio]