Library clips

A lot of people have different views on “emergence”, stating that this is the true essence of “enterprise 2.0″.
Using blogs and wikis doesn’t necessarily mean you are being social or are doing “enterprise 2.0″, it’s only when you these tools are certain way, and ultimately when a new social organisational culture has emerged.

Further to this, the best kind of “enterprise 2.0″ is when the participation and contributions are not just Directed In-the-Flow social ways of doing tasks, but moreso when people are Volunteering Above-the-Flow tacit knowledge.

Emergence isn’t just what content emerges from using these social tools, that would have never otherwise emerged. It’s also that these social tools are unstructured (not rigid) allowing people to use them for whatever purpose they like…rather than desiging tools for a specific purpose, we see new ways emerge in how people use these free-form tools.

For more see my posts:
Collaboration, Emergence and Culture
Why km 1.0 failed in a nutshell
KM 2.0 : catalyzing voluntary participation

Emergence is technology populism
- people start using a social or productivity tool as it helps them get work done, and it spreads virally
- it emerges as a tool of choice and method of choice to get things done

Emergence is similar to above but deployed by the enterprise as a bottom-up approach
- a pilot with ground level people may spread virally by word of mouth (rather than a roll-out)
- it emerges as a tool of choice and method of choice to get things done

Emergence is invention in the ways people creatively use free-form unstructured tools
- a team uses wikis to gather input from everyone to make a list
- it emerges as a great use as everyone is now using wikis this way

Emergence is collective intelligence
- a wiki is used to start a glossary of terminology and acronyms used by the enterprise
- it emerges a massive glossary, like wikipedia, via the collaborative input by the whole enterprise

Emergence is evolving ideas
- people have distributed blog conversations and leave comments
- it emerges a new concept or solution…an initial blog post may of had nothing to do with the end solution, but it’s existence spurred related ideas, and debate within the collective evolved a concept that no-one person thought of at the time

Emergence is seeing patterns in explicit data
- people that tag their wikipages, blog posts, bookmarks (folksonomies), etc…are contributing to a collective tag cloud
- it emerges concepts people are talking about, and we can see what they are most and least talking about…this tag cloud analysis reveals what’s going on in the enterprise and decisions can be made from this raw data

Emergence is seeing patterns in implicit data
- people click things leaving behind a recorded trail of what they pay attention to (clicks stream)
- it emerges a way to graph offerings like What’s Popular, and Personal Recommendations

Emergence is a new culture change in organisation dynamics and autonomy
- people are being socially productive using social tools; by participating, contributing, being visible and having conversations, they are drawing on the social captial to get things done, learn and create
- it emerges a learning organisation of an autonomous nature where people are tuning in and particpating to knowledge flow…you are aware of what’s going on, and perhaps the right projects and tasks fall into your lap (the right person is doing the right job as the enterprise social graph is aware of everyone and everything).

[ADDED 13/11/08: Emergence is the platform. “VCs usually don’t like the idea of a “platform”. They want to see a killer app first. But, it is quickly becoming obvious that having a platform IS the killer app. Or at least the killer differentiator. By platform, I mean something beyond a simple API. It is a mechanism for letting 3rd parties add value to your application through extensions and plug-ins.
WordPress, with all the 3rd party themes and application plugins is a great example of something that gets better as more people use it.”]

Explanation

Andrew McAfee
“Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.”

Mike Gotta
“The emergent use of social software platforms” vs. “use of emergent software platforms”

Mike Gotta
“Enterprise 2.0 is not about “all collaboration”, “all types of information sharing” or “all types of communication”. The context of E2.0 is anchored around “emergence”. Addressing organizational dynamics, which includes culture, is important to fully leverage and sustain the goals associated with E2.0″

Gordon Taylor
“The traditional approach is to build something autocratic, and deployed from the top down, that works along vertical reporting lines. Working this way, silos of information are preserved. and communication is kept within the traditional areas.

For a system to be emergent, the emphasis needs to be on how quickly the users will adopt the system rather than on its structure. That explains why a hallmark of these Web 2.0 technologies is that they are accessible and less restrictive.”

Gordon Taylor
“Emergent systems are decentralized, self-organizing and organic — the antithesis of the top-down, rules-based engineering approach taken by most enterprise software. To build an emergent system — an ecosystem — you target the bottom of the pyramid, building it up one user, one connected node, at a time. The value of an emergent system is derived from its flexibility, adaptability, and responsiveness.

Emergence isn’t another feature to add to the enterprise technology stack. Emergence isn’t a feature at all — it’s an approach to solving a problem.”

UPDATE: I just noticed Ray Sims has a post about emergence.

Grazr is a place where you can splice/merge feeds into one stream, or even keep a whole bunch of feeds together and read them by source, which ever way, it’s basically a mini-RSS Reader widget. You can make as many of these as you like and they host it all.

