<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Coaching Pillar: Situating</title>
	<atom:link href="http://anarchycreek.com/2009/11/24/coaching-pillar-situating/feed/" rel="self" type="application/rss+xml" />
	<link>http://anarchycreek.com/2009/11/24/coaching-pillar-situating/</link>
	<description>Towards a Way of Excellence</description>
	<lastBuildDate>Fri, 06 Jan 2012 00:33:30 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: Simon Kirk</title>
		<link>http://anarchycreek.com/2009/11/24/coaching-pillar-situating/comment-page-1/#comment-648</link>
		<dc:creator>Simon Kirk</dc:creator>
		<pubDate>Wed, 25 Nov 2009 13:26:48 +0000</pubDate>
		<guid isPermaLink="false">http://anarchycreek.com/?p=901#comment-648</guid>
		<description>Would you say that&#039;s the general pattern of the way to situate a function (team, business, whatever) with the problem of being badly situated (or not situated at all): To find the various parties that want something from them, quantify those wants (decipher the details) and arrive at a suitable suggestion?

Of course the chances are most of those wants are cyclical, such as with your example. I&#039;m thinking that&#039;s probably why situating a business feel much more difficult as there are inevitably a far wider spectrum of demands on the entity.

I still think you&#039;re right that identifying all the parties who want something from the badly situated entity (and vice versa) is the first and hardest step (hence &quot;Everything else is details&quot;, though I&#039;m glad you didn&#039;t include the word &quot;just&quot; :).</description>
		<content:encoded><![CDATA[<p>Would you say that&#8217;s the general pattern of the way to situate a function (team, business, whatever) with the problem of being badly situated (or not situated at all): To find the various parties that want something from them, quantify those wants (decipher the details) and arrive at a suitable suggestion?</p>
<p>Of course the chances are most of those wants are cyclical, such as with your example. I&#8217;m thinking that&#8217;s probably why situating a business feel much more difficult as there are inevitably a far wider spectrum of demands on the entity.</p>
<p>I still think you&#8217;re right that identifying all the parties who want something from the badly situated entity (and vice versa) is the first and hardest step (hence &#8220;Everything else is details&#8221;, though I&#8217;m glad you didn&#8217;t include the word &#8220;just&#8221; <img src='http://anarchycreek.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> .</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: GeePawHill</title>
		<link>http://anarchycreek.com/2009/11/24/coaching-pillar-situating/comment-page-1/#comment-647</link>
		<dc:creator>GeePawHill</dc:creator>
		<pubDate>Wed, 25 Nov 2009 13:08:10 +0000</pubDate>
		<guid isPermaLink="false">http://anarchycreek.com/?p=901#comment-647</guid>
		<description>Interesting thought indeed. 

A side note: I had a team a little bit ago. The testers had told me pre-retrospective that they were unhappy with dev&#039;s fairly casual approach to staying in touch.  Ten minutes into the retro, dev expressed frustration that testing couldn&#039;t turn results around fast enough.
Bingo. I situated them both: &quot;Dev has something testing wants, and testing has something dev wants. Everything else is details.&quot;</description>
		<content:encoded><![CDATA[<p>Interesting thought indeed. </p>
<p>A side note: I had a team a little bit ago. The testers had told me pre-retrospective that they were unhappy with dev&#8217;s fairly casual approach to staying in touch.  Ten minutes into the retro, dev expressed frustration that testing couldn&#8217;t turn results around fast enough.<br />
Bingo. I situated them both: &#8220;Dev has something testing wants, and testing has something dev wants. Everything else is details.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Kirk</title>
		<link>http://anarchycreek.com/2009/11/24/coaching-pillar-situating/comment-page-1/#comment-646</link>
		<dc:creator>Simon Kirk</dc:creator>
		<pubDate>Wed, 25 Nov 2009 12:46:13 +0000</pubDate>
		<guid isPermaLink="false">http://anarchycreek.com/?p=901#comment-646</guid>
		<description>&quot;The hardest part of coaching for me is the part where I have to puzzle out the next right act.&quot;

Oh yes, right on the nail, spot on, etc. Sometimes the fear of making a wrong action for a team can just *paralyse* me. Though these days I&#039;m fairly confident with teams, it&#039;s the next right act for the business that&#039;s troubling me.

Which is an interesting thought: situating is equally applicable to the business, as well as a team...</description>
		<content:encoded><![CDATA[<p>&#8220;The hardest part of coaching for me is the part where I have to puzzle out the next right act.&#8221;</p>
<p>Oh yes, right on the nail, spot on, etc. Sometimes the fear of making a wrong action for a team can just *paralyse* me. Though these days I&#8217;m fairly confident with teams, it&#8217;s the next right act for the business that&#8217;s troubling me.</p>
<p>Which is an interesting thought: situating is equally applicable to the business, as well as a team&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

