<?xml version="1.0" encoding="utf-8"?><!-- generator="wordpress/1.5.1-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: K-flow</title>
	<link>http://libraryclips.blogsome.com/2008/04/22/k-flow/</link>
	<description>sharing ideas thoughts and feedback</description>
	<pubDate>Sat, 28 Nov 2009 16:20:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.1-alpha</generator>

	<item>
		<title>by: Johnt</title>
		<link>http://libraryclips.blogsome.com/2008/04/22/k-flow/#comment-32466</link>
		<pubDate>Mon, 28 Apr 2008 02:57:11 +0100</pubDate>
		<guid>http://libraryclips.blogsome.com/2008/04/22/k-flow/#comment-32466</guid>
					<description>James,

I like your post about &quot;batching&quot;, especially the bit about group protocols.
You can apply all the productivity tips for yourself and perhaps be a role-model, but unless others do the same you are still not changing the load of your inbox, all you are doing is working out how to manage it best. Like youself Jack Vinson feels the real problem is about &quot;input&quot;, in that how do we make people think about alternate ways before pressing send...and group behaviour protocols is the only way.
http://blog.jackvinson.com/archives/2008/03/31/yours_is_bigger_than_mine_ha_ha.html

The aim along with productivity is too have a smaller inbox load in the first place, and this will only work if the team/group/organisation (ouch!, that's a lot of people) is aware of not using email for certain messages, and instead using a more contextually appropriate tool as I mentioned in this post.
http://libraryclips.blogsome.com/2008/04/10/email-is-not-the-centre-of-my-universe

Email overload is an excellent excuse for social tools in the enterprise, these social tools don't have to be called web 2.0 or enterprise 2.0 rollout, instead they are called email overload tools, or whatever, as long as the name sounds like it's a solution to a current problem.

And like other enterprise 2.0 adoption techniques it's not a roll-out. Telling the whole organisation, this is how we are going to relieve email overload is not going to work, and plus different environments may require different techniques. So instead a viral and more contextual approach is needed to smaller groups...kind of an inside-out approach. 
Start off with a project or team and start using new &quot;think before you send an email techniques&quot;:
- Blog it - if it's an announcement, review, news, status, idea 
- Forum it - if it's a discussion
- Wiki it - if it's to collaborate
- etc...

These team members will want other projects and teams to use these approaches, so hopefully it will become viral where the workers want to work this way without the organisation having to command it.They will perhaps find themselves sending emails back to people reminding them to use the right tool for the right content...habits have to be broken, and there is nothing wrong with helping others by counselling them out of old habits. But the beauty of this is it's not the managers telling people of new email ettiquette, it's the workers themselves.</description>
		<content:encoded><![CDATA[	<p>James,</p>
	<p>I like your post about &#8220;batching&#8221;, especially the bit about group protocols.<br />
You can apply all the productivity tips for yourself and perhaps be a role-model, but unless others do the same you are still not changing the load of your inbox, all you are doing is working out how to manage it best. Like youself Jack Vinson feels the real problem is about &#8220;input&#8221;, in that how do we make people think about alternate ways before pressing send&#8230;and group behaviour protocols is the only way.<br />
<a href='http://blog.jackvinson.com/archives/2008/03/31/yours_is_bigger_than_mine_ha_ha.html' rel='nofollow'>http://blog.jackvinson.com/archives/2008/03/31/yours_is_bigger_than_mine_ha_ha.html</a></p>
	<p>The aim along with productivity is too have a smaller inbox load in the first place, and this will only work if the team/group/organisation (ouch!, that&#8217;s a lot of people) is aware of not using email for certain messages, and instead using a more contextually appropriate tool as I mentioned in this post.<br />
<a href='http://libraryclips.blogsome.com/2008/04/10/email-is-not-the-centre-of-my-universe' rel='nofollow'>http://libraryclips.blogsome.com/2008/04/10/email-is-not-the-centre-of-my-universe</a></p>
	<p>Email overload is an excellent excuse for social tools in the enterprise, these social tools don&#8217;t have to be called web 2.0 or enterprise 2.0 rollout, instead they are called email overload tools, or whatever, as long as the name sounds like it&#8217;s a solution to a current problem.</p>
	<p>And like other enterprise 2.0 adoption techniques it&#8217;s not a roll-out. Telling the whole organisation, this is how we are going to relieve email overload is not going to work, and plus different environments may require different techniques. So instead a viral and more contextual approach is needed to smaller groups&#8230;kind of an inside-out approach.<br />
Start off with a project or team and start using new &#8220;think before you send an email techniques&#8221;:<br />
- Blog it - if it&#8217;s an announcement, review, news, status, idea<br />
- Forum it - if it&#8217;s a discussion<br />
- Wiki it - if it&#8217;s to collaborate<br />
- etc&#8230;</p>
	<p>These team members will want other projects and teams to use these approaches, so hopefully it will become viral where the workers want to work this way without the organisation having to command it.They will perhaps find themselves sending emails back to people reminding them to use the right tool for the right content&#8230;habits have to be broken, and there is nothing wrong with helping others by counselling them out of old habits. But the beauty of this is it&#8217;s not the managers telling people of new email ettiquette, it&#8217;s the workers themselves.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Johnt</title>
		<link>http://libraryclips.blogsome.com/2008/04/22/k-flow/#comment-32464</link>
		<pubDate>Wed, 23 Apr 2008 10:15:23 +0100</pubDate>
		<guid>http://libraryclips.blogsome.com/2008/04/22/k-flow/#comment-32464</guid>
					<description>On behalf of James Dellow:

G'day,
 
I was having trouble posting this comment to your post here:
 
http://libraryclips.blogsome.com/2008/04/22/k-flow/
 
For some reason I couldn't find the &quot;submit&quot; button (could be an IE7 thing?)... anyway this is what I wanted to say:
 
Glad to hear you enjoyed Matt's podcast interview with me and for adding some more ideas to that conversation in your post. I actually agree with your comments about the push/pull point - after I said it I did wonder if I had them the right way around, but that's what you get for an unscripted interview in one take! On reflection, after reading your post, I'm not sure they are good terms to use at all - I recently blogged about Ross Mayfield's post about Streaming and Batching http://chieftech.blogspot.com/2008/04/streaming-and-batching.html , the &quot;stream&quot; bit reminds me in someways about your ideas for K-flow.

Thanks!
 
James</description>
		<content:encoded><![CDATA[	<p>On behalf of James Dellow:</p>
	<p>G&#8217;day,</p>
	<p>I was having trouble posting this comment to your post here:</p>
	<p><a href='http://libraryclips.blogsome.com/2008/04/22/k-flow/' rel='nofollow'>http://libraryclips.blogsome.com/2008/04/22/k-flow/</a></p>
	<p>For some reason I couldn&#8217;t find the &#8220;submit&#8221; button (could be an IE7 thing?)&#8230; anyway this is what I wanted to say:</p>
	<p>Glad to hear you enjoyed Matt&#8217;s podcast interview with me and for adding some more ideas to that conversation in your post. I actually agree with your comments about the push/pull point - after I said it I did wonder if I had them the right way around, but that&#8217;s what you get for an unscripted interview in one take! On reflection, after reading your post, I&#8217;m not sure they are good terms to use at all - I recently blogged about Ross Mayfield&#8217;s post about Streaming and Batching <a href='http://chieftech.blogspot.com/2008/04/streaming-and-batching.html' rel='nofollow'>http://chieftech.blogspot.com/2008/04/streaming-and-batching.html</a> , the &#8220;stream&#8221; bit reminds me in someways about your ideas for K-flow.</p>
	<p>Thanks!</p>
	<p>James
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
