<?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 for Martin T. Focazio</title>
	<atom:link href="http://www.focazio.com/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://www.focazio.com</link>
	<description>Digitizing the business world since 1992</description>
	<lastBuildDate>Thu, 16 Feb 2012 02:30:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Comment on Digital Agencies in a Post PC World (Part 2) by Laurent Stanevich</title>
		<link>http://www.focazio.com/?p=405#comment-296</link>
		<dc:creator>Laurent Stanevich</dc:creator>
		<pubDate>Thu, 16 Feb 2012 02:30:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.focazio.com/?p=405#comment-296</guid>
		<description>This is great. It really touches on a lot of topics that I&#039;ve thought about a lot, myself. In a lot of ways, I think this all comes down to &quot;abstraction layers&quot; -- the operational seams that open up as new technologies arise, and allow different elements of the process to suddenly interact a lot more efficiently (and usually a lot more   independently) than they had before. Whether you&#039;re talking about APIs or SDKs, they create a structured interface -- and a structural division -- between pieces of the system that had been organically intertwined before, and all of a sudden, you&#039;ve got a friction-free zone that allows the equilibrium and the structure of the entire system to shift. (Whoa.)

Anyway, to keep this relatively short, I&#039;ll bring up a couple of my own pet fascinations that are think are pretty relevant here:

1. &lt;em&gt;Coase&#039;s &quot;Theory of the Firm&quot;:&lt;/em&gt; There&#039;s a good chance you&#039;re already familiar with this, but if not, you &lt;a href=&quot;http://en.wikipedia.org/wiki/Theory_of_the_firm&quot; rel=&quot;nofollow&quot;&gt;should definitely check it out&lt;/a&gt; -- it&#039;s pretty much the most powerful idea I learned from hanging out with MBAs in management consulting. Coase&#039;s basic idea is that the organizational structure of a modern corporation is really a response to the market forces that make different functions -- like marketing, or manufacturing, or HR -- more or less &quot;expensive&quot; to handle internally. On the one hand...&quot;Duh&quot;...but on the other hand, I guess he was really the first to look at that dynamic with any rigor. He defines that structural dynamic in terms of &quot;transaction costs&quot;, but he looks at the idea of &quot;cost&quot; much more broadly than just &quot;price&quot; -- it theoretically encompasses effort, opportunity costs, added complexity, training requirements, cultural conflicts...anything that might impose a penalty on the business.
I think that offers a useful lens to look at a lot of the issues you&#039;ve brought up. Basically, the transactions involved in developing a more traditional &quot;thick&quot; app tend to be so deeply intertwined, and so project-specific, that the costs of trying to modularize the process are prohibitive (or at least really unattractive). You would basically need to have distributed teams that are all willing and able to do their work with a level of discipline, communication and trust that&#039;s pretty rare -- and above and beyond what you&#039;d need to just &quot;get it done&quot;. On the other hand, in the newer model you&#039;re talking about, the &lt;em&gt;platform&lt;/em&gt; enforces all those requirements, from the beginning, and makes them &lt;em&gt;really cheap&lt;/em&gt;. Playing by the rules is the cost of entry, but it&#039;s like handing out &quot;free drink&quot; tickets at the door. The OS developers introduce an economy-of-scale by doing 80% of the work for almost &lt;em&gt;every&lt;/em&gt; app on their platform. Any developer who wants to take advantage of that has to agree to a very specific set of ground-rules, but in return, it means that most of their &quot;transaction costs&quot; for developing the app go away.

2. &lt;em&gt;&quot;Service-as-a-Service&quot;:&lt;/em&gt; This is something that I&#039;ve really thought is critical for a few years now -- the imminent (and inevitable) modularization of professional services, especially in the digital space. Going back to Coase, a lot of the really large, &quot;vertical&quot; agency structures that you&#039;re describing have evolved (not just in digital, but in traditional, too) have really been in response to two things...
     (a) the structure of the funding sources (i.e., big clients with big all-in-one budgets), and
     (b) a pretty traditional assumption that &quot;employee&quot; = &quot;FTE&quot;
