<?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: The Art of Posing a Problem</title>
	<atom:link href="http://blog.ezyang.com/2010/02/art-of-posing-a-problem/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.ezyang.com/2010/02/art-of-posing-a-problem/</link>
	<description>Existential Pontification and Generalized Abstract Digressions</description>
	<lastBuildDate>Tue, 21 Feb 2012 05:30:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Kevin Riggle</title>
		<link>http://blog.ezyang.com/2010/02/art-of-posing-a-problem/comment-page-1/#comment-118</link>
		<dc:creator>Kevin Riggle</dc:creator>
		<pubDate>Sun, 28 Feb 2010 01:48:55 +0000</pubDate>
		<guid isPermaLink="false">http://blog.ezyang.com/?p=663#comment-118</guid>
		<description>&lt;i&gt;Many projects are extremely large and complex, and in many cases it&#039;s simply not possible to assign someone an interesting, high-level project and expect them to make significant headway.&lt;/i&gt;

Thinking about your points in the context of my experience with MITSFS, I find it depends a lot on the person.  There are people to whom I can give a large, complex project, and they&#039;ll approach it, break it down, come back to me as they have questions, and eventually bring back an excellent result.  Other people need more hand-holding, and some people are completely incapable of functioning on their own (though at least in the context of MITSFS they tend to go away quickly).  Figuring out where any particular person falls in this is an important skill as a manager.  I&#039;ll often start by tossing someone a big, poorly-defined project.  If they can handle it, great; if they&#039;re still around but not making any headway after some amount of time, I&#039;ll take them off that and give them something better specified to do.  Doing the big complicated projects is also a skill people develop, so I watch people and give them bigger things if I think they&#039;ve developed the skills to handle them.

&lt;i&gt;No one ever tells you what they&#039;re interested in!&lt;/i&gt;

I find it really hard to tell someone &lt;i&gt;a priori&lt;/i&gt; what I&#039;m interested in, and I think other people do too.  I find it works a lot better for the person posing the project to lay out some of the options and then let me choose or narrow from there.

&lt;i&gt;It&#039;s easy to exert too much or too little control over the direction of the project. [...] Too little control and the person can easily get lost or waste hours fighting incidental issues and not the core of the problem.&lt;/i&gt;

See above about figuring out how much oversight people need, with the caveat that there&#039;s often utility to letting people try something their own way and fail first, if that&#039;s what they want to do, and &lt;i&gt;then&lt;/i&gt; come to you for guidance.  That&#039;s a much more powerful and long-lasting learning experience than doing exactly what you told them.

&lt;i&gt;Being a proper mentor is a time-consuming process, even if you exert minimal control. [...] You might wonder why you didn&#039;t just do the damn task yourself.&lt;/i&gt;

Yup.  It&#039;s hard to avoid.  Ultimately you&#039;re trying to &lt;i&gt;build&lt;/i&gt; people to whom you can give a poorly-specified problem and who will then go off and solve it, so if you can think of your time as an investment towards that goal, it becomes more worthwhile.

&lt;i&gt;As people refine the art of bootstrapping, the number of possible projects they can work on explode, and what makes you think that they&#039;re going to work on your project? [...] if you don&#039;t get the person to buy in, you can easily loose them.&lt;/i&gt;

Yup.  The best solution to this I&#039;ve found is to throw as many people as you have at as many kinds of problems as possible, and when somebody gets bored or burned-out, find something else for them to try.  The people who like a project and have bought into it will stick, and your organization as a whole will be a lot happier if everybody is doing more-or-less what they enjoy.</description>
		<content:encoded><![CDATA[<p><i>Many projects are extremely large and complex, and in many cases it&#8217;s simply not possible to assign someone an interesting, high-level project and expect them to make significant headway.</i></p>
<p>Thinking about your points in the context of my experience with MITSFS, I find it depends a lot on the person.  There are people to whom I can give a large, complex project, and they&#8217;ll approach it, break it down, come back to me as they have questions, and eventually bring back an excellent result.  Other people need more hand-holding, and some people are completely incapable of functioning on their own (though at least in the context of MITSFS they tend to go away quickly).  Figuring out where any particular person falls in this is an important skill as a manager.  I&#8217;ll often start by tossing someone a big, poorly-defined project.  If they can handle it, great; if they&#8217;re still around but not making any headway after some amount of time, I&#8217;ll take them off that and give them something better specified to do.  Doing the big complicated projects is also a skill people develop, so I watch people and give them bigger things if I think they&#8217;ve developed the skills to handle them.</p>
<p><i>No one ever tells you what they&#8217;re interested in!</i></p>
<p>I find it really hard to tell someone <i>a priori</i> what I&#8217;m interested in, and I think other people do too.  I find it works a lot better for the person posing the project to lay out some of the options and then let me choose or narrow from there.</p>
<p><i>It&#8217;s easy to exert too much or too little control over the direction of the project. [...] Too little control and the person can easily get lost or waste hours fighting incidental issues and not the core of the problem.</i></p>
<p>See above about figuring out how much oversight people need, with the caveat that there&#8217;s often utility to letting people try something their own way and fail first, if that&#8217;s what they want to do, and <i>then</i> come to you for guidance.  That&#8217;s a much more powerful and long-lasting learning experience than doing exactly what you told them.</p>
<p><i>Being a proper mentor is a time-consuming process, even if you exert minimal control. [...] You might wonder why you didn&#8217;t just do the damn task yourself.</i></p>
<p>Yup.  It&#8217;s hard to avoid.  Ultimately you&#8217;re trying to <i>build</i> people to whom you can give a poorly-specified problem and who will then go off and solve it, so if you can think of your time as an investment towards that goal, it becomes more worthwhile.</p>
<p><i>As people refine the art of bootstrapping, the number of possible projects they can work on explode, and what makes you think that they&#8217;re going to work on your project? [...] if you don&#8217;t get the person to buy in, you can easily loose them.</i></p>
<p>Yup.  The best solution to this I&#8217;ve found is to throw as many people as you have at as many kinds of problems as possible, and when somebody gets bored or burned-out, find something else for them to try.  The people who like a project and have bought into it will stick, and your organization as a whole will be a lot happier if everybody is doing more-or-less what they enjoy.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

