<?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: Dear Developer</title>
	<atom:link href="http://blog.arc90.com/2008/01/10/dear-developer/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.arc90.com/2008/01/10/dear-developer/</link>
	<description>Web Application Design &#38; Development</description>
	<lastBuildDate>Thu, 29 Jul 2010 10:34:30 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Pete Park</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-458</link>
		<dc:creator>Pete Park</dc:creator>
		<pubDate>Fri, 19 Sep 2008 17:28:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-458</guid>
		<description>* Tim Meaney is a colleague at Arc90.
This is a very expressive post in which you&#039;ve high-lighted your personal experience of &quot;transitioning&quot; from developer to product manager, yet you&#039;re still a developer at heart. Your skillset is a rarity and a huge benefit to your team.
I&#039;ve worked with a lot of developers on different s/w projects in my career and always had to establish my expectations in a collaborative effort from the onset. I always remind them that s/w is an experience to the user&#039;s benefit, not a checklist of things to throw over the wall. We&#039;re all working hard together. Moreover, the initial specs that you define as a product manager may not be exactly what the market really wants at the end, so you always have the probability of changing direction. Therefore, product managers walk the precarious tricky tightrope act of listening to the client / market needs while making sure engineering is developing the product. The definition of execution and getting things done is elusive. For example, sometimes wait and see is the wisest approach (which hard to control when you have a million deadlines to manage), because the engineers don&#039;t want to change direction at every new possibility. Also, I observed that engineers are most productive in spurts, so it&#039;s hard to grind the productivity 24 x 7. Deadlines must be followed, yet a talented engineer will deliver their code in a reasonable amount of time.
This presents 2 extreme cases: Being too flexible with your specs will impede development, whereas Being too rigid with your requirements may not please your customer base. After all, what good is s/w if it doesn&#039;t suffice the needs of the end-user? The thing about internet s/w these days is that there are so many options, and switching costs are minimal.
As for the internal culture between developers and product managers, this depends on every organization&#039;s culture. Every organization has to define their own equilibrium and measure their productivity and qualitative metrics. The goal is to create a culture of transparency and empathy. Engineering needs to understand that their livelihood is contingent on satisfied &quot;paying&quot; customers; product managers need to understand that engineers work best when they have clear, detailed specs that don&#039;t change every day and to limit distractions. For instance, this is what google as they established their culture in the 2001-2003 timeframe by not having any phones for engineers (I don&#039;t if is still the case today) for less disruption.
IMHO, I assert that product managers and technical leads are ultimately responsible to keep developers on track and in the loop. Otherwise, it&#039;s far too easy to calcify departments into a Us vs. Them culture, which plagues many technology firms all over the world. Another qualitative issue is motivation. Product Managers often are not only coaches but cheerleaders. We must keep the morale high and praise team members when they contribute to the project, even when it&#039;s an unpopular viewpoint. Teams of people are capable of producing awesome, cutting edge products with great communication and a optimistic attitude.</description>
		<content:encoded><![CDATA[<p>* Tim Meaney is a colleague at Arc90.<br />
This is a very expressive post in which you&#8217;ve high-lighted your personal experience of &#8220;transitioning&#8221; from developer to product manager, yet you&#8217;re still a developer at heart. Your skillset is a rarity and a huge benefit to your team.<br />
I&#8217;ve worked with a lot of developers on different s/w projects in my career and always had to establish my expectations in a collaborative effort from the onset. I always remind them that s/w is an experience to the user&#8217;s benefit, not a checklist of things to throw over the wall. We&#8217;re all working hard together. Moreover, the initial specs that you define as a product manager may not be exactly what the market really wants at the end, so you always have the probability of changing direction. Therefore, product managers walk the precarious tricky tightrope act of listening to the client / market needs while making sure engineering is developing the product. The definition of execution and getting things done is elusive. For example, sometimes wait and see is the wisest approach (which hard to control when you have a million deadlines to manage), because the engineers don&#8217;t want to change direction at every new possibility. Also, I observed that engineers are most productive in spurts, so it&#8217;s hard to grind the productivity 24 x 7. Deadlines must be followed, yet a talented engineer will deliver their code in a reasonable amount of time.<br />
This presents 2 extreme cases: Being too flexible with your specs will impede development, whereas Being too rigid with your requirements may not please your customer base. After all, what good is s/w if it doesn&#8217;t suffice the needs of the end-user? The thing about internet s/w these days is that there are so many options, and switching costs are minimal.<br />
As for the internal culture between developers and product managers, this depends on every organization&#8217;s culture. Every organization has to define their own equilibrium and measure their productivity and qualitative metrics. The goal is to create a culture of transparency and empathy. Engineering needs to understand that their livelihood is contingent on satisfied &#8220;paying&#8221; customers; product managers need to understand that engineers work best when they have clear, detailed specs that don&#8217;t change every day and to limit distractions. For instance, this is what google as they established their culture in the 2001-2003 timeframe by not having any phones for engineers (I don&#8217;t if is still the case today) for less disruption.<br />
IMHO, I assert that product managers and technical leads are ultimately responsible to keep developers on track and in the loop. Otherwise, it&#8217;s far too easy to calcify departments into a Us vs. Them culture, which plagues many technology firms all over the world. Another qualitative issue is motivation. Product Managers often are not only coaches but cheerleaders. We must keep the morale high and praise team members when they contribute to the project, even when it&#8217;s an unpopular viewpoint. Teams of people are capable of producing awesome, cutting edge products with great communication and a optimistic attitude.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: qwick cover</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-457</link>
		<dc:creator>qwick cover</dc:creator>
		<pubDate>Tue, 03 Jun 2008 04:23:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-457</guid>
		<description>Goes back to the same old saying, &quot;Communication is key.&quot;</description>
		<content:encoded><![CDATA[<p>Goes back to the same old saying, &#8220;Communication is key.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: T1 Mike</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-456</link>
		<dc:creator>T1 Mike</dc:creator>
		<pubDate>Fri, 18 Jan 2008 23:47:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-456</guid>
		<description>Interesting article. Good to know that people are opening up to newer ideas.</description>
		<content:encoded><![CDATA[<p>Interesting article. Good to know that people are opening up to newer ideas.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-455</link>
		<dc:creator>Tim</dc:creator>
		<pubDate>Fri, 11 Jan 2008 04:05:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-455</guid>
		<description>Claus:  You picked up on an important point - I was writing this to express the feeling &quot;we&quot; have, not attempting to say that we&#039;re right.  I fully appreciate the creative process that writing good software demands.  At Arc90, we&#039;re so bought into this concept that we don&#039;t have core hours.  Developers give so much more of themselves to their work when it&#039;s on their terms, I&#039;ve seen it played out time and time again for years.
However, that doesn&#039;t change the feeling we have - which is sometimes one of frustration at your methods.  I wrote this with some hyperbole in order to put forth a point.  Don&#039;t take me all too seriously - I know exactly why you&#039;re leaving at a reasonable hour - because you worked hard all day.
Cheers!</description>
		<content:encoded><![CDATA[<p>Claus:  You picked up on an important point &#8211; I was writing this to express the feeling &#8220;we&#8221; have, not attempting to say that we&#8217;re right.  I fully appreciate the creative process that writing good software demands.  At Arc90, we&#8217;re so bought into this concept that we don&#8217;t have core hours.  Developers give so much more of themselves to their work when it&#8217;s on their terms, I&#8217;ve seen it played out time and time again for years.<br />
However, that doesn&#8217;t change the feeling we have &#8211; which is sometimes one of frustration at your methods.  I wrote this with some hyperbole in order to put forth a point.  Don&#8217;t take me all too seriously &#8211; I know exactly why you&#8217;re leaving at a reasonable hour &#8211; because you worked hard all day.<br />
Cheers!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Claus Wahlers</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-454</link>
		<dc:creator>Claus Wahlers</dc:creator>
		<pubDate>Thu, 10 Jan 2008 23:21:09 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-454</guid>
		<description>Dear Business Lead, Project Manager, Product Manager or Project Owner,
i agree with you on most things you wrote. Good communication helps a lot bringing a project forward and is one of the many keys to success.
However, this left me with a very sour taste in my mouth, especially when you say you once were one of us:
&quot;But sometimes I see you leave at a reasonable hour and can&#039;t fathom it! If I could, I&#039;d sleep here tonight to bang this out! Everything is teed-up, there&#039;s clarity of definition, all that needs to happen is to author those lines of code!&quot;
See, software developers are a very creative bunch. Yes, i said creative. I often compare software development to creative writing. You rarely ask a writer to finish that particular chapter today and please not leave until it&#039;s finished even when the plot is well defined. If you do, you are likely to get crap writing, or at least not something you were hoping for. Creative output is not something you can fit into an eight hour day. Creativity comes and goes. Maybe the writer even went home because she worked through the previous night already, trying to satisfy the (often ridiculous) deadlines of her editor?</description>
		<content:encoded><![CDATA[<p>Dear Business Lead, Project Manager, Product Manager or Project Owner,<br />
i agree with you on most things you wrote. Good communication helps a lot bringing a project forward and is one of the many keys to success.<br />
However, this left me with a very sour taste in my mouth, especially when you say you once were one of us:<br />
&#8220;But sometimes I see you leave at a reasonable hour and can&#8217;t fathom it! If I could, I&#8217;d sleep here tonight to bang this out! Everything is teed-up, there&#8217;s clarity of definition, all that needs to happen is to author those lines of code!&#8221;<br />
See, software developers are a very creative bunch. Yes, i said creative. I often compare software development to creative writing. You rarely ask a writer to finish that particular chapter today and please not leave until it&#8217;s finished even when the plot is well defined. If you do, you are likely to get crap writing, or at least not something you were hoping for. Creative output is not something you can fit into an eight hour day. Creativity comes and goes. Maybe the writer even went home because she worked through the previous night already, trying to satisfy the (often ridiculous) deadlines of her editor?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-453</link>
		<dc:creator>Patrick</dc:creator>
		<pubDate>Thu, 10 Jan 2008 18:51:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-453</guid>
		<description>My Dad was my sports coach on countless occasions throughout my childhood.  He didn&#039;t really encourage or support easy communication to the leader.  I&#039;m a software developer now and find that I have a really hard time communicating effectively up the ladder.  Go figure.  Deep frustrations indeed...thanks for listening.</description>
		<content:encoded><![CDATA[<p>My Dad was my sports coach on countless occasions throughout my childhood.  He didn&#8217;t really encourage or support easy communication to the leader.  I&#8217;m a software developer now and find that I have a really hard time communicating effectively up the ladder.  Go figure.  Deep frustrations indeed&#8230;thanks for listening.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bz</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-452</link>
		<dc:creator>bz</dc:creator>
		<pubDate>Thu, 10 Jan 2008 17:28:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-452</guid>
		<description>I think we need to see other people.</description>
		<content:encoded><![CDATA[<p>I think we need to see other people.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Avi Flax</title>
		<link>http://blog.arc90.com/2008/01/10/dear-developer/#comment-451</link>
		<dc:creator>Avi Flax</dc:creator>
		<pubDate>Thu, 10 Jan 2008 14:21:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.daniell.acr90-dev-02/2008/01/10/dear-developer/#comment-451</guid>
		<description>Yes, sir!
Great post!</description>
		<content:encoded><![CDATA[<p>Yes, sir!<br />
Great post!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