There are a lot of reasons why that&#039;s been true, but I really do feel that -- over time -- the professional services economy is going to graduate to a much more fluid and modular environment. I think it&#039;s pretty certain that 10-20 years from now, being an &quot;employee&quot; of an agency is going to be much less of a black-and-white question of getting 100% of your income, &lt;em&gt;and&lt;/em&gt; your insurance, &lt;em&gt;and&lt;/em&gt; your retirement savings, etc. from one company. There are going to be gradations of commitment, from the agency and from the employee, that sit between &quot;FTE&quot; and &quot;Freelance&quot;. The mechanics of those intermediate relationships will need to get formalized, so that they can be efficient, and there&#039;s a good chance they&#039;ll literally be codified, in some kind of API, but I think it&#039;s very, very likely that many people in our industry will have some kind of baseline &quot;platform&quot; employment that ensures that they can feed their kids, pay their mortgage, etc., but then operate in a much more free-ranging environment where their final take-home income is driven by a share of project revenue they&#039;ve worked on, the profitability of the agencies they&#039;ve worked with, and a lot of other factors.
The flip side of that, of course -- and the part that&#039;s more relevant to your post -- is that the &quot;firms&quot; involved would also need to become much more modular and fluid. Instead of large, integrated firms that encompass account management, and strategy, and design, and UX, and development, (and HR, and finance, etc.) I think we&#039;re going to see the rise of much smaller, focused entities. They may actually consistently collaborate together, so for all intents and purposes they act as a single entity to the client, but as seams evolve for how the different pieces work together, each function like Development or Creative is much more likely to have separate ownership, distinct economic structures, and individual responsibility for their own success and survival. I think that the changes you&#039;re talking about here are -- in some ways -- the beginning of that process, and I only think it&#039;s going to accelerate from here.

