Library clips

This post is an idea, thinking out loud, something to build upon, or perhaps something that is a bad idea…see what you think.

This is a follow-up to my post, Re-purposing email meme, which explained the email problem (overload, siloed) and how a “re-purposing email” idea with social tools can help reduce the anxiety and act as a catalyst for an open, collaborative, conversational and emergent social enterprise.

One thing to note is that you don’t save or waste time, you spend the same amount of time, only spread across various tools…what you are doing is spending your time more wisely (social productivity).

The focus of a future post will be examples of emails, and in what way they can be re-purposed.

But for now I want to examine exactly how blog communication is going to replace email, except emails for private or sensitive one-to-one correspondence.

This post is only about one type of blog use, and that is “communications“.
This is an In-the-Flow usage scenario as the concept is to use blogs instead of email for something we are already doing…this is not an extra thing we have to do, it’s substituting a tool.

This post does not include Above-the-Flow blog (sharing tacit knowledge) uses like:

- Personal/Group blogs (experiences, “thoughts out loud”, ideas, reviews, opinions, “work in progress”)
- Tips and Tricks blog
- Topic blogs
- etc…

If blogs are to replace team and cross-team communication I’ve realised blog channels are required.
Reason being is that when you email a communication, it may be to a:
- team email group
- sub-team email group
- directed at only two sub-team email groups
- directed at 3 out of 10 people in a sub-team
- directed to a team in another business unit
- directed to just two teams in another business unit
- directed to the whole office

I call these mesh blogs, as most blogs above are dedicated to 2 or more email groups.
This makes a blog two way in the sense that it can be a channel for 2 email goups to communicate through.
eg. In email you would have a manager emailing a “communication” to sub-team group
To: DM Support group
From: A DM Management member

Or a sub-team group member emailing a “communication” to the manager group
To: DM Management group
From: A DM support member

Now both these groups can “communicate” or broadcast announcements to each other through a mesh blog called “DM Management-Support blog”.

Both these email or Active Directory groups are auto-subscribed to the blog.
People from other sub-teams are welcome to manually subscribe to the blog.
People from other business units (permissions based) may also be welcome to visit the blog page or subscribe to the blog.

This is openess at it’s best, with visible and centralised content (corporate memory), where conversations (comments) are seen by all…content can evolve.

Other business units may want to point to a blog post in the “DM Management-Support blog” in one of their own blogs as a way to inform their own team…this is the beginnings of an open internal blogosphere.

NOTE: DM is Document Management - this is an example of a team or business unit

Issues

Now what about if the DM Management group wanted to communicate an annoucement to both the DM Support and DM Sys Admin, but not the other sub-teams within this business unit.

Would they cross post in the “DM Management-Support blog”, and the “DM Management-Sys Admin blog”?
Not sure about duplicate posts, as conversations will be fragmented.

If there are often communications directed at both these sub-teams communications, then maybe another blog is required, such as a “DM Management-Support-Sys Admin blog”

If the communication is directed to the whole team then it could be posted in the “DM All Team blog”

The reason I came up with the concept of a “mesh blog”, that is conceived to only serve 2 parties, is to overcome the subscriber issue and occupational spam.

Sometimes communications are not directed at your whole team, and if your whole team is subscribed to your blog, they will get new posts not directly concerning them.
This can be avoided using email as you can push the communication to just one group of people.
But at the same time it’s not an email silo, it’s visible for others to see or even subscribe to.

For an Above-the-Flow blog like a “Tips and Tricks” blog, a non-mesh approach is OK, you publish stuff and people with an interest in your stuff will subscribe.

This is where I get stuck, what if your communication is to your “All team blog”, and also to 2 other business units.

Well maybe this type of communcation could be posted on your “All team External blog”, where your whole team is subscribed and the leads of other business units. Then these business unit leads can point to this blog post in their own teams blog.

But again if there are 10 business unit leads, this post will be spam to 8 business unit leads.
At the same time, it is good for “leads” to be aware of what’s happening around the enterprise.

I guess this is the problem in enterprises at the moment, in that email is a closed system, where people in other business units are not in the loop…I’ve posted on this in the past.
With mesh blogs, even if they are not auto-subscribed, the communication is still visible to visit at the blog page, and they could choose to manually subscribe themselves.

So what was once an email to an email group, is now a blog dedicated to communications between these 2 groups, where blog posts to those same people in the email group (as they are auto-subscribed) are being delivered, and a clean conversation can happen in the comments.

The added value is that what was once a closed email communication, can now be subscribed to by others by their own choice, or they can visit the blog page.

I like that the existence of these pre-made channel like blogs welcome communications within sub-teams and across business units.
Email groups are there for you to post to a whole group if you want to, but having a blog channel as a place dedicated to 2 groups to communicate kind of welcomes or expects communication.

Cross-team awareness is the foundations of a competitive edge that creates conditions for inter-disciplinary conversations, which is a way to innovation…see more.

Tasks

Another issue I had was with emails that contain a task, whether it’s emailed to 1 person or 4 people.

In this case perhaps a wikipage can contain the task, and the wikipage comments can inform of progress and discussion. The wikipage can also have a subscriptions feature for all to be in the loop on the latest version without having to email each other.

Another option is a task specific tool like Activities from Lotus Connections.

In this case of tasks, perhaps email can be used to invite people to the wiki…in this instance blogs are not a suitable tool for this use case.

