<?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: Question of the Week: How much ambiguity does your team permit when assigning a task to a team member?</title>
	<atom:link href="http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/</link>
	<description>Shedding Light on the Hidden World of Embedded Systems</description>
	<lastBuildDate>Mon, 28 Jul 2014 16:18:37 -0400</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Anonymous @EM</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-887</link>
		<dc:creator>Anonymous @EM</dc:creator>
		<pubDate>Thu, 10 Jun 2010 21:09:42 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-887</guid>
		<description>Ambiguity is basically a form of slack management. It leaves gaping holes in specifications and can lead to disastrous products. I believe in spending time up front in specifying a project as much as possible. There should be a requirement document that highlights all the architectural considerations along with all the interface standards. The document may be open for other engineers to define their modules/functions. Those functions would be added into the final document. In the ASIC world and the high speed fault-tolerant world there is no guessing!</description>
		<content:encoded><![CDATA[<p>Ambiguity is basically a form of slack management. It leaves gaping holes in specifications and can lead to disastrous products. I believe in spending time up front in specifying a project as much as possible. There should be a requirement document that highlights all the architectural considerations along with all the interface standards. The document may be open for other engineers to define their modules/functions. Those functions would be added into the final document. In the ASIC world and the high speed fault-tolerant world there is no guessing!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: R.A. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-886</link>
		<dc:creator>R.A. @LI</dc:creator>
		<pubDate>Mon, 07 Jun 2010 14:54:17 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-886</guid>
		<description>&quot;With that constraint in mind, I would expect that the project lead would assign those tasks with the most unresolved ambiguity to the senior members, and assign the tasks with the least unresolved ambiguities to the junior members. Those tasks assigned to junior members would be low risk and relatively straight forward to recover from by a senior member in the event of a poor outcome. &quot;

I would expect that the project lead would assign the appropriate task to the appropriate resource. I believe that pre-conceived notions regarding the inherent superiority of senior resources for any particular task are both illogical and ill-conceived.</description>
		<content:encoded><![CDATA[<p>&#8220;With that constraint in mind, I would expect that the project lead would assign those tasks with the most unresolved ambiguity to the senior members, and assign the tasks with the least unresolved ambiguities to the junior members. Those tasks assigned to junior members would be low risk and relatively straight forward to recover from by a senior member in the event of a poor outcome. &#8221;</p>
<p>I would expect that the project lead would assign the appropriate task to the appropriate resource. I believe that pre-conceived notions regarding the inherent superiority of senior resources for any particular task are both illogical and ill-conceived.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Cravotta</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-885</link>
		<dc:creator>Robert Cravotta</dc:creator>
		<pubDate>Mon, 07 Jun 2010 06:12:18 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-885</guid>
		<description>I should probably clarify. I do not advocate injecting ambiguity into a project for the sake of developing a junior member&#039;s growth. However, in any project that is performing something new or novel, there is necessarily some uncertainty in the specifications. It may not be practical for the project lead to resolve all of the ambiguities in the specification before assigning tasks to the other team members - it is this time constraint that provides the source of ambiguity that I refer to in my question.

With that constraint in mind, I would expect that the project lead would assign those tasks with the most unresolved ambiguity to the senior members, and assign the tasks with the least unresolved ambiguities to the junior members. Those tasks assigned to junior members would be low risk and relatively straight forward to recover from by a senior member in the event of a poor outcome.</description>
		<content:encoded><![CDATA[<p>I should probably clarify. I do not advocate injecting ambiguity into a project for the sake of developing a junior member&#8217;s growth. However, in any project that is performing something new or novel, there is necessarily some uncertainty in the specifications. It may not be practical for the project lead to resolve all of the ambiguities in the specification before assigning tasks to the other team members &#8211; it is this time constraint that provides the source of ambiguity that I refer to in my question.</p>
<p>With that constraint in mind, I would expect that the project lead would assign those tasks with the most unresolved ambiguity to the senior members, and assign the tasks with the least unresolved ambiguities to the junior members. Those tasks assigned to junior members would be low risk and relatively straight forward to recover from by a senior member in the event of a poor outcome.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: forex robot</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-884</link>
		<dc:creator>forex robot</dc:creator>
		<pubDate>Sun, 06 Jun 2010 07:11:17 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-884</guid>
		<description>Keep posting stuff like this i really like it</description>
		<content:encoded><![CDATA[<p>Keep posting stuff like this i really like it</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: R.A. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-883</link>
		<dc:creator>R.A. @LI</dc:creator>
		<pubDate>Sat, 05 Jun 2010 23:31:32 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-883</guid>
		<description>&quot;If a particular person is not capable you might end up either with a failed project or a mediocre delivery&quot;

If the individual is not capable, fully specifying the task won&#039;t help and you&#039;ll still end up with a failed, or (at best) a mediocre product.

OTOH if the individual is capable and you tie their hands; you pretty much guarantee that you will get a mediocre work product (because, in anything other than trivial cases, only the individual who actually does the work is really capable of putting together the optimal detailed design).

Of course, the capable individuals occasionally ignore the over-specified design, and do what&#039;s right anyway :-)</description>
		<content:encoded><![CDATA[<p>&#8220;If a particular person is not capable you might end up either with a failed project or a mediocre delivery&#8221;</p>
<p>If the individual is not capable, fully specifying the task won&#8217;t help and you&#8217;ll still end up with a failed, or (at best) a mediocre product.</p>
<p>OTOH if the individual is capable and you tie their hands; you pretty much guarantee that you will get a mediocre work product (because, in anything other than trivial cases, only the individual who actually does the work is really capable of putting together the optimal detailed design).</p>
<p>Of course, the capable individuals occasionally ignore the over-specified design, and do what&#8217;s right anyway <img src='http://www.embeddedinsights.com/channels/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: S.N. @LI</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-882</link>
		<dc:creator>S.N. @LI</dc:creator>
		<pubDate>Sat, 05 Jun 2010 23:30:42 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-882</guid>
		<description>Robert,
I fully agree with you on two things one is leaving certain amount of uncertainty helps the junior engineers to evolve and with seniority our ability to absorb uncertainty should also increase.
However we should carefully evaluate the degree of uncertainty an individual can handle. If a particular person is not capable you might end up either with a failed project or a mediocre delivery.

Thanks
S.</description>
		<content:encoded><![CDATA[<p>Robert,<br />
I fully agree with you on two things one is leaving certain amount of uncertainty helps the junior engineers to evolve and with seniority our ability to absorb uncertainty should also increase.<br />
However we should carefully evaluate the degree of uncertainty an individual can handle. If a particular person is not capable you might end up either with a failed project or a mediocre delivery.</p>
<p>Thanks<br />
S.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: B. @EM</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-881</link>
		<dc:creator>B. @EM</dc:creator>
		<pubDate>Thu, 03 Jun 2010 20:12:09 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-881</guid>
		<description>&lt;p&gt;And then there is also the problem that some managers come back and make all your work obsolete since you did not design what they had in mind, simply because the parameters you were given were not sufficient to know what was required.&lt;/p&gt;
&lt;p&gt;Ingenuity for the design phase is desirable, but the requirements have to be well defined to come up with a meaningful solution.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>And then there is also the problem that some managers come back and make all your work obsolete since you did not design what they had in mind, simply because the parameters you were given were not sufficient to know what was required.</p>
<p>Ingenuity for the design phase is desirable, but the requirements have to be well defined to come up with a meaningful solution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: N. @EM</title>
		<link>http://www.embeddedinsights.com/channels/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-880</link>
		<dc:creator>N. @EM</dc:creator>
		<pubDate>Thu, 03 Jun 2010 03:39:04 +0000</pubDate>
		<guid isPermaLink="false">http://robert.blogs.embeddedinsights.com/2010/06/02/question-of-the-week-how-much-ambiguity-does-your-team-permit-when-assigning-a-task-to-a-team-member/#comment-880</guid>
		<description>&lt;p&gt;Zero ambiguity!&lt;br /&gt;
I practice your advice 15 years ago and found that it takes fare more time for the junior to come with the right conclusion. Unfortunately our small design team has to move fast. There is no time for plan B. Customers prefer our services as we move fast and for that reason cost less. If we trim ambiguity to zero at all levels project takes a lot less.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Zero ambiguity!<br />
I practice your advice 15 years ago and found that it takes fare more time for the junior to come with the right conclusion. Unfortunately our small design team has to move fast. There is no time for plan B. Customers prefer our services as we move fast and for that reason cost less. If we trim ambiguity to zero at all levels project takes a lot less.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