If you merge feeds into the one stream, others can subscribe to this RSS feed.
If you have a bunch of feeds by source, others can subscribe to this OPML feed.

NOTE: Feeds are Grazr’s main deal, but you can also add other type of nodes other than feeds, like an OPML, plain text, links…

Now they have gone a step further and enable you to filter a Grazr by keyword (title, author, body), by date, and by media type. This isn’t filtering each feed you put into a Grazr, it’s filtering the overall Grazr.

All your Grazr’s are hosted in the “Files” tab, here you can re-work your files, etc…
But they are also hosted in a blog view, so each Grazr you make becomes a blog post.

Here’s my Grazr blog, how cool is that.

Each of my Grazr’s is a blog post, and you can subscribe to the feed or OPML of each post.
My Grazr blog also has an overall OPML and RSS feed…hmmm, I could put my Grazr blog feed into FriendFeed.

From what I see the “file” and “blog” views are the same content in different views, it would probably be better if you had the option to choose which files to go into your blog view.

Imagine this for Flickr, etc…sure you have all your Flickr photos in a stream, but this is like your back-end. Imagine each time you add a Flickr photo, you had the option to add it to your Flickr blog, that way your Flickr blog showcases your best stuff. People would rather subscribe to your quality Flickr blog, instead of your main stream…plus a blog is a place to hangout.

Request

I was sent an email today along with 5 other people.

The email read something like, “Can everyone please email me a list of issues with [our system] and then [this person] will go through all the emails make a list in a document.”

This just screamed wiki to me.

This was an In-the-Flow collaborative process that could put email to shame.

I emailed Reply-to-All with a request to use a wiki, a good idea I thought, especially since we are piloting wikis.

I got the go ahead to create a wiki…”but hurry because we need this quick.”

Right on, a wiki is hawaiian for “quick” (a private laugh with myself at the time)

I created a wiki

I listed all my issues on the wiki index page.

Then I published a wikipage for each issue.

I had to go to a meeting so I left a note on the wiki index page that I would be back at 2.30pm.

When I got back I noticed some others had made contributions.

Someone made a contribution by Reply-to-All to the initial email.
They said that my contributions to the wiki covered what they would of contributed, but they also wanted to ask a question and also add one item to the list…so they sent an email instead of contributing to the wiki
I took the essence of it and put it on the wiki on their behalf…we need to discipline people out of old habits.

At this point I’m feeling that the lack of a comments module on the wiki is making our collaboration only half successful, as whatever the object is; a document, a wiki, you need to converse about this object, and you want this inhouse next to the object.

When I was finished, I left a note at the end of the index page

“John - I have finished all my contributions”

Later on I remembered another issue, so I whacked it in.

Then I discovered another issue and added it.

I decided to look at recent changes and noticed someone left a comment within a wikipage I created
(our wiki doesn’t have comments, instead at the end of a wikipage we are creating a line and under that line we can write comments/notes)

Later on I was with a colleague and noticed they were emailing the person in charge about a wikipage, ie. they were leaving a comment.
I suggested they still put it in the wiki in our workaround comments thread, and also email the person that way you are pinging that person, and other users of the wiki can visit and notice your contributions.

Again, I’m finding comments 50% of what makes a wiki work.

What we feel we really need

Comments
-The wiki use case was creating a communal list, so scratching a linear comment thread at the end of each actual wikipage was OK, but if the wikipage was something more presentable like a communal glossary then we don’t really want comments scratchings on the actual page, we’d rather a comments module.

Notifications
-If we do scratch a comment on an actual wikipage, we want to be notified by email (or RSS)
- and what about subscribing to the page itself it see if anyone has made changes to a page (you can go to the recent changes page, but having this as a delivered notification digest would be good)

eg. Wikispaces

Notifications for whole wiki
- Edits and Discussions
- Edits Only
- Discussions Only

Notifications for a wikipage
- Page Edits
- Page Discussion

What I liked about using wikis

It was never too late to add issues.
If I emailed my contributions, I would of had to email another two times for my two extra contributions.

I also didn’t have to email that I was in a meeting and I would resume my contributions at a later time.
And again I didn’t need to email that I was finished.
The person who left a comment/note on the wikipage I created didn’t have to email me, as he wrote it in the wiki.

I also discovered issues others contributed.
Which I would have not seen if we did not use a wiki, as they would have emailed it to the person in charge.

Yeah, no crap emails!

I just visit the wiki to see the progress and conversations.

In the ideal wiki I’d also be able to be notified of new edits and comments.

No need for the person in charge to spend time compiling all the emails, deleting the duplicates, and cutting ‘n pasting a list into a document.

The wiki is used for the process and is also the finished product, you can even export to another file type.