If a task is part of a bigger task or a project within a team, perhaps a taskforce (community of practice) can be used where members of this community can communicate and collaborate using wikis, blogs, and forums.

NOTE: I’m not referring to client projects, I’m refering to projects/tasks within a team

Team relationships

As I’ve explained above, in relation to “communications” (not Tips and Tricks blogs and the like), I have found each sub-team needs a blog for themselves and separate blogs to deliver communications to each other sub-team, I’ve called these “mesh blogs”.
They are almost an email/blog hybrid in a sense, or perhaps an open email channel.

To really blur the line, there could also be the availability to receive new posts in an email, publish new posts by email, and post comments by email.

If the team (business unit) is small eg. 10 people in an organisation of 100 people, well then perhaps there would not be much occupational spam (I suppose it also depends on the frequency of posts). In this case maybe mesh blogs would not be required, each sub-team could have a blog, and each sub-team could subscribe to each others blogs.
As a support person I wouldn’t be thrilled about getting 3 posts a day from the development blog about stuff I have no clue about, just in the case that they have a once in a while post that I need to know.
But then as a support person I wouldn’t need to subscribe to the development blog, as when they have something to say to the support team, they can post it on the All team blog.
If I like I can visit the development blog to be in the know about stuff that would have usually been closed in email.

Another thing to consider is instead of all these mesh blogs, they could be reduced to categories on a few blogs, and the correct sub-team subscribes to the correct category feeds.

This post is about enterprise business unit or teams, but the same concept could also be applied to bigger sized communities of practice and projects.

Before we start we need to know the relationship between the sub-teams, and from this we can create our list of blogs…here’s a team and it’s sub-teams.

DOCUMENT MANAGEMENT (TEAM or UNIT)
SUB-TEAMS
Executive
Management
Development
Sys Admin
Support

On top of the blogs below, each sub-team could have blogs to cross unit teams or sub-teams
eg. DM sys admin -IT sys admin blog
This is a channel for 2 cross unit sub-teams to communicate.

Another consideration is blogs could further be divided by location, or by function
eg.
DM Support team Perth blog
Server status blog
New release blog
etc…

Here are a list of the blogs for a business unit or team such as Document Management

1. DM All team blog
2. DM All team External (to rest of the organisation) blog

3. DM Management team Internal blog
4. DM Development team Internal blog
5. DM Support team Internal blog
6. DM Sys Admin team Internal blog
7. DM Executive team Internal blog

8. DM Management-Sys Admin team blog
9. DM Management-Support team blog
10. DM Management-Executive team blog
11. DM Management-Development team blog
12. DM Executive-Development team blog
13. DM Development-Sys Admin team blog
14. DM Support-Sys Admin team blog

These really look like proper channels for open communication.

Subscriptions

Any team member can subscribe to any blog.

But most subscriptions are already done at the group level via auto-subscribing groups (or individuals)
- a typical example is members of the DM Support team and the DM Sys Admin team are automatically subscribed to the “DM Support-Sys Admin team blog”

Exceptions

DM DEVELOPMENT TEAM
This team doesn’t really speak to the DM Support team
- they can go through the DM Sys Admin team which have a closer relationship with the DM Support Team
- ie. they can publish a post to the “DM Development-Sys Admin team blog”

DM SUPPORT TEAM
This team doesn’t really speak to the DM Executive team
- they can go through the DM Management team which have a closer relationship with the DM Executive Team
- ie. they can publish a post to the “DM Support-Management team blog”

This team doesn’t really speak to the DM Development team
- they can go through the DM Sys Admin team or the DM Management team which have a closer relationship with the Development Team
- ie. they can publish a post to the “DM Support-Sys Admin team blog” or the “DM Management-Support team blog”

DM SYS ADMIN TEAM
This team doesn’t really speak to the DM Executive team
- they can go through the DM Management team which have a closer relationship with the DM Executive Team
- ie. they can publish a post to the “DM Management-Sys Admin team blog”

DM EXECUTIVE TEAM
This team doesn’t really speak to the DM Support team
- they can go through DM Management team which have a closer relationship with the DM Support Team
- ie. they can publish a post to the “DM Management-Executive team blog”

This team doesn’t really speak to the DM Sys Admin team
- they can go through DM Management team which have a closer relationship with the DM Sys Admin Team
- ie. they can publish a post to the “DM Management-Executive team blog”

Conclusion

This post sounds like a lot of setting up (would it get confusing in a large organisation), perhaps it would be easier for all teams and sub-teams to have non-mesh blogs…that is, regular blogs that people can subscribe to be in the loop. The problem here is since regular blogs are not targeted directly to a group of people, you may have to get 30 unrelated emailed for every related email.

My idea was to leverage what we do with email, but augment it by meshing 2 email groups together with their own unique communication space…which is also visible for others to see or even subscribe to.

As I mentioned mesh blogs are probably not needed in small organisations, as long as the level of posts that are not directly related to you don’t outweigh the posts that are relevant (noise to signal ratio).
To re-iterate perhaps as a member of one sub-team, you wouldn’t need to subscribe to another sub-teams blog, because when that sub-team wants to communication something to your sub-team, they would use the All team blog.
Posting on the All team blog means the other sub-teams will also see this post, but I think this is negligible.

Or as I also mentioned perhaps blog by function would be better, only problem is what if a blog doesn’t exist for the type of communication you want to deliver, whereas mesh blogs are generic.

What do people think about the mesh blog idea, please leave a comment.