So...that&#039;s what I think. Great post.</description>
		<content:encoded><![CDATA[<p>This is great. It really touches on a lot of topics that I&#8217;ve thought about a lot, myself. In a lot of ways, I think this all comes down to &#8220;abstraction layers&#8221; &#8212; the operational seams that open up as new technologies arise, and allow different elements of the process to suddenly interact a lot more efficiently (and usually a lot more   independently) than they had before. Whether you&#8217;re talking about APIs or SDKs, they create a structured interface &#8212; and a structural division &#8212; between pieces of the system that had been organically intertwined before, and all of a sudden, you&#8217;ve got a friction-free zone that allows the equilibrium and the structure of the entire system to shift. (Whoa.)</p>
<p>Anyway, to keep this relatively short, I&#8217;ll bring up a couple of my own pet fascinations that are think are pretty relevant here:</p>
<p>1. <em>Coase&#8217;s &#8220;Theory of the Firm&#8221;:</em> There&#8217;s a good chance you&#8217;re already familiar with this, but if not, you <a href="http://en.wikipedia.org/wiki/Theory_of_the_firm" rel="nofollow">should definitely check it out</a> &#8212; it&#8217;s pretty much the most powerful idea I learned from hanging out with MBAs in management consulting. Coase&#8217;s basic idea is that the organizational structure of a modern corporation is really a response to the market forces that make different functions &#8212; like marketing, or manufacturing, or HR &#8212; more or less &#8220;expensive&#8221; to handle internally. On the one hand&#8230;&#8221;Duh&#8221;&#8230;but on the other hand, I guess he was really the first to look at that dynamic with any rigor. He defines that structural dynamic in terms of &#8220;transaction costs&#8221;, but he looks at the idea of &#8220;cost&#8221; much more broadly than just &#8220;price&#8221; &#8212; it theoretically encompasses effort, opportunity costs, added complexity, training requirements, cultural conflicts&#8230;anything that might impose a penalty on the business.<br />
I think that offers a useful lens to look at a lot of the issues you&#8217;ve brought up. Basically, the transactions involved in developing a more traditional &#8220;thick&#8221; app tend to be so deeply intertwined, and so project-specific, that the costs of trying to modularize the process are prohibitive (or at least really unattractive). You would basically need to have distributed teams that are all willing and able to do their work with a level of discipline, communication and trust that&#8217;s pretty rare &#8212; and above and beyond what you&#8217;d need to just &#8220;get it done&#8221;. On the other hand, in the newer model you&#8217;re talking about, the <em>platform</em> enforces all those requirements, from the beginning, and makes them <em>really cheap</em>. Playing by the rules is the cost of entry, but it&#8217;s like handing out &#8220;free drink&#8221; tickets at the door. The OS developers introduce an economy-of-scale by doing 80% of the work for almost <em>every</em> app on their platform. Any developer who wants to take advantage of that has to agree to a very specific set of ground-rules, but in return, it means that most of their &#8220;transaction costs&#8221; for developing the app go away.</p>
<p>2. <em>&#8220;Service-as-a-Service&#8221;:</em> This is something that I&#8217;ve really thought is critical for a few years now &#8212; the imminent (and inevitable) modularization of professional services, especially in the digital space. Going back to Coase, a lot of the really large, &#8220;vertical&#8221; agency structures that you&#8217;re describing have evolved (not just in digital, but in traditional, too) have really been in response to two things&#8230;<br />
     (a) the structure of the funding sources (i.e., big clients with big all-in-one budgets), and<br />
     (b) a pretty traditional assumption that &#8220;employee&#8221; = &#8220;FTE&#8221;<br />
There are a lot of reasons why that&#8217;s been true, but I really do feel that &#8212; over time &#8212; the professional services economy is going to graduate to a much more fluid and modular environment. I think it&#8217;s pretty certain that 10-20 years from now, being an &#8220;employee&#8221; of an agency is going to be much less of a black-and-white question of getting 100% of your income, <em>and</em> your insurance, <em>and</em> your retirement savings, etc. from one company. There are going to be gradations of commitment, from the agency and from the employee, that sit between &#8220;FTE&#8221; and &#8220;Freelance&#8221;. The mechanics of those intermediate relationships will need to get formalized, so that they can be efficient, and there&#8217;s a good chance they&#8217;ll literally be codified, in some kind of API, but I think it&#8217;s very, very likely that many people in our industry will have some kind of baseline &#8220;platform&#8221; employment that ensures that they can feed their kids, pay their mortgage, etc., but then operate in a much more free-ranging environment where their final take-home income is driven by a share of project revenue they&#8217;ve worked on, the profitability of the agencies they&#8217;ve worked with, and a lot of other factors.<br />
The flip side of that, of course &#8212; and the part that&#8217;s more relevant to your post &#8212; is that the &#8220;firms&#8221; involved would also need to become much more modular and fluid. Instead of large, integrated firms that encompass account management, and strategy, and design, and UX, and development, (and HR, and finance, etc.) I think we&#8217;re going to see the rise of much smaller, focused entities. They may actually consistently collaborate together, so for all intents and purposes they act as a single entity to the client, but as seams evolve for how the different pieces work together, each function like Development or Creative is much more likely to have separate ownership, distinct economic structures, and individual responsibility for their own success and survival. I think that the changes you&#8217;re talking about here are &#8212; in some ways &#8212; the beginning of that process, and I only think it&#8217;s going to accelerate from here.</p>
<p>So&#8230;that&#8217;s what I think. Great post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Role of Digital Agencies in the Post PC World (Part 1) by Digital Agencies in a Post PC World (Part II) &#187; Martin T. Focazio</title>
		<link>http://www.focazio.com/?p=377#comment-294</link>
		<dc:creator>Digital Agencies in a Post PC World (Part II) &#187; Martin T. Focazio</dc:creator>
		<pubDate>Wed, 15 Feb 2012 18:17:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.focazio.com/?p=377#comment-294</guid>
		<description>[...] Note: This post is a continuation of yesterday&#8217;s post.  [...]</description>
		<content:encoded><![CDATA[<p>[...] Note: This post is a continuation of yesterday&#8217;s post.  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Role of Digital Agencies in the Post PC World (Part 1) by The Role of Digital Agencies in the Post-Desktop Era (Part 2) &#187; Martin T. Focazio</title>
		<link>http://www.focazio.com/?p=377#comment-293</link>
		<dc:creator>The Role of Digital Agencies in the Post-Desktop Era (Part 2) &#187; Martin T. Focazio</dc:creator>
		<pubDate>Wed, 15 Feb 2012 16:31:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.focazio.com/?p=377#comment-293</guid>
		<description>[...] Martin T. Focazio  Digitizing the business world since 1992   Skip to content HomeContact      &#8592; The Role of Digital Agencies in the Post-Desktop Era (Part 1) [...]</description>
		<content:encoded><![CDATA[<p>[...] Martin T. Focazio  Digitizing the business world since 1992   Skip to content HomeContact      &larr; The Role of Digital Agencies in the Post-Desktop Era (Part 1) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Role of Digital Agencies in the Post PC World (Part 1) by Vineel</title>
		<link>http://www.focazio.com/?p=377#comment-292</link>
		<dc:creator>Vineel</dc:creator>
		<pubDate>Wed, 15 Feb 2012 02:22:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.focazio.com/?p=377#comment-292</guid>
		<description>Relax! You&#039;re just looking at the first stage in the development of the new client paradigm. By stage two or three the agencies will be right back in the saddle, building weird apps that people don&#039;t want, and getting paid crazy money to do so.

Remember the mid-nineties, when Netscape rapidly replaced Mosaic? There started to be very popular web sites with a bit of functionality (which would eventually become web apps.) These were mostly simple HTML forms using built-in elements and occasionally an image or two. Some funny logic would happen when you hit &quot;submit&quot; and a moderately entertaining results page would be the result. Ah, interactivity!

Then &quot;digital agencies&quot; and designers started getting into the fun. Remember the absolutely insane layouts we used to build using tables within tables within tables with a million cut up images?  Those were awful for builders and for users -- and were an early attempt to get around the ugliness of the built-in widgets in a web browser. The industry responded by pouring billions into new technologies such as CSS, Javascript, DHTML,  app servers, and the like. Just a few (like 10) years later, we had web browsers that could run almost any website that crazy art directors at digital agencies could imagine.

The same thing happened with gaming platforms, Facebook web apps, etc.

The same thing will eventually happen with iOS and Android and Windows Phone. The new &quot;flexible&quot; widget sets are being built, and it&#039;ll take years and zillions of dollars to get them to work well. But eventually they&#039;ll do whatever anybody wants them to do (because otherwise, the platforms won&#039;t survive.) We&#039;re only really 4 years into the new paradigm (because JavaME didn&#039;t really count.) The web itself took much longer to really get going.</description>
		<content:encoded><![CDATA[<p>Relax! You&#8217;re just looking at the first stage in the development of the new client paradigm. By stage two or three the agencies will be right back in the saddle, building weird apps that people don&#8217;t want, and getting paid crazy money to do so.</p>
<p>Remember the mid-nineties, when Netscape rapidly replaced Mosaic? There started to be very popular web sites with a bit of functionality (which would eventually become web apps.) These were mostly simple HTML forms using built-in elements and occasionally an image or two. Some funny logic would happen when you hit &#8220;submit&#8221; and a moderately entertaining results page would be the result. Ah, interactivity!</p>
<p>Then &#8220;digital agencies&#8221; and designers started getting into the fun. Remember the absolutely insane layouts we used to build using tables within tables within tables with a million cut up images?  Those were awful for builders and for users &#8212; and were an early attempt to get around the ugliness of the built-in widgets in a web browser. The industry responded by pouring billions into new technologies such as CSS, Javascript, DHTML,  app servers, and the like. Just a few (like 10) years later, we had web browsers that could run almost any website that crazy art directors at digital agencies could imagine.</p>
<p>The same thing happened with gaming platforms, Facebook web apps, etc.</p>
<p>The same thing will eventually happen with iOS and Android and Windows Phone. The new &#8220;flexible&#8221; widget sets are being built, and it&#8217;ll take years and zillions of dollars to get them to work well. But eventually they&#8217;ll do whatever anybody wants them to do (because otherwise, the platforms won&#8217;t survive.) We&#8217;re only really 4 years into the new paradigm (because JavaME didn&#8217;t really count.) The web itself took much longer to really get going.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