Yeah for wikis!
Yeah for no unnecessary emails!
Yeah for collaboration!
Yeah for visibility!
Yeah for conversations!
Yeah for notifications!
Yeah for a central home!
Yeah for transparency!
Yeah for simplicity!
Yeah for a ready-made end product!
Yeah for wikis!

UPDATE: I just realised I experienced the classic CommonCraft Wikis in Plain English

When a department has a change they think will affect the organisation as a whole they will send a broadcast email to the whole office.

In a past post I mentioned to perhaps also enter the email address of a blog, so the email can also be published in a blog (post to blog via email).

This way in the future we can consult the blog to remember what’s happened in the past (even derive a bit of analysis and patterns) rather than search through our emails, plus comments enable a two way interaction (valuable insight from the social captial).

Unless the whole office is subscribed to the blog, this still needs to be a broadcast email.

But what about changes that will not affect the whole enterprise, a department has to stop and think, who is going to need to know about these changes we are making.
What they do is find the relevant email groups and send the email announcement.

But have they reached everyone who needs to know…who knows?

Another scenario is a department makes some changes where they can’t forsee it affecting others, so they just communicate the announcement within their own team.

Or maybe they announce their changes to a few people in another department, but those people fail to pass the message on within their own team.

As we can see, there is too much cognitive stress in figuring out who your audience is, there is too much relying on others to let others know.

Scenario

I was on a Document Management Support call and I couldn’t work out why something was behaving different than usual.

My last resort was to ask the IT Support team to troubleshoot the problem.

After explaining the problem, IT told me they changed something in the system and that’s why I was having these issues. It seems they couldn’t forsee how their changes to the system affected my knowledge capability of supporting users.
The problem was easily resolved as I was verbally communicated the remedy.

The problem here is that it was reactionary, I had to have an issue and demand the solution, plus it was embarrasing as they use could clearly see that our departments aren’t communicating properly.

To conclude I was not privy to knowing about this change (nothing to do with privacy, moreso not being on the emai list), and I should have been as it affected my capacity to work, and ultimately wasted company time.

This is typical departmental communication silos, and it’s happening a milion times now in every organisation as I publish this post.

Solution is visibility

The remedy is so easy…we need more visibility, rather than using email and email lists.

Visibility is exactly what I posted about the other day. It’s no a big social enterprise 2.0 effort, it just has to be visible.

In this example if the IT department published this change in a blog announcement, they don’t have to forsee which people this change will affect, as the blog is visible and public for all to see.

As mentioned before thay could still email a list, but also email the blog email address, that way, others not on the email list, can wander over to the blog homepage and see what’s new, or they could even subscribe to the blog.

By just adding the blog email address to that communication we solve the problems in the scenario described above. All it takes is putting one more email address in your email, and you don’t have to worry about lacking to communicate to all the concerned parties.
In turn we have less confusion and embarrasment, and have not wasted time and money.

Visibility is the key.

Decisions, process and actions in one department will affect another, and it’s hard to speculate all parties that will be affected, so why not make this communication public, and others can tune in.

As I mentioned in my K-flow post:

Pull = RSS subscription
Push = email broadcast

We are pushing to who we think should know; we are certain they will get the message as we are pushing it into their inbox, and we can even get a receipt they have read the email.

We are also pushing the message to publish to a blog, without having to go to the blog.

People can visit or pull (subscribe) the new content from this blog
- now people we didn’t think of who should know may be informed

Conclusion

Without any extra effort other than including the blog email address:

- we are not changing the way we work
- we feel secure in knowing we have pushed the message to who should know
- we can also feel comfort in knowing that the public (visitors and blog subscribers) will know what’s going on
- we can visit the blog to see the history of announcement (rather than searching our email)
- people can leave comments for feedback, discussion, etc…

If we had an enterprise blog culture and I was confronted with the scenario above:

A. I would already know the answer as I subscribe to the right blogs

If I didn’t subscribe, I would visit…
B. my teams blog
C. the IT Changes blog

All this without me having to even talk with anyone, and without IT having to know that I should know.

Visibility is the key to communications.

Twitter PollDaddy - create a poll and send it to Twitter

TwitResponse - schedule your tweets in advance…also see TweetAhead and AutoTwit.

TwitterReply - if you use TwitterMail replies sent as emails is part of the package, but you can now just sign up for this feature alone.

TwitEarth - watch tweets spin around the globe…my tweet on TwitEarth has a permalink. Also see TwitterFaces, TwitterAtlas, Twitter Earth, and TwitterVision.

Twitimonials - send a tweet about your friends

BONUS LINK
Twitter Fixer - Twitter has just fixed its cache problems, one solution was to unfollow/refollow your friends, instead Twitter Fixer does this in one click